Hello, Maxim Rogozhin, you wrote: > Kind time of days! > 1. Tell please principles SOLID now are actual? It is now direct read judgement that is principles from 80 and already it is not modern type. > 2. If it is actual, whether that you can formulate each principle (in relation to OOP) one-two sentences, i.e. is short and clear. Was tired to read the infinite dim explanations For a long time forgot, as it is decrypted SOLID, it was necessary to google. But the general common sense is present. 1.Single responsibility As it is necessary: the behavior of any insulated unit of the code (function, a method, a class) should be described by its title well. On method name it should be clear that it does. On class name - what for it is necessary. As it is not necessary: to create classes with the names containing words Factory, Processor, Engine, Manager. To write methods 100 lines and classes more than 300 are longer. Excessive fanaticism: It is a lot of methods and classes which do not do anything, except a call something else 2. Open Closed As it is necessary: to project the code so that the future changes demanded minimum changes in already existing code. And these changes should consist in code adding, instead of in its modification. And changes should save backward compatibility with the existing code. As it is not necessary: at adding of a functional the code changes "stains", it is necessary to rewrite the existing code. Excessive fanaticism: deep (it is more than 3 levels) inheritance, usage of aspects, carrying out in separate methods/classes of the code which does not carry semantic loading. Absence of understanding that is written not so configured , and own application in which source codes always can be corrected. 3. Liskov Substitution as it is necessary: all implementations of the interface should adhere to its contract ( on the interface, the general agreements in the project) As it is not necessary: One of implementations does not that is written in the interface contract Excessive fanaticism: to Consider as the contract behavior of one of interface implementations, to apply this principle to test and to stubs. 4. Interface Segregation as it is necessary: to Remember that for the big interface the big implementation is required, and too small to implement senselessly As it is not necessary: to have implementation of the interface it is more 500 lines or the implementation, which part or all functional delegates Excessive fanaticism to other classes: to Have interfaces which are never implemented and are not used without other interfaces. Marker interface, naturally, it is not counted. 5. Dependency Inversion As it is necessary: the Class should receive the dependences from the outside (through the designer), instead of to construct them independently As it is not necessary: to transfer in a class instead of dependences parameters for their construction, to use factories, static Excessive fanaticism: To use interfaces for all dependences (same not the library code, always it it is possible to transform a class to the interface), to transfer all dependences from the outside instead of usage of aggregation for dependences which are an implementation detail.