This series of articles for learning “Android source code design pattern analysis and combat” notes. The main record knowledge points of the basic introduction and personal views. This book combines Android source code to introduce design patterns for readers. The first part of the book introduces the “six principles of Object-oriented”. The first part of the book introduces the “six principles of object-oriented”. The first part of the book introduces the “six principles of object-oriented”.
1. SRP (Single Responsibility Principle)
Definition: There should be only one reason for a class to change. To put it simply: a class should be a set of highly related functions, data encapsulation. If a class takes on too many responsibilities, they are coupled together, and changing one responsibility may impair or inhibit the class’s ability to fulfill its other responsibilities. For example, the Activity in the MVC pattern assumes both user interaction and Controller logic processing. As a result, the Activity code is bloated and causes many changes.
2. OCP (Open Close Principle)
Definition: Objects (classes, modules, functions, etc.) in software should be developed for extension, but closed for modification. When software needs to be modified during its life cycle, such as changes, upgrades, and maintenance, errors may be introduced into the old code that has already been tested, damaging the original system. Therefore, when software modification is we should try to achieve through the way of extension, rather than modify the original code. Of course, the actual development of modified source code and inheritance may exist at the same time, the specific implementation of the development of their own judgment, to ensure the stability and expansion of the program, as far as possible to follow the open and closed principle.
3. Liskov subsidtitution Principle (LSP)
Definition: Any reference to its base class must be able to transparently use its subclass. Simply put, any reference to its parent class can be replaced by its subclass without any errors or exceptions. But the reverse is not true.
There are a few things to note when using the Reese substitution principle:
- Methods that a subclass needs to provide must be declared in the parent class, and the subclass must implement all methods declared in the parent class. According to the Reese substitution principle, the program is defined using a parent class. If the method of a subclass is not declared in the parent class, the method cannot be used.
- The core principles of Reese’s substitution principle are abstraction and inheritance. Therefore, the parent class should be designed as an interface or abstract class to be inherited or implemented by subclasses. When running, the subclass instance replaces the parent class instance, so we can easily expand the system functions without modifying the original subclass code, and the new functions can be implemented by new subclasses. Richter’s substitution principle is one of the concrete means to realize the open – close principle.
4. Dependence Inversion Principle
Definition: high-level modules should not depend on low-level modules; both should be abstracted. Abstraction does not depend on details, details should depend on abstractions.
In the Java language, dependencies between modules occur through abstraction. There are no direct relationships between implementation classes. Dependencies are generated through interfaces or abstract classes.
For the understanding of inversion, if this principle is not followed, high-level modules will depend directly on low-level module details. If this principle is followed, the low-level module details will depend on the abstraction of the higher-level module dependencies. So dependency inversion
If this principle is not used, high-level modules will depend directly on low-level module details. Changes in the details of low-level modules may require modification of high-level modules at the same time, so that high-level and low-level direct coupling is not conducive to code modification and extension.
Interface Isolation Principle (ISP)
Definition: Dependencies between classes should be established on the smallest interface. The principle of interface isolation is to separate some large and bloated interfaces into smaller and more specific interfaces. The goal is to reduce system coupling, so that better modification and expansion.
6. LOD (Law of Demeter)
Definition: An object should know the least about other objects. Also known as the “least knowledge principle”. To put it simply, a class should know the least about the classes it needs to couple and call. How a class’s internals are implemented is irrelevant to the caller or dependent, who only needs to know what methods it needs. The goal is also to reduce system coupling for better modification and expansion.
summary
Knowing the six principles, it is easy to find that their purpose is to reduce system coupling, improve cohesion and maintain system scalability. It is not difficult to complete the development task of the application, but the most difficult thing is how to ensure that the system architecture remains clear, flexible and stable after the application is upgraded and maintained. Following the six principles of object orientation is the first step on the path to flexible software. Design patterns will be introduced later