Developer Revelation

We are constantly dealing with MVC in the process of developing sites on frameworks. And each time, starting a new project, the developer hopes to make it better than the previous one, to apply in his new release all the accumulated development experience. Sometimes the developer tries to master other, new for himself, frameworks that are most appropriate in their fashion. Conversely, adhering to more conservative views, try to "use" their usual framework. Anyway, the developer has to write their own libraries, modules, or implement ready-made solutions. The conclusion immediately suggests itself: “there is no special reason to chase the framework.”

In the depths of their hearts, every right developer hopes that his project will not die and not become dusty in the raid array of any Cloud on the “nameless” hosting. But, as a rule, the developer himself does not want in the future to engage in supporting the project submitted, especially when his potential is now focused on developing a new interesting project. But there is another category of developers whose main task is to support and develop the project after its commissioning, and not always these specialists took direct part in the development process before the project went into operation. Therefore, we will continue the last conclusion: "..., it’s enough to stop your choice on a popular, well-documented framework with an advanced developer community or with a rich dad, like Zend."

Do not, however, forget about the need for competent application of various libraries and technologies. But the most important thing is to choose the right approach to development. Now, probably, any developer understands the need for the use of “Development images” in modern web-projects. Perhaps someone will disagree, and will argue that the use of “design patterns” and even OOP is too redundant, in terms of performance, processor and memory resources are not optimally used, and that this is too “cool” for the web, especially if the code then processes the interpreter, and that complicates the process of debugging the code. To some extent this is all true. But, as practice shows, the problem of shortage of processor resources is, as a rule, in last place, if we are talking about large web-projects with huge attendance, such as, for example, Facebook. In conditions, as it is fashionable to say, “High Load”, the main problems are reduced, tritely, to the number of revolutions of the spindle drive of the hard disk drive per second, thanks to the “storm” of database queries continuously received from users of the “world wide web”. Highly charged projects, as is known, require horizontal scaling of the project database into multiple clusters in one or several data centers. And memory resources are almost completely consumed for data caching. The conclusion is: “you should not save on the flexibility of developing a web-project and its further support, which is guaranteed by the use of design Paterns”.
')
What I do not advise to use when building an object model for a web project: avoid multiple inheritance - this is far from cool and not at all flexible.
Disadvantages of multiple inheritance:

• there is no 100% guarantee of getting the right result when crossing elements (properties, methods) of data structures of different types (classes), the developer always has to remember about these classes;
• abusing inheritance in general (not only plural), we get a cumbersome class that combines many methods and properties of our own ancestors, some of the methods and properties of which are probably not even needed in a descendant class; objects of such classes can be very redundant;
• the flexibility of class maintenance is lost when one of the ancestor classes needs to be changed, it will be necessary to change all or some descendants
• if it becomes necessary to create a set of objects similar in functionality, but at the same time requiring a different set of all ancestor classes, or the sequence of inheritance of ancestor classes of such objects is different, then in this case you will need to create a class for each such object that will be different from others only a sequence of ancestral inheritance or their composition.

Imagine: If each class will be responsible for the derivation of one particular letter of the alphabet, then in terms of inheritance, to build each different phrase you will need to write a separate class that inherits all classes of letters of the alphabet in its composition. As a result, a sea of ​​classes, and this is not very flexible. If inheritance is not flexible, then why replace it? Answer: inheritance. But the inheritance of not classes, but objects of different classes, says the basic law of object-oriented design. “Different” - not completely different, all these objects will implement one interface. This approach is implemented by the “Composite” pattern and covers all the disadvantages of class inheritance, while adding the ability to dynamically add / remove inheritance components, move them from the “node to node”, dynamically change their behavior and add new properties. The only drawback of the “Composition” is the difficulty in debugging. I recommend using the “Composite” pattern when building a “View”, if the framework does not provide such an opportunity, then it’s not difficult to implement your “Composite View”.