This article has participated in the third phase of the “High production” track at the Digger Creators Camp. For more details, check out the third phase of the Digger Project | Creators Camp to “write” personal impact.
Preface:
All of the examples are honor of Kings (for those of you who don’t play honor of Kings, it looks a little hard). In order to increase the interest of reading and facilitate the mastery of the seven principles, examples and principles of the connection, I have spent my life learning. I have been writing for more than a week. If you don’t like it, don’t spray it. If you have gained something, please click “like” before you go.
PS: The article refers to the king of glory of the relevant name part of the use of green characters, so there is no know what is a small partner do not have to trace, understand as a equipment name, hero name or direct understanding as a class name is ok.
One, single responsibility principle
1.1 Example: The punishment is on the list
Time: a rest day, place: King’s Canyon, character: Punishment in vain
Version description: This version of double burn stream is very popular in single play, which leads to many single heroes on the tank willing to carry retribution, and then the red lotus cloak. Increases growth and damage…
The two sides dragged to 20 minutes storm dragon king appeared, it can be said that the strength of the scene is very anxious. Now it’s time to take the Stormlord. In other words, we have a greater advantage in double punishment + long time battle control…
Intra-office Dialogue:
- Play wild: the opposite side to play dragon force group, I look for a chance to cut the archer mage around, you pull down the front, white attempt to grab dragon
- Assist: you can enter the group directly and control the group, I guarantee double C (our archer mage)
- The road leitian: Ok, the dragon will soon come to the bloodline, everyone get ready… I entered,Didn’t get the dragon
- Sagittarius: nothing, nothing, you look for opportunities to cooperate with the wild cut opposite Lu Ban, Lu Ban Si can play
- The road leitian: Ready to cut in, Lu Ban flashedI don’t have enough distanceIt’s up to you, Lu Ban…
After 5S, the opposite side with storm dragon buffs and lu ban output, destroy our side. Lead a good line of soldiers can directly push our crystal, victory.
Post-match replay:
- Although Bai Qi carries punishment, but did not rob the Dragon King.
- Also because of the punishment, so the team station did not control the opposite core Luban no. 7, resulting in the loss of the game.
If you can do either of those two things you won’t lose the game.
1.2 Principle analysis: single responsibility
In fact, most of the time, a position of the hero is simpler, with a single responsibility, may be a better choice. This is the same as one of the principles of design patterns — single responsibility.
There should only be one reason for a class to change, and it’s natural to add a variety of functions to a class when writing code. For example, we write a game, generally define a GameManager such a class, so we put all kinds of code, like processing logic algorithm ah, access to the database ah what are written in this class. This means that we need to modify the game manager whenever the requirements change, which is poor writing, cumbersome maintenance, unreusable, and inflexible.
We’ve known the benefits of object orientation since we first learned it: maintainable, extensible, reusable, and flexible. So this is something that needs to be corrected.
If a class has too many responsibilities, they are coupled together, and a change in one responsibility can weaken or inhibit the class’s ability to perform other responsibilities. This coupling can lead to a fragile design that is subject to unexpected disruption when changes occur.
- Definition of single responsibility:
The single responsibility principle: There should be only one reason for a class to change.
Second, the principle of openness and closure
2.1 Examples: The origin of yellow Dao
There are several versions of the yellow Saber online, so take a quick guess at how it is implemented at the code level.
- Since it is a wild blade, there is also a general nature of the wild blade (releasable against wild monsters) – it can be inherited.
- Since it is a new device, it also has a different attribute from other daggers – create your own class implementation.
A modification like this conforms to the open closed principle. Open for extensions, closed for modifications. At this point you’re probably thinking, what a load of crap I’m talking. There is a new item added, but don’t you want to expand it? There is no way to write the logic of yellow saber in red saber class.
That’s true, but have you thought about it? It’s in a mature framework to add new equipment. What if this is a program you just started developing? Instead of writing all the secondary sabers in one class and then using attributes or enumerations to identify which sabers are currently in use and then doing the logical processing accordingly…
2.2 Principle analysis: Open and close principle
When we first wrote the code, we assumed that the requirements would not change. When requirements change, we create abstractions to isolate future changes to the same class. For example, there were only two types of daggers in the original King: one for physical damage and one for spell damage. All other properties being the same, it’s perfectly possible to write code that has both daggers in one class. Then came the savage blade, which also did physical damage, but changed from damage to defense.
At this point, we need to consider whether the future game balance will include new blades, whether it will change the stats and numbers of the existing single blades… At this time we originally write a class in the realization of two playing wild knife, will naturally evolve into a playing wild knife base class, two subclasses inheritance form. Then there is the way to add the wild knife later.
When we do any application, we should not expect the requirements to be determined at the beginning and never be changed again. Since the requirements will certainly change, how can we make our program relatively easy to modify in the face of the changes of requirements, so as not to say that we have to delete the original part of the code and write a new set of requirements? This is the significance of the open and closed principle.
It is also a bad idea to abstract parts of a program that show frequent changes during development, whereas every part of the program can be abstracted. Rejecting unformed abstraction is as important as the abstraction itself.
The open-close principle is at the heart of object-oriented design. Following this principle can lead to the huge benefits that object-oriented technology claims, namely maintainable, scalable, reusable, and flexible.
- Definition of the Open closed Principle:
The open-close principle: software entities (classes, modules, functions, etc.) should be extensible, but not modified.
Third, the Richter substitution principle
3.1 Example: bloodsucking sickle
The vampire sickle, commonly known as the small vampire knife, can be synthesized with the following equipment:
From the image above we can see the properties of the little vampire knife:
- +10 physical attacks
- +8% physical vamp
When we click on it to synthesize items, we can see that all three items have + physical attack and + percentage physical drain. This means that the larger item is composed of the smaller item and inherits the attributes of the smaller item (the extra parts are private to the larger item).
In the game, no matter which of the three items you purchase at this point in time, you gain the attributes of its parent, the Little Vampire Knife. From a procedural point of view, the code that uses the little Vampire knife (parent class) can be replaced by any of the three devices (subclass) without affecting the game logic. This is the Richter substitution principle.
3.2 Principle analysis: Richter substitution
Further description: a subclass object can replace any object in the program’s parent object, and ensure that the original program logic behavior unchanged and correctness is not broken. This is a bit like polymorphism, which is a feature of object-oriented programming and a syntax of object-oriented programming languages. It’s a code implementation idea. Richter substitution is a design principle, which is used to guide how to design subclasses in inheritance relationship. The design of subclasses should ensure that the original program logic is not changed and the correctness of the original program is not destroyed when replacing the parent class.
Return to example: if in our example we have a small vamp knife (parent)GetAttribute() method that returns the attributes of the current item, then the parent class returns [+10 physical attack,+8% physical vamp]; If GetAttribute() returns +100 physical attack,+25% physical drain, then the design of this subclass violates the Richter substitution principle.
If a software entity uses a parent class, it must apply to its subclasses, and it will not know the difference between a parent and a subclass. In other words, in the program, replace the parent class with its child class, the program behavior does not change; Simply put, subtypes must be able to replace their parent types.
- Definition of Richter’s Principle:
Richter’s substitution principle: Subtypes must be able to replace their parent types.
Four, Demeter’s law
Also known as: least know the law
4.1 Example: Daji arrested people
Time: a rest day, place: King canyon, characters: Arthur, Daji
Daji in the middle of the line, to help Arthur on the road to catch people.
Daji sent three quick messages in succession:
- attack
- Two skills are good
- Three seconds to the big one
Arthur replies with a quick message:
- received
Three seconds later, Daji went to the road grass ambush. Arthur sell blood pretend to fight, but withdrew to Daji in the grass, Daji a set of two or three, with Arthur to take the head on the road.
For Arthur, he only knew that Daji was ready to go on the road to catch people, skills are soon good, the two news, he did not know the current daji skill level, also do not know how much money can be out of the next equipment Daji. Arthur didn’t know about any of daji’s “internal realizations,” and he didn’t need to. This is Demeter’s law.
4.2 Principle analysis: Demeter’s law
“Demeter’s law first emphasizes the premise that each class should be structured in such a way as to minimize member access; In other words, a class wraps its private state and doesn’t need fields or behaviors that other classes know about.”
The fundamental idea of Demeter’s law is to emphasize loose coupling between classes.
- Definition of Demeter’s law:
Demeter’s law: 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.
Five, interface separation principle
5.1 How Do I Understand the Interface Isolation Rule?
The key to understanding the interface Isolation principle is to understand the word “interface” :
- If the “interface” is understood as an object-oriented interface, then the interface design should be as simple as possible, do not let the implementation class not useful interface functions.
For example: class A implements interface I, which has X() and Y() functions; If class A only needs X(), then this design is not reasonable.
-
If “interface” is understood as a set of interfaces, it can be the interface of a class library. If we use a class that calls only a part of the interface, we need to isolate that part of the interface and make it available to only a few callers.
5.2 Difference from single responsibility principle
-
The single responsibility is for the design of modules, classes, and interfaces. Compared with the single responsibility principle, the interface isolation principle focuses more on interface design on the one hand, and on the other hand, it also has a different perspective
-
The interface isolation principle provides a way to determine whether the responsibility of an interface is single: indirectly by how the interface is used by the caller. If the caller uses only part of the interface or part of the functionality of the interface, the interface design is not simple enough.
Interface isolation rule: An object should not be forced to rely on interfaces it does not need.
Sixth, rely on the inversion principle
6.1 Example: computer motherboard
Yesterday the company art girl’s computer was suddenly using the blue screen, come to find me to help see what happened. According to my experience, the memory module was broken, so I opened the case to remove the memory module, replaced the slot and various operations, finally determined that one of the memory modules was broken. With a new memory, the computer started successfully.
This is thanks to the PC’s pluggable design. If memory, graphics card, hard drive, or any other component fails, we simply replace the broken one. ** This easy pluggability in object oriented is strong cohesion, low coupling.
Because no matter which manufacturer makes this memory, and no matter what its internal implementation is, it ultimately needs to support the motherboard slot. That’s designing for interfaces. If for the implementation of the design, then it is very likely that our memory is broken, also need to replace the corresponding motherboard.
6.2 Principle analysis: Dependency inversion
Rely on the inverted design concept: Abstract things are more documented than detailed variability. An architecture based on abstraction is much more stable than one based on details. The central idea behind dependency inversion is programming to interfaces.
In procedural development, to make common code reusable, it is common to write it into a library of many functions, so that we can call these low-level functions when working on a new project.
- Definition of dependency inversion:
The principle of dependence inversion:
A. High-level modules should not depend on low-level modules. Both should rely on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions.
Principle of synthesis/polymerization reuse
Composite reuse and aggregation reuse are two names that mean the same thing. Later, I learned that this is not the case. It can be said that these are two similar design patterns. What the hell is going on? Check it out below
7.1 Example: Soldier queue
Synthesis and polymerization are both special types of associations:
- Aggregation represents A weak ‘ownership’ relationship in which object A contains object B, but object B is not part of object A
- Synthesis, on the other hand, represents a strong ‘ownership’ relationship, embodiments a strict relationship between the parts and the whole, whose life cycles are consistent.
For example: The pawn line in King of Glory, each wave of pawn line is composed of multiple pawns, each pawn belongs to a pawn line, a pawn line and multiple pawns are aggregated. Each pawn has a weapon (attack type), and the relationship between the weapon and the pawn is part of the whole, and their life cycle is the same, so the relationship between the pawn and the weapon is synthetic.
7.2 Principle analysis: synthesis/polymerization reuse
Benefits of composition/aggregation reuse: Composition/aggregation of objects in preference will help us preserve the encapsulation of each class and be focused on a single task. This way classes and their hierarchy of inheritance will remain small and less likely to grow into uncontrollable behemoths.
- Definition of synthesis/polymerization reuse principle:
Composition/aggregation reuse: Use composition/aggregation whenever possible, and use class inheritance whenever possible.
There are two examples of these two principles, which I really didn’t figure out how to use with honor of Kings. Feel free to add in the comments if you have a good idea.
After studying, take a break. Go play king ~
