Android Architecture Learning Path series
preface
This is the second part of an architecture learning series that introduces UML diagrams, design principles, and design patterns. These terms are probably familiar, and they are very important for architecture, and only when theory is combined with practice will you become more proficient in the future. At the beginning of the requirements, don’t rush to write code, think about the nature of the requirements, use object-oriented thinking to abstract the process, not just a few classes.
Object oriented and process oriented
- Object orientation: Object orientation is a style in which classes are the basic unit, accessed through objects, and everything is object and owned
Encapsulation, inheritance, abstraction, polymorphismFeatures. - Process-oriented: analyze the steps needed to solve the problem, and then use functions to achieve these steps step by step, when using one by one can be called, more emphasis on the design of functions.
UML diagrams
From the Web: UML, or Unified Model Language, is a modeling Language. In software development, when the scale of the system is relatively complex, it is necessary to use graphics to express complex concepts abstractly, so as to make the whole software design more readable and understandable, so as to find the potential problems in software design as soon as possible, so as to reduce the development risk. It also greatly facilitates communication between business people and developers.
Common diagrams for UML modeling: use case diagrams, class diagrams, object diagrams, activity diagrams, state diagrams, sequence diagrams, collaboration diagrams, component diagrams, deployment diagrams. The focus here is on UML class diagrams.
Relationships between classes: inheritance/generalization, implementation, composition, aggregation, association, dependency. Inheritance/generalization and implementation relationships embody a vertical relationship between classes or between classes and interfaces. Other relationships represent class to class, or class to interface references, and are horizontal. Sometimes it’s hard to distinguish, but many of the relationships between things are difficult to identify, and they are semantic, so they are not completely distinguishable at the code level.
In general, the degree of strength of the latter relationships is as follows: combination > aggregation > association > dependence.
General UML class diagram tools will give hints as to whether the diagrams below are arrows or diamonds, hollow or solid, and will become familiar if you use them frequently. I’m using an online drawing tool similar to ProcessOn that can also be used to draw flowcharts, mind maps, UML diagrams, etc.
The above six relationships are expressed as follows:
Class structure
In general:
- Common class name: Normal font bold
- Abstract class name: italic bold
- Interface: add above bold
<interface> - Visibility symbol:
+=public.#=protected.-=private - The colon
:Represents the type of the property and the return type of the method
As shown in figure:
Generalization/inheritance
Generalization and inheritance are actually reverse processes. Generalization abstracts a parent from a subclass, while inheritance externalizes a subclass from a parent class.
The generalization relation is represented by A straight line with A hollow arrow (A inherits from B) :
implementation
Interface refers to a Class that implements the function of the Interface.
The implementation relationship is represented by a dashed line with a hollow arrow:
Rely on
The definition of a class dependent on another class is a “use” relationship, for example, a car dependent on gasoline. Dependencies are typically represented in Java as local variables, parameters, or calls to static methods. Unlike associations, it is an AD hoc relationship, typically occurring at run time, and dependencies can change as the run time changes.
A dependency is A dashed line with an arrow that describes the relationship between an object and another object at run time. A depends on B as shown below:
associated
Association is the connection between classes, so that a class knows the attributes and methods of another class. For example, there is an association between the passenger and the ticket. Students and schools are a kind of relational relationship; Associations can be bi-directional or unidirectional and are typically implemented using member variables.
By default, the association does not emphasize the direction, indicating that objects know each other. If the direction is emphasized, as shown in the following figure, it indicates that A knows B, but B does not know A:
The aggregation
Aggregation is a strong correlation relationship, which reflects the relationship of HAS-A. The whole and the parts can be separated, they can have their own life cycle, and the parts can belong to multiple whole objects. For example, the relationship between computer and CPU, company and employee, etc. At the code level, they are consistent with relational relationships and can only be distinguished at the semantic level.
The polymerization relationship is represented by A straight line with A hollow diamond arrow, as shown in the figure below, where A polymerizes to B, or B is composed of A:
combination
Combination is an association relation, stronger than aggregation, also known as strong aggregation, which reflects the relationship of Contains -A, which is also the relationship between the whole and the parts, but at this time, the whole and the part are inseparable, and the end of the life cycle of the whole means the end of the life cycle of the part. You and your mind, for example, are consistent at the code level and at the relational level, only at the semantic level.
Six Design principles
Here’s a quick overview of the six principles of design (from the Web, I won’t link to many of these articles) : The object-oriented design principle is at the heart of OOPS(Object-oriented Programming System) Programming.
In the actual architecture design, it is difficult to meet all the design principles. How to choose and choose according to the actual business
Principle of single liability
Single responsibility principle: Let a class do only one type of responsibility, when the class needs to shoulder other types of responsibility, need to break the class, emphasize high cohesion.
I’ve heard that even experienced programmers might violate this principle because of responsibility diffusion, where responsibility P is split into more granular responsibilities P1 and P2 for some reason. So when developing in an object-oriented language, don’t rush to write code, and consider whether the design of modules, classes, functions, and so on is simple enough.
The open closed principle
Open closed principle: Open for extensions, closed for modifications. Full interpretation of abstract, polymorphic characteristics, is the basis of most behavioral design patterns, all over the great framework, is the most important design principle. For example, for database operations, a CRUD interface can be abstracted. If the implementation mode is changed later, such as ROOM or GreenDAO framework, only the interface needs to be re-implemented. However, the external business layer only holds the interface and has no awareness of the implementation, and no changes are required.
Demeter’s rule
Demeter’s Law: In layman’s terms, a class knows as little as possible about the classes it depends on. That is to say, for the dependent class, no matter how complex the logic is, it should be encapsulated inside the class as far as possible, except for the public methods provided, without disclosing any information to the public.
The basic idea of Demit’s law is to emphasize the loose coupling between classes. The weaker the coupling between classes is, the more beneficial it is to reuse. When a class in weak coupling is modified, the impact on related classes is relatively small, that is, the hiding of information promotes the reuse of programs.
Interface Isolation Principle
Interface isolation principle: Create a single interface, do not create a bloated interface, and try to refine the interface. In programming, relying on several specialized interfaces is more flexible than relying on one comprehensive interface.
The interface isolation principle has a similar purpose to Demeter’s rule in reducing dependencies between modules. However, interface isolation focuses more on designing a single interface to improve reuse and indirectly reduce inter-module dependencies, while Demeter’s rule directly reduces inter-module dependencies.
When applying the principle of interface isolation, be sure to use moderation. It is not good to design an interface too large or too small. When designing interfaces, this principle can only be implemented accurately if you spend more time thinking and planning.
Richter’s substitution principle
Richter’s Substitution rule: When designing subclasses, follow the behavior conventions of their parents. The parent class defines the behavior convention of a function. A subclass can change the internal implementation logic of a function, but cannot change the original behavior convention of a function.
Dependency inversion principle
Dependency inversion principle: high-level modules (users) should not depend on low-level modules (users). They all depend on the same abstraction. Abstraction should not depend on concrete implementation details, which depend on abstraction. That is, program for the interface, not the implementation.
In practical programming, we generally need to do the following three points:
- Low-level modules should have abstract classes or interfaces as much as possible
- Declare variables as abstract classes or interfaces as possible
- Follow the Richter substitution principle when using inheritance
Design patterns
There are many articles on the web about design patterns, but I won’t go into them here. I’ve taken notes on them before. If you’re interested, you can look at Java object-oriented design patterns.
These design patterns are the essence of our predecessors after careful consideration, we can think more about whether it can be used in the actual development, with more familiar. In addition, it is not necessary to stick to these formal patterns. In combination with the actual business, we can consider using our own design patterns. In fact, many ideas are interchangeable, as long as we remember to follow the above design principles.
Write in the last
Architecture is not built overnight. Hopefully, one day, we can find the sense of accomplishment in architecture from the code we write instead of just running away. This series will be updated all the time to record the footprints of my learning on the road of architecture, removing the mysterious veil of architecture one by one
If the content of the article is wrong, welcome to point out, common progress! If you think it is good, leave a thumbs-up before you go. Your three companies are my motivation to write!