Detailed explanation of original sin based on PHP static class

Detailed explanation of original sin based on PHP static class_PHP tutorial

WBOY

Release： 2016-07-21 15:10:49

Original

859 people have browsed it

Hegel has a famous saying: Existence is reasonable. Using this as an argument, the use of static classes must be reasonable. However, when things go to extremes, they must be reversed. Once the code relies too much on static classes, its deterioration is inevitable. This is just like poppy, as a herb, it has medicinal value, but if used unscrupulously in large quantities, it becomes a drug.

What is a static class

The so-called static class refers to a class that does not need to be instantiated into an object and can be directly called statically. The code is as follows:

Copy codeThe code is as follows:

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

public static function floor($value)
{
return floor($value);
}
}

The role played by this class is more like a namespace. This is perhaps the most direct reason why many people like to use static classes.

Problems with static classes

Essentially, static classes are process-oriented, because usually they just mechanically put together originally process-oriented code. Although the result exists in the form of a class, the class at this time is more like An emperor's new clothes, so it can be said that static classes are actually wearing an object-oriented shell and doing process-oriented things.

One of the principles of object-oriented design: programming for interfaces, not programming for implementations. What difference does this make? For example: Putting aside the price factor, do you prefer a computer with a discrete graphics card or a computer with an integrated graphics card? I think most people will choose a discrete graphics card. Independent graphics cards can be seen as targeting interface programming, while integrated graphics cards can be seen as targeting implementation programming. The disadvantage of implementation-specific programming becomes clear: it loses the possibility of change.

The following is an example of an article management system to explain in detail:

Copy the code The code is as follows:

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

Article implements the necessary domain logic, and then leaves the data persistence to ArticleDAO, which is a static class, just like welded on the motherboard Integrated graphics cards are also difficult to change. Suppose we may need to Mock the implementation of ArticleDAO in order to test the code. However, because the name of the static class is used when calling, it is equivalent to binding the specific implementation method. Mock is almost impossible. Of course, in practice, There are some ways to achieve this:

Copy the code The code is as follows:

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:

Copy code The code is as follows:

Article::setDao('MockArticleDAO');

Article::save();

Although this implementation method seems to solve the problem of Mock, first of all, it modifies the original code and violates the opening and closing principle. Secondly, it introduces static variables, and static variables are shared states, which may cause Interfere with the execution of other code, so it is not a perfect solution.

Additional explanation, using the characteristics of dynamic language, you can actually implement Mock simply by requiring a different class definition file, but this also has disadvantages. Imagine that we need to change the implementation method multiple times in the script, But in fact we only have one chance to require, otherwise a duplicate definition error will occur.

The value of the object

If you abandon static classes and use objects instead, how should you implement an example of an article management system? The code is as follows:

Copy the codeThe 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, the dependency injection technology that people often call is used here, injecting dependent objects through constructors or setters:

Copy code The code is as follows:

$article = new Article(new MockArticleDAO());

$article->save();

The object has its own state, and the shared state will not interfere with the execution of other codes.

…

Of course, static classes have good sides. For example, they are very suitable for implementing some stateless tool classes. But most of the time, my subjective tendency is very clear. Use more objects and less static classes to avoid premature solidification of the system. By the way, I hope no one will tell me that static classes are faster than objects, thank you.