We will add and organize as needed.
There are things like the concept itself and no clear explanation.
** "Programming style that extracts frequently changed parts into classes, centering on the parts that do not change" **
In short, I understand that it is a way of thinking to program so that it is easy to change specifications and expand functions later.
** The essence of inheritance is an interface that brings together abstract concepts **
--"Inheritance of functions" is not the essence --The difference between class inheritance and interface is that inheritance can inherit functionality from a superclass. --Composition is used more often than inheritance --EX.) New part 1, new part 2, new product (part 1, part 2)
** Programming for an interface (abstract) **
--Do not program for concrete ("new" is concrete) ――It is not a problem that the number of dependent classes increases, but the problem is that it depends on the concreteness. --Instantiation without creating a factory should be done in the main class
** Eliminate waste, refine and make something easy to understand **
--Layer is different from inheritance and polymorphism --Give the correct name to the class (maybe this is the worst ...) ――It doesn't work even if you put the real world into an object-oriented source.
For the time being, I will protect only the following.
--Camel case --Class is a noun or gerund --The method brings the verb first
** There must be no more than one reason to change the class (role = responsibility = reason to change) **
** ・ When there is a specification change, it is possible to deal with the change by adding behavior. -Adding behavior does not affect existing code **
What is desired is the following substitution property:
There is one T-type object o2 for each S-type object o1 There is a program p defined using o2 At this time, even if o1 is used instead of ** o2, the behavior of p does not change **
** • Do not force the client to depend on methods that the client does not use **
-If you depend on a method that you are not using, it may affect clients that should not be related when that method is changed.
-Make each client depend on ** only the methods that it actually uses **
**-Group related interfaces and prepare a specialized interface for each client ** This allows the client to break dependencies on methods it doesn't use.
· Higher modules should not depend on lower modules, ** Both modules should depend on "abstract" **
· "Abstract" should not depend on implementation details, ** Implementation details should depend on "Abstract" **
-If the upper module follows the interface declared by the lower module, it can be said that the ownership of the interface belongs to the lower module.
** · Make relationships within the program end with an abstract class or interface, independent of the specific class ** No class derived from a concrete class Do not overwrite the methods implemented in the base class
** ・ It is just as important not to do premature "abstraction" and to use "abstraction" **
There was an explanation. I would like to identify meaningful and effective abstractions.
Recommended Posts