1

Topic: Principles SOLID in application to OOP

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

2

Re: Principles SOLID in application to OOP

Hello, Maxim Rogozhin, you wrote: > 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. Actually, but it is not necessary to go into extremes and everywhere to see their violation. Quite often, it is necessary to write simply normally that worked. It is not necessary to see violation SRP in each class. It is necessary to estimate, whether costs  and to project a class so that all principles were fulfilled? Or this code on burst can? Or all can tomorrow should be is ready and it is necessary to write as soon as possible? Or this code we can we do not plan to change more never (i.e. the code from discharge wrote - works - forgot), and if and it is necessary to change it will be easy for making? > 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 In my opinion in Robert Martin's book these principles are normally explained.

3

Re: Principles SOLID in application to OOP

Hello, MozgC, you wrote: It was not my judgement - I read it at a forum. MC> In my opinion in Robert Martin's book these principles are normally explained. Books of this at me are not present, but I read fragments - something not seemed to me that there shortly and clearly... But can it is simple with ...

4

Re: Principles SOLID in application to OOP

Hello, Maxim Rogozhin, you wrote: > Books of this at me are not present, but I read fragments - something not seemed to me that there shortly and clearly... But can it is simple with ... Look Vicks, there they are described quite to themselves normally. Or Tepljakova esteem (truth there on C#)...

5

Re: Principles SOLID in application to OOP

Hello, Maxim Rogozhin, you wrote: whether > 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 It is possible - to try to organize the code so that it did not turn out that all is connected to all. To try that one //// - one solved task. If to follow word-for-word to these principles it is possible to hit in other level of marasmus, i.e. a keyword - to try to follow, but without fanaticism. An overall objective - simplification of the code, its structure that it was possible to understand and understand faster in it it easier.

6

Re: Principles SOLID in application to OOP

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. On interviews about SOLID regularly ask, though in the code they are not present. Probably, hope that you will teach them. > 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 I Congratulate, you already on a head above the colleagues (I am absolutely serious). Single responsibility - you should change something in this unit/class, you change also all works as it is necessary in a new fashion. Fans of changes in other units and classes are not present. Open/closed - it is necessary to implement a new feature. You look in the code and see a place which as if specially left for a new feature. You write there the code and a feature is implemented. Liskov substitution - you can launch the program without UI or replace  with operative storage with little effort. You not  in , at you all under control also are easily played back by your machine. Interface segregation - if it is observed, in the good code it is very difficult to add the bad code. There are no rear entrances. Dependency inversion - your code looks as in textbooks on OOP - beautiful objects in vacuum. However this code the worker, in it concepts on which analysts and customers when you consider the project argue are reflected. The project does not look as a dial-up of the scripts integrating among themselves a dial-up . In the real world these principles are observed very rarely. For business they can be not important, business can bring the big money and for the account of file Excel with macroes. These principles are necessary especially not to be strained when work as the programmer for the salary.

7

Re: Principles SOLID in application to OOP

8

Re: Principles SOLID in application to OOP

Hello, Vladek, you wrote: V> Single responsibility - you should change something in this unit/class, you change also all works as it is necessary in a new fashion. Fans of changes in other units and classes are not present. . No. V> Open/closed - it is necessary to implement a new feature. You look in the code and see a place which as if specially left for a new feature. You write there the code and a feature is implemented. . No... V> Liskov substitution - you can launch the program without UI or replace  with operative storage with little effort. You not  in , at you all under control also are easily played back on yours of machines . . No... V> Interface segregation - if it is observed, in the good code it is very difficult to add the bad code. There are no rear entrances. . No... V> Dependency inversion - your code looks as in textbooks on OOP - beautiful objects in vacuum. However this code the worker, in it concepts on which analysts and customers when you consider the project argue are reflected. The project does not look as a dial-up of the scripts integrating among themselves a dial-up . Well, maybe, but these words can be carried to all principles, together with to DRY, KISS and YAGNI... V> In the real world these principles are observed very rarely. For business they can be not important, business can bring the big money and for the account of file Excel with macroes. These principles are necessary especially not to be strained when work as the programmer for the salary. At whom - as... All depends on the architect or from experience of developers.

9

Re: Principles SOLID in application to OOP

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.

10

Re: Principles SOLID in application to OOP

Thanks that unsubscribed - very much helped, now is clearer!))