Original sin of static classes

There is a famous saying in iegg: existence is reasonable. The existence of static classes is justified. However, it is absolutely necessary. Once the code is too dependent on the static class, its deterioration is inevitable. This is like poppy, as a herb, has its pharmacological value, but it becomes a drug if it is used in large quantities. What is static class> <LINKhref = "http://www.php100.com//st

There is a famous saying in iegg: existence is reasonable. The existence of static classes is justified. However, it is absolutely necessary. Once the code is too dependent on the static class, its deterioration is inevitable. This is like poppy, as a herb, has its pharmacological value, but it becomes a drug if it is used in large quantities.

　　What is a static class?

Static classes refer to classes that are called directly in static mode without being converted into objects by instance. The code is as follows:

 
 

  
  
 
  
  
 
  
  
class Math  
  
  
{  
  
  
    public static function ceil($value)  
  
  
    {  
  
  
        return ceil($value);  
  
  
    }  
  
  
 
  
  
    public static function floor($value)  
  
  
    {  
  
  
        return floor($value);  
  
  
    }  
  
  
}  
  
  
 
  
  
?> 
 
 

At this time, the role played by the class is more like a namespace, which may be the most direct reason many people prefer static classes.

　　Static class problems

Essentially, static classes are process-oriented, because they usually combine the originally process-oriented code sets mechanically. although the results exist in the form of classes, however, at this time, the class is more like a new emperor, so it can be said that the static class is actually dressed in object-oriented Pier, doing process-oriented things.

One of the object-oriented design principles: Interface-oriented programming, rather than implementation programming. What is the difference? For example: aside from the price, do you like computers with independent graphics cards or computers with integrated graphics cards? I think most people choose independent graphics cards. Independent graphics cards can be viewed as interface-oriented programming, while integrated graphics cards can be viewed as implementation programming. In this case, the disadvantages of programming are suddenly put on the paper: it loses the possibility of change.

The following is an example of a management system:

 
 

  
  
 
  
  
 
  
  
class Article  
  
  
{  
  
  
    public function save()  
  
  
    {  
  
  
        ArticleDAO::save();  
  
  
    }  
  
  
}  
  
  
 
  
  
?> 
 
 

Article implements the necessary domain logic and then delivers data persistence to ArticleDAO. ArticleDAO is a static class, which is as hard to change as the integrated video card that is soldered on the motherboard, suppose we may need to implement Mock ArticleDAO to test the code, but because the static class name is used for calling, it is equivalent to the specific implementation method already bound, Mock is almost impossible, of course, there are actually some ways to achieve this:

 
 

  
  
 
  
  
 
  
  
class Article  
  
  
{  
  
  
    private static $dao = 'ArticleDAO';  
  
  
 
  
  
    public static funciton setDao($dao)  
  
  
    {  
  
  
        self::$dao = $dao;  
  
  
    }  
  
  
 
  
  
    public static function save()  
  
  
    {  
  
  
        $dao = self::$dao;  
  
  
 
  
  
        $dao::save();  
  
  
    }  
  
  
}  
  
  
 
  
  
?> 
 
 

With the intervention of variables, you can set which static class to use at runtime:

 
 

  
  
 
  
  
 
  
  
Article::setDao('MockArticleDAO');  
  
  
 
  
  
Article::save();  
  
  
 
  
  
?> 
 
 

Although this implementation method seems to solve the Mock problem, the original code it modified first violates the open and closed principles, and secondly introduces static variables, static variables are shared and may interfere with the execution of other code, so they are not a perfect solution.

In addition, the dynamic language features can be used to implement Mock simply by using a different class definition file of require. However, this method also has drawbacks, suppose we need to change the implementation method multiple times in the script, but in fact we only have one chance of require. Otherwise, we will see repeated definition errors.

Note: In some cases, static latency binding can also improve the testability of static classes. For more information, see PHPUnit.

Object value

How can I implement the document management system example if I abandon static classes and use objects instead? The code is as follows:

 
 

  
  
 
  
  
 
  
  
class Article  
  
  
{  
  
  
    private $dao;  
  
  
 
  
  
    public function __construct($dao = null)  
  
  
    {  
  
  
        if ($dao === null) {  
  
  
            $dao = new ArticleDAO();  
  
  
        }  
  
  
 
  
  
        $this->setDao($dao);  
  
  
    }  
  
  
 
  
  
    public function setDao($dao)  
  
  
    {  
  
  
        $this->dao = $dao;  
  
  
    }  
  
  
 
  
  
    public function save()  
  
  
    {  
  
  
        $this->dao->save();  
  
  
    }  
  
  
}  
  
  
 
  
  
?> 
 
 

In fact, here we use the dependency injection technology that people often call to inject dependent objects through the constructor or Setter:

 
 

  
  
 
  
  
 
  
  
$article = new Article(new MockArticleDAO());  
  
  
 
  
  
$article->save();  
  
  
 
  
  
?> 
 
 

The object has its own status, so the sharing status does not interfere with the execution of other code.

...

Of course, static classes have a good side. for example, they are suitable for implementing some stateless tool classes. However, most of the time, my subjective tendency is very clear. I use more objects and use less static classes, avoid premature system solidification. By the way, I hope no one will tell me about the preaching of static analogy objects such as quick object. thank you.