Next, we will continue to talk about:
3. Dependency Inversion Principle
Definition: Program for abstraction, not for implementation; high-level modules should not depend on low-level modules, both modules should depend on abstractions (abstract classes/interfaces). The top and bottom layers should not communicate directly. There should be a middle layer between the top and bottom layers, which is responsible for the communication between the two parties.
Let's say a Chinese communicates with a foreigner (Japanese, German, Russian...):
Chinese and foreigners do not communicate directly, and an interpreter is needed in the middle, and both Chinese and foreigners rely on interpreters.
The Unity engine is a product that plays the "dependency inversion principle" very smoothly.
The high layer depends on the bottom layer: Developing games needs to rely on the low-level API of the platform.
Because when writing these games, use C# to develop a version, which can be released to N platforms with a little adjustment.
When we publish games on different platforms, Unity itself does a "docking" task, connecting the API in our code to the corresponding API on the platform.
Both the high-level and the bottom-level depend on abstraction: our game relies on Unity, and the API of each platform is also completed by Unity to complete the docking task.
Fourth, the Liskov transformation principle
Definition: ① If a software entity uses a parent class, it must be applicable to its subclasses. And it does not perceive the difference between the parent class object and the child class object.
②In the software, the parent class is replaced with its subclass, and the behavior of the software does not change; in layman's terms, the subtypes must be able to replace their supertypes.
To understand the Liskov conversion principle from the perspective of life, a company's brand is like a parent category, and the brand of Xiaomi is a parent category.
There are many products of the brand Xiaomi, such as: mobile phones, TVs, laptops, air purifiers...
These products are like subclasses that are implemented after inheriting the parent class.
[The following three pseudo-codes are the most common manifestations of the Liskov transformation principle in code]
Xiaomi brand mi = new Xiaomi phone(); ① ②
Xiaomi phone m5 = new Xiaomi phone(); ②
Xiaomi mobile phone m4 = (Xiaomi mobile phone)mi; ③
Entry point:
①Subclass objects can be directly assigned to parent class variables;
Understanding: Users who use Xiaomi mobile phones are users of Xiaomi.
②Subclass objects can call members of the parent class, but the parent class object can only call its own members;
Understanding: Xiaomi mobile phones can make calls and can use Xiaomi's after-sales service; but Xiaomi can't make calls, it can only toss its own user experience, design concepts, brand positioning, marketing strategies...
③ If the parent class object is loaded with a subclass object, the parent class object can be forcibly converted to a subclass object;
Understanding: Xiaomi launches a new product launch conference --> Xiaomi Mi 6 mobile phone launch conference.
Understand from the unity engine as an entry point: the Unity engine is a parent class;
Unity4.x, Unity5.x, Unity2017.x are all subclasses under this parent class. It has the functions of the parent class, and at the same time has its own new functions.
5. The principle of Demeter (also known as the principle of least knowledge/knowing)
Definition: ① If two classes do not have to communicate directly with each other, then the two classes should not interact directly.
If one of the classes needs to call a method of the other class, the call can be forwarded through a third party.
② An object should have as little knowledge as possible about other objects.
For example: ordinary people, banks, bank workers
In real life, we ordinary people do not need to understand the various rules and regulations of the bank. When we ordinary people have a business relationship with the bank, we are faced with the staff of the bank. The staff completed the communication between ordinary people and the bank.
In programming, ordinary people, banks, and bank staff are represented in three categories.
The two classes of ordinary people and banks are completely independent, and the class of bank staff completes the communication between the two.
When ordinary people or banks change the code logic, it will only affect the middle staff.
However, if ordinary people communicate directly with banks, the degree of coupling will increase, reducing the reusability of ordinary people and banks [ordinary people may also need to communicate with dozens of other institutions similar to banks].
1. The entry point in programming
① In the structural design of the class, each class should try to reduce the access rights of the members.
Unity project development, do not use public public fields, and then drag and drop resource assignments in the panel. All fields should be modified privately, and then public properties should be called publicly.
② The principle of Demeter mainly emphasizes the loose coupling between classes.
The lower the degree of coupling between classes, the more conducive to code reuse. A low-coupling class is modified without affecting related classes.
2. Unity Demeter Principle
In the Untiy4.x era:
We create a script, mount it on the game object, and there are a bunch of properties in the script that can be used.
transform，rigidoby，light，audio，collider.......
Through these properties, you can directly call the corresponding other components on the current game object.
But "it knows too much", regardless of whether our game object has these components or not, these properties exist and do not conform to the "least known principle".
In the Untiy5.x era:
98% of these properties are abandoned, leaving only one transform property, which is used to access the Transform component on the current game object. To access other components, you must obtain them first and then access them.
Sixth, the principle of interface isolation (here is the default understanding of object-oriented inheritance, as well as related syntax formats such as interfaces)
Definition: ① The client should not depend on the interface it does not need;
② A class's dependency on another class should be built on the smallest interface.
There are many departments in the company, such as: development department, business department, finance department, etc., each department has N employees working. Now I define what employees do as an interface, and all employees implement this interface to do things.
The things defined in this interface are:
Payroll calculation, accounting management, customer expansion, customer maintenance, product promotion, program development, software maintenance.
All employees implement this interface to do things. Now the problem arises. No matter which department employees, after implementing this interface, there are many things that they do not need to do by themselves.
At present, this interface is relatively bloated, and we need to "functionally isolate" the interface:
Financial department employee interface:
Payroll calculation, accounting management;
Business department employee interface:
Customer expansion, customer maintenance, product promotion;
Development department employee interface:
Program development, software maintenance;
In this way, the interface functions are isolated and subdivided into the responsibility function interfaces of different departments. Whether it is an existing employee or a new employee who joins in the future, only the interface corresponding to their own department needs to be implemented.
1. Entry point
The interface should be as small as possible.
When defining an interface, the methods in the interface should be as few as possible to avoid the interface being too bloated.
A class needs to implement an interface due to functional requirements, and it is necessary to ensure that all methods in the interface are required by the class.
2. Unity interface isolation principle
For example, in UGUI, there are many interfaces that can be used to extend the functions of UI game objects.
UI events in UGUI, when we write UI control scripts, after inheriting the Mono behavior class, we can also implement N UI event interfaces [Interface]. The event interfaces involved here are defined to adhere to the principle of interface isolation.