The book has the following paragraph:

Polymorphism illustrates another kind of encapsulation. Placing various implementations behind the common interface, we hide the mechanism working in their basis from the client code. This means that any changes made to this interface are transparent to the wider system. We can add new classes or change the code in the class, which does not lead to errors. What matters is the interface, not the mechanism that runs it. The more independent these mechanisms are, the less likely it is that the changes or amendments made will have a “domino effect” for your projects.

Can you please give an example of such a code that can lead to a domino effect? Something I just can’t think of such an example.

  • Write a code that crashes one by one - that's your domino effect. - Edward
  • I can easily write one using polymorphism. - Undefined
  • I am interested in the domino effect in this context. - Undefined

1 answer 1

Using interfaces brings to the fore the idea that different parts of your code interact with one another in a universal way. Accordingly, when designing, you select cleaner abstractions.

For example, you write a site with some functionality for registered users, create a user class with the email and photo fields and start using it everywhere, but after a while the requirements change and it turns out that the user can be a program that works on api. The program has no email and pictures, and some of the functionality does not work (for example, you send a notification to email), and you start writing some ifs and probably miss something. But if you develop a user interface, then you shift the focus from what the user is to what the user can do and get more versatile and flexible abstractions.

Please note that the author is talking about the independence of the interface and the code using it. The interface itself is not a panacea for problems, but the independence of different parts of the code is what makes your code flexible and more reliable.

Interfaces in libraries are especially useful. For example, you wrote a cool client for api vkontakte, but for sending requests use file_get_contents . But a user of your library may have a reason to disable the allow_url_fopen directive allow_url_fopen then he will not be able to use it. However, if you describe the http-client interface, then the user will be able to replace the standard implementation with file_get_contents with his own curl and the library will work!

That still happens. Newbies often write a bunch of sql queries where they need data from the database. As a result, data from the users table (for example) is selected in 10 different places of the code. There comes a day when the decision is made to make a change to the base scheme and delete or add some fields to the users table. Edit requests are made, but sometimes something is forgotten. Now, in some part of the system there may be a user without any field. If this field is used in any conditional code branch, then such a bug may exist imperceptibly for a very long time and affect other parts of the application. Let's say the new field was the level of trust in the user, on the basis of which the decision was made about the need to pre-moderate his comments. Now, there accidentally turned out to be null if the user comments on his own post.