Address: http://www.cnblogs.com/psunny/archive/2010/02/02/1662205.html
Programmers who know Java, C #, and other object-oriented programming languages are familiar with classes, objects, and OOP.
When talking about OOP, we will think of the textbook-style OOP concept: encapsulation, inheritance, and polymorphism. The superficial interpretation encapsulation is to hide the data. The Inheritance means that the subclass inherits the methods and attributes of the parent class or interface, and achieves code reuse. polymorphism means reload and rewrite. Such an explanation is only the basic features of object-oriented programming, which is simple and cannot be understood.
Object-oriented understanding
We should first understand object-oriented programming.
The following is my personal understanding of object-oriented, because I did not do programming for a long time, I have limited understanding of OOP, and I have no idea about design patterns.
- Abstract understanding: Abstraction extracts common and essential features from numerous objects. abstraction is a concept (such as public interface or abstract base class ), abstract processes are a comparative process. Only when compared can we abstract the common features and essence. Abstract processes are also a process of cropping and cutting off non-essential features. Abstract things from different perspectives, and different interfaces can be derived. These perspectives of viewing or comparing things can also be called interfaces.
- All things are objects, and the appearance of things is abstracted as object attributes. The privacy of things is regarded as object fields. The external behavior of things is abstracted as a public method of objects, the internal behavior of a transaction is regarded as the private method of the object. Attributes and public methods are called interfaces, and fields and private methods are called origin.
- All private members, interfaces, and base-class objects are used as method parameters to hide data. The interface and base-class method parameters are also implemented with polymorphism. private Members are the internal behaviors and forms of objects, private Members are the source of objects and private Members cannot be inherited.
- All public members are interfaces. The interface here is not just interfaces. It is a standard and a rule (such as a defined public attribute). It is the external behavior and form of the object, it is the bond between communication and interaction between objects.
- The significance of class inheritance is not only code reuse, but also class extension. Class extension is represented by method overloading and some methods and attributes in the subclass, and methods and attributes not in the parent class. To a certain extent, class extension can also be seen as a kind of polymorphism, which not only indicates that the subclass overrides the parent class method, but also shows that the subclass has more features than the parent class, subclass is a variant of the parent class, which is similar to the parent class but richer than the parent class.
- Method Overloading is manifested in "same things all the way". objects do the same thing and the results are the same (return value type), but the implementation methods are different (the parameter list or method body are different ). Method rewriting is manifested in "Being blue but better than blue". Subclass covers the parent class method and extends it. If not, rewriting doesn't make much sense.
- Object-oriented (OO) and process-oriented (OP): process-oriented design and analysis are based on processes. The solution to a problem or the implementation of functions must follow steps in sequence, each step can be a function, while object-oriented design and analysis are based on abstraction. Classes and interfaces are abstracted from problems and functions, and methods are atomic and classes are single. In object-oriented language, everything is an object. In the process-oriented process, a method is called a function or process. In object-oriented mode, a method is the behavior of an object, and an object-oriented method is a process-oriented encapsulation.
Object-oriented principles
The first five principles are about class design. They are:
- SRP, single responsibility principle, a class should have only one reason for change.
- OCP, open and closed principle, you should be able to expand the behavior of a class without modifying the original class.
- LSP, Liskov replacement principle, the derived class must be self-compatible with its base class.
- DIP: the principle of dependency inversion depends on abstraction rather than implementation.
- ISP, interface isolation principle, customers only need to pay attention to the interfaces they need.
The other six items are about the package design principles. In this article, a package refers to a binary publishable file, such as A. jar file or dll file, rather than a Java package or a C ++ namespace (3 ).
The first three package principles are about package cohesion. They will tell us what to divide into packages:
- REP: Reuse release equivalence principle. The granularity of reuse is the granularity of release.
- The CCP principle indicates that all classes in the package are closed for changes to the same class.
- CRP, the principle of reuse together, all classes in a package should be reused together.
The last three principles are about the coupling principle between packages, and the criteria for judging whether the structure of the system package is good or not.
- ADP: the principle of no-ring dependency. A ring is not allowed in the package dependency graph.
- SDP, stable dependency principle, dependency in a stable direction.
- SAP: the principle of stable abstraction, the degree of abstraction of the package should be consistent with its degree of stability.
Although some masters have summarized these principles, they are only a standard. We should follow the standards instead of relying on them. In actual software design, how to easily and quickly achieve requirements and Customer goals is the key. Excessive adherence to principles will complicate simple problems and cause a lot of trouble for yourself and your team.
Several Design Principles summarized by the original author are indeed troublesome and complex.
However, as the author said in the last sentence, we should follow suit, not relying on or fully complying with standards.
