The disadvantage of object-oriented

Invalid S
Links: https://www.zhihu.com/question/20275578/answer/26577791

The downside is that no one remembers what the object-oriented problem was.

1, object-oriented what to solve (or what good characteristics)
It seems simple, but it's really not simple: object-oriented three elements encapsulation, inheritance, polymorphism

（ Warning: In fact, from the industry so summed up this object-oriented three elements of the moment began, it has begun to make a mistake! ）。

Package: The meaning of encapsulation is to explicitly identify all member functions and data items that are allowed to be used externally, or to call Interface。

With encapsulation, you can clearly distinguish inside and outsideAllows class implementations to modify the encapsulation insideof things without affecting outsideExternal callers can also know where they cannot touch. This provides a good basis for cooperation--or, as long as InterfaceThe underlying contract is unchanged, and the code changes anthias.



inheritance + polymorphism: Inheritance and polymorphism must be said together. Once fragmented, it means that understanding has gone astray.

Say it first. Inheritance: Inheritance has two meanings: one is to inherit the method of the base class and make its own changes and/or extensions--claiming to solve the problem of code reuse; StatementA sub-class compatibleto a base class (or, on an interface, completely compatiblebase class), external callers do not have to pay attention to their differences (the internal mechanism automatically distributes the request [dispatch] to the appropriate logic).

Again polymorphic: Depending on the class to which the object belongs, the external call to the same method differs from the actual execution logic.

Obviously, polymorphism is actually two meanings attached to inheritance: "Change" and "extension" itself means there must be a mechanism to automatically select the version you have changed/extended, so there is no polymorphism, then two meanings can not be achieved.

Therefore, polymorphism is essentially the implementation detail of inheritance, so that the two concepts of polymorphism and encapsulation, inheritance, are obviously does not conform to logicOf The idea of using them as a side-by-side concept is clearly misguided from the start-and it is this misleading that makes most people focus too much on the tactical aspect of polymorphism, even to the point of almost malicious exploitation, while ignoring the strategic aspects of the problem, This makes it easy for the software to be designed as a thin piece of excrement (which will be discussed in detail later).


In practice, the first meaning of inheritance (realization of inheritance) is not very significant, and often harmful. Because it causes the subclass to be strongly coupled to the base class.

The second meaning of inheritance is very important. It is also called "Interface inheritance."
Interface InheritanceIt is essentially a requirement to "make a good abstraction, which prescribes a compatible interface so that external callers do not have to care about specific details and can treat all objects of a particular interface in a non-discriminatory process"-a program called Normalization。


NormalizationAllows high-level external users to handle the collection of objects that are compatible with all interfaces without distinction-just like the generic file concept of Linux, everything can be treated as a file, regardless of whether it is memory, disk, network, or screen (of course, for the underlying designer, it can also distinguish between "character devices" and "block devices "And then make a targeted design: to what extent, depending on demand."

NormalizationExamples of:
A, all objects can be serialized/tostring
b, all UI objects are a window, and can respond to Windows events.

It must be noted that all objects (subject to XX conditions) can do anything, not "everything". The latter is meaningless (from the information theory point of view, everything is XX contains the amount of information is 0).


Obviously Normalizationcan greatly simplify UserThe processing logic:
This is similar to the soldiers in the war, the monitor needs to know each warrior's name/character/expertise, otherwise he will not know who to deal with the sniper on the opposite hillside, and the company commander, just know what class/platoon He is good at anything, and then arrange their respective to defend a line, to the teachers/captains there, He is more concerned about the changes and expectations of the battlefield situation ... Without such a layer of simplification, but must direct to each person's words, exhausted captains can not command even if only a situation of clear conflict-the light one after the phone will be able to make him dumb.

In turn, the captains should not intervene in the tactical cooperation of a infantry class or a few big soldiers, which not only delays his duties as a military commander, but also interferes with the long-standing tacit understanding of the soldiers. His job is to get the right troops in the right place at the right time, rather than trying to figure out how to do it with a few creeps.

To restrain all units from performing their respective duties and to prohibit them from jumping into random command, which is Package。

It is through encapsulation and normalization that we can do "if a division can't solve the problem, then two more divisions" "If the army alone can not solve the problem, then let the Air Force also come over"-this flexibility is clearly from the good troop production. In software design, we call it "flexible response to demand changes through reasonable modularity."



Software design is the same. For example, when the message loop is distributing a message, it is sufficient to know that all the UI objects are a window, and that it is enough to respond to Windows messages; It is not necessary to know what each UI object is (normalized), nor should it care about the internal execution details (encapsulation) of the UI object-- The object knows what to do when it receives the message, and if it's a problem, just modify the object, without affecting the external.

Reasonable division of functional levels, timely cut off unnecessary miscellaneous information, a layer of upward provide concise but complete information/interface, high-level modules will not be exhausted--kiss is the most difficult and optimal software design method, not one.


Visible encapsulation and normalization are strategic, life-and-death issues。 Following it does not guarantee that you will win the battle, but you must die hard to see it in violation of it.

But these two problems are too big, too difficult, and there is no universal answer. This makes the laymen who have not enough experience and lack of serious thinking are this choice at all.。



As mentioned earlier, people wrong polymorphism This tactical technique refers to "encapsulation and normalization" at the same strategic level。 This led to the design work of the strategy to be discussed by a group A tactician who has no practical experience and only has a simple polymorphic eight-wayCapture and control, thus making " take a tactical instead of a strategy"Become a universal phenomenon--because for them, Polymorphism is both easy to understand and easy to play with a lot of tricks, and encapsulation and normalization are too vague and too complex for them to get started.
So, they use all their energies in polymorphic abuse, but never talk about encapsulation and normalization: even when it comes to the state, it appears as a polymorphic dependency.

This tactical-level rhetoric is easy and easy to do, but doesn't solve the problem-it always complicates simple problems.
However, they are not good and don't care about how to solve the problem. Because they don't have the ability to care.
It's killing me.



Summary: The object-oriented benefits are actually two points.
First, through the encapsulation clearly defined what is the interface, what is the internal implementation of the interface, what is the external caller of the interface, so that we do their own duties, not cross-border;
Second, through the inheritance + polymorphism of this built-in mechanism, at the language level support NormalizationDesign and make it possible for insiders to see the design from the code itself--but, note that just SupportNormalized design. A layman who does not know how to make such a design is still unlikely to gain any benefit from the design of the nonsense.


Obviously, without the object-oriented language, without class, you can do the normalization of the design (such as the old-fashioned universal file concept, the game industry, all the Elves), as can be encapsulated (by defining modules and interfaces), but with object-oriented language can be directly in the language elements explicitly declared these;
And with the object-oriented language, full text is a class, does not mean that there is a normalized design. Even, because they are confused by these fancy things, but even more do not know what is the design.


2. What people think is object-oriented, and therefore the tragedy and farce

Misunderstanding One, Object-oriented language supports the direct declaration of encapsulation and interface compatibility with language elements, so things written in object-oriented languages must be clearer and easier to understand。

In fact, since class implies that encapsulation, inheritance means declaring interface compatibility, the wrong class design is clearly a false declaration, a blindly defined class is meaningless chatter. and A false statement is worse than no declaration; a meaningless chatter is better than a false statement .。

Unless you really make a pretty design, and then use object-oriented syntax to declare the design-just declare what really is designed, where people really need attention, rather than barking everywhere-otherwise you won't get any benefits.

all objects are essentially encouraging the piling up of meaningless chatter, and use this tactical level of stupid chatter to replace strategic considerations.

Most people--note, not individual--even get neurotic by this senseless chatter to find meaning in chatter: yes, I'm talking about design-mode-driven programming and understanding object-oriented programming.



Misunderstanding two, object-oriented three elements are encapsulation, inheritance, polymorphism, so as long as the object-oriented language writing program, it must "inherit" the language of these three excellent features。

In fact, as mentioned earlier, encapsulation, inheritance, polymorphism is only a language-level support for good design, and does not guide good design.
If your design does not have a true encapsulation and does not know what normalization is, then what it writes out is rubbish (not only so, because of your low level, "object-oriented three elements" will mislead you, so that you faster, farther, more bizarre deviation from the target).



Misunderstanding three, to write software as object-oriented is at least harmless.。

To understand what is actually, we need a few concepts of science first.


1, what is the real Package？

--Answer me, is encapsulation equal to "hide what you don't want others to see and what you might modify later?"

Obviously is not。
If the function is not met, or the demand changes that are not expected to happen, then how do you put a member variable/function into the private, you will have to move it out in the future.

The more you go blind, the more you engage in some flashy "flexibility"--a design pattern, for example--the more places you move when real demand comes.

The real package is, after deep thinking, making good abstractions, giving "complete and minimal" interfaces, and making internal details transparent (note: Transparent to the outsideThe meaning is ,External callers can get whatever functionality they want, completely unaware of the existence of internal details;Rather than an external caller being furious by a private statement that has been blocked in order to complete a function, the only way to change the details he must pay attention to is through a weird, complicated, even exotic mechanism-and the access is often implemented so complex that a little attention can lead to catastrophe.

A design, only to achieve this height, can really do so-called "encapsulation", in order to truly eliminate the internal details of access.

Otherwise, Blunt put into the inside of the things, and finally have to be dragged out of the blunt--of course, this kind of thing will often be beautified to "access function" such as slag (not to say that the access function is slag, but that because of poor design, have to access functions and other items in the package to dig holes This behavior is slag).



A typical example is the coupling between the new and overly flexible memory usage of C + +.
This coupling leads to new[]/delete[], placement new/placement Delete and other weird things: these things must be used in pairs, how the distribution must be released, any wrong collocation can cause the program to crash-this is to be compatible with C, And the frustration of getting higher execution efficiency, but it is a typical case of "an abstraction hierarchy too complex to make a truly transparent design": it can only be said that the C + + designer is the real master, so complex things in his hands, only to pay such a small price.

(more precisely, new/delete and other language elements of C + + are orthogonal to each other, so when using these language elements, it is inevitable that each of them will appear to be a bit of a drag.) That is, New/delete this operation is non-transparent to other language elements: in C + + design, by dividing the new/delete into two tiers, one is memory allocation, the other is initialized in the allocated memory, and then exposes this layered detail, thus to achieve the maximum extent of encapsulation-- But New/delete is clearly too complex to relate to other language elements that are truly transparent to each other.

In this case, it is very straightforward to explain how difficult it will be to design a truly externally transparent package.


2. Interface InheritanceWhat are the real benefits? Is the use of inheritance to appear relatively tall on it?

Obviously not.

Interface inheritance does not have any benefits. It simply declares that some objects can be treated in a normalized manner under certain scenarios.

In other words, if there is no "need for indiscriminate processing of similar series of objects", then the inheritance is just loaded x.




Knowing the above two points, then, it is clear:
1, if you do not make good abstraction, or even completely do not know the need to do the abstraction is busy to "encapsulation", then you are only "sealed" and "loaded" just.
This "seal" and "act" will only create burdensome and false promises, and these burdensome and inevitable commitments will inevitably cause more trouble for future maintenance and even the entire project.

It is the drag of this burden and false commitment, not the need to cope with "demand change" Required"Flexibility" is the culprit for most object-oriented project code increases.

2, there is no real catch a class of things ( in the current application scenarioThe fundamental of the design of the inheritance structure, there will be no gain.

Not only that, please note I emphasized in the current application scenario。
This is because the classification is an extremely subjective thing, There is no universal taxonomy.。

For example, I would like to study racial discrimination, so it is necessary to classify the color of the skin, and in the case of forensic science, it is classified by cause of death.

Imagine that the demand is "fashionable ladies", but you are classified according to the "signs of suffocation death/death of drowning/poisoning death" ... Do you think the software can still be written in the back?



Similarly, I have met the man who wrote the game but struggled with the "weapons and equipment should not inherit from the game characters". What do you think?

In fact, one of the real abstractions of the game world is that everything is an elf with a place to feel the passage of time, and a "object that feels the time passing through a different picture" is actually the protagonist of the game, and "when the collision event is received, changing the next round of the picture Group" is the game logic.


See how far it is from "the weapon should not inherit from the game character". What does it look like when you think about a game role as a base class? Why is that?





The most heavyweight bomb is: is the square a rectangle? Should it inherit from the rectangle? If you can inherit from a rectangle, what is the length and width of the square? In this design, if I modify the length of the square, then this square class can also be called a square? Shouldn't it be naturally converted into rectangles? If I have two lists, a rectangle, a square, automatically converted objects can automatically migrate to the appropriate list? What language can provide this mechanism? If not, "treat all elements of a container in a non-discriminatory way" wouldn't that be a fart?

The root cause of this bomb is that "classes" in object-oriented, and "classes" in our everyday language and even in mathematical languages are not matter at all.

Object-Oriented "class", meaning "interface compatible with a series of objects", is only concerned about the compatibility of the interface (can search for the Richter substitution), the key is on the "treatment can be treated" (academically called is-a).

Clearly, this definition is purely and only to cope with the need for normalization.

This definition is often coincident with the class concept that we refer to in our daily conversations, but, as previously mentioned, it is fundamentally completely different from the eight poles.

The misuse of the term "class" in the life experience, and even the superficial understanding to do the design, will inevitably lead to a variety of deviations. This design is essentially nonsense.
That's the nonsense to write a program--does anyone think such a person can have good results?

But almost all object-oriented languages, almost all object-oriented methodologies, are encouraging everyone to do so without realizing how unreliable their theoretical foundations are.
How can you not die?


Do you dare to say that object-oriented is harmless?

-Before you really understand what encapsulation is and what it is, each time you write the class, you take one more step on the wrong path.
The core of the design that really needs attention is simply encapsulation and normalization. when a project starts, the sooner the "class" writes, the farther away it is from the core .。
The various object-oriented methodologies that were preached in the past, and even some languages themselves, are just encouraging and even forcing developers to write as early and as much as possible.


Repeat: The package can (through a fixed interface) cope with requirements change, normalization can be simplified (the user of the Class) design: Above, is the most basic object-oriented benefits.
Everything else is just a derivative of these two foundations.

Other words If you don't get the two basic benefits, there's no derivative benefit.--Meet demand Change/Simplify design is not the Dazoigu cannon can do.


Misunderstanding four, only the object-oriented language writing program is object-oriented.

In fact, when the UNIX system presents the generic file concept, the object-oriented language does not exist at all, and the basic abstraction of the game-World Sprite is originally written in C or even sinks;

Object-oriented is actually drawn from the experience of the above-mentioned successful designs.

Therefore, object-oriented design, do not have to c++/java such as support object-oriented language can be implemented, but they are only after you have made the object-oriented design, you can write a little more comfortable-but, if a project does not need to make an object-oriented design, Some object-oriented languages can make you very difficult.

write programs in object-oriented languages, and a program is designed to be object-oriented, and the two are not the same thing that eight Poles can't fight.。 The Linux kernel written in plain C is actually more object-oriented than most of the projects that come out of the C++/java language--but most people think that they are blind to writing class noodle code is the object-oriented Orthodox, And the Linus of the dead brains of the pan-file abstraction is just a process of thinking out of the antique.

This misunderstanding, even reaching the wiki entry, defines OOP as the degree to which "write programs in support of object-oriented language".
When we mention object-oriented, we are talking about strategy, talking about the overall design of the software, but there are people who distort it into tactical, aimless but self-feeling, trivial speculation.
--I'm afraid this is also no one said that the pan-file design idea is a scam, and the object-oriented is the industry's main reason for the severe attack: the real package, the essence of normalization was abandoned, floating on the surface, the chatter of the class/design model has become "orthodox"!

Borrow a link from a friend downstairs Peytoncai:
Designer Spit Groove: Object-oriented Programming there's a problem in the bones.

————————————————————————————

Summary: Object-oriented is actually a summary of past successful design experience. But the successful design, not because of the encapsulation/normalization of success, but to meet their own problems, give the right design。

It is good for a beginner to know that he should move in the direction of encapsulation/normalization, and to frame them in an object-oriented way, even to make them think that writing a class is completely without thinking, and that what should be pursued is a design pattern, which is evil It essentially takes the beginner's attention away from the encapsulation and normalization that really should be noticed, deceiving them into a "near-malicious, all-out, abusive, polymorphic" quagmire.

In fact, the more arbitrary the class writes, the more it needs to design patterns, the more the error is written, the more features it uses, the more rigid it must be to have more features, patterns, and even grammatical hack in order to barely fulfill the demand.

It is only through real deliberation that it is possible to kiss.


The biggest drawback of the clamor for object-oriented programming is that the concept of software design work is changed into a "nonsense of class and related dogma, regardless of whether there is any benefit in the first taping", even making people forget to pay attention to "the problem that the abstraction really simplifies the face"-this is the wretched speculation, not the design.

Word: no silver bullets. Any desire to rely on a "tall" technology-whether object-oriented, data-driven, message-driven or lambda, and so on-can once and for all make any real-world problem "solved" is doomed to failure, are just layman's fantasy; It's not the ditch that's weird.

If you want to make a kiss, you have to have a thorough understanding of the problems you face, enough experience and ability, and thoughtful thinking to make a concise abstraction: whether the final abstraction is object-oriented, process-oriented or data-driven/message-driven, or even a hodgepodge, doesn't matter. As long as this design can do the most important and hardest kiss, it is a good design.

In a particular field, in a particular scenario, there is a successful experience, a correct/reasonable direction: the technology is not guilty, but there is no silver bullet.


————————————————————————————————————————
2016.5.16:

Well, this is a series of posts I sent on the CU a long time ago ...

At that time many advocated "object-oriented is good to be good" on the smattering Importune, this series of posts is to refute them. So a lot of sarcastic words are very strong, forgive me.

For example, the legendary object-oriented game field should be great--say the popular Wow bar.

This game has 10 professions, 10 races, each race has its own unique ethnic talent (this race talent may also be different depending on the occupation, such as Blood elves), each occupation has dozens of or even hundreds of different skills/spells, these skills have melee skills, have remote skills , some skills can cause damage or bad condition to the enemy, some skills will be able to add a good status to their teammates or heal teammates, and many of these skills will also be based on the status of the target to switch different effects, some skills are monomer effect, some skills are halo effect (also divided into the enemy caused by halo effect or two of their own), or both), while others are map extent effects (such as a blaze storm is a circular area; ice pick is a tapered area; In particular, a slash is another hostile target that is no more than 5 yards below the current target-a boss with a strong slash, which delivers dozens of targets from the first target. The total transmission distance can reach an exaggerated hundreds of yards, and this damage is also unique: The warrior's strike is each target damage fixed, some bosses are at the same time the more people beat the injury lower, but there is a sick boss is beaten more people hurt the more ... Most skills can also be enhanced/altered by the Glyph of talent (for example, by inserting a glyph, the Mage's fireball does not cause sustained damage but increases the casting speed; Point a talent, the Mage's cold deceleration effect will reduce the other side of the treatment effect; Some of the rogue's skill attacks will prolong the duration of the state of the attack, and so on); there are many skills that are obtained by learning a profession or equipping/holding an item (for example, by taking medicine, you can get the blood of life, which is available every 3 minutes and can respond to several health values in a few seconds- -this skill is linked to the picking skill level, but it is likely that the next version will be linked to the player's life limit to prevent it from being denounced as a scrap skill by the player as it is now, and that different levels of skill may have a difference in cast time or even extra effects, and each skill will cause damage to different attributes. /Effects (sacred, shadow, elemental, physical, and so on), even a skill that causes multiple types of damage, and an ice fireball that intelligently chooses a more lethal type of perverted magic based on the target's resistance ...

Finally, most importantly, all of the thousands of professional skills (and perhaps some of the thousands of unique skills of NPCs) are unstable, often modified by the combination of a skill or certain skill set (such as an extra negative state such as invincible/holy healing; or even a full modification of "resistance"). "Definition of the concept of" armor "--played by Wow knows that it happens almost every month.

Well, how are you going to design these thousands of skills/effects?
Or, you just put these concepts in the class of this basket, and then open the special case, special cases can not solve the 23 mode hard to a piece of sticky, tube his overall structure, how to drip?

Nonsense.


Well, there's a story to say:
Someone sent a few blind people a fish, the blind men happy bad, decided to boil fish soup drink. Fish soup boil, blind a tasted a mouthful, really fresh Ah, the blind B hurriedly also drink a mouthful, too fresh, too good to drink. Several blind men drank one side of praise--suddenly the blind man called up: the fish jumped on my feet, it was not in the pot!
The blind people are surprised: this fish did not put into the pot, soup is fresh into this, if put in the pot, not to kill us all!

The object-oriented fundamentalists make a mess of things, the same will be surprised: God, with the object-oriented complex into this, this need not object-oriented, the software can not write it!

Think about what would happen if the object-oriented fundamentalists were to design:

Define a base class called skill; then an inheriting class is called a spell skill, another is a physical skill, and then the Divine spell inherits from the spell skill, and the disease spell inherits from the spell skill; Since paladins have both physical and magical effects, multiple inheritance of divine spells and physical skills is necessary, and multiple inheritance is too dangerous. So we have to make the sacred spell into the interface class, introduce the interface inheritance even with the implementation of pure virtual function and so on high-end concept; Then, the blizzard designer who deserved to be shot came up with a strange idea for a skill to add divine sustained damage to the target-and then had to add an inheritance level, Makes divine spells a subset of sacred persistent damage spells: a dot (damage of time) skill that only immediately causes a sustained damage ...

So, a talent, a skill will have dot, otherwise it will not do?

Design pattern is a panacea, isn't it ^_^


By the time you get all thousands of skills, at least a tens of thousands of-class, dozens of-story tree of Terror, and will run out of 23 design patterns (and even invent a few new ones, I won't be surprised), so sophisticated that no one wants to touch it.


However, please note that the days of the blizzard designers, in the beginning of the design program to specify that dot can not be critical, and later added to the Convention that a certain point of a profession may be critical hit; a certain dot in another profession can be critical when a talent is gifted; As for the Death Knight, when he wore four of the equipment in the T9 suit, One of his plague-type dots can be critical-but the other plague dot is never critical.


Well, well, that's a good deal--isn't that the strategy model?

Well, you can fill in a few more hundred, and then put the tens of thousands of classes in the old dozens of-tier inheritance tree one by one. It's not that I'm defending ...



Alas, the blizzard designer, who had shot hundreds of times, had a bad idea, asking: When the death Knight ordered a gift from the evil department, not only to add a new dot, but also to protect his two dot diseases and a debuf disease during the existence of the new dot.


Continue to add: Inside the WLK, the Blizzard designer, who was shot into a sieve by bullets, jumped out of his mind with a loophole: he asked to add the concept of a carrier, to temporarily remove all of his skills when he sat on the upload, to replace the skills of a carrier, or when he was seated in a particular position on a particular carrier. To prevent him from any harm and allow him to release all his skills!
What's more, he asked that some skills would not have been allowed to be cast on the move, but now, when the player is seated in a position on the carrier, temporarily allow him to move the cast!

Also, in order to balance a field battlefield, he also asked that, in the case of a small number of people, temporary based on the increase in their health and all skills of attack and healing ability-This change must be based on the number of people entering the battlefield in real-time, and in the case of a continuous failure of a battlefield, they must compensate them!



Well, look at these ever-changing tricky demands, if there's no object-oriented, no 28 design patterns led by the strategy model (I have reason to believe you need at least 28 design patterns instead of 23) Wise leaders, we have not touched the big project, do not understand the object-oriented silly B, It's the tears that tear the Great Wall out of the way, right? I certainly know that the materials that build the Great Wall are extremely difficult to dissolve and water.

Poor blind man, is your fish soup very fresh?

Well, here, I hope the readers can stop and think about it and see how the problem is solved.














Did you think of it?
Here's the answer to see if your thoughts coincide:

This problem blizzard in the Diablo 2 era has been a perfect solution: Spell/Skill Database


The so-called database, in fact, is equivalent to tabular, for example, this casually invented the simplification scheme, is to design a data table with the following fields:

Spell ID animation Effects scope action Type properties special restrictions hardening type special settings


The Special setting field can be a LUA code, where you can search, set a very special type of damage, or query the target of a strange skill such as a slash/heal chain, and so on.

Special restriction fields set spells or/and effective conditions, such as dispel limit to only be used for magical buf/debuf (depending on the occupation, there may be one of offensive dispersal and defensive dispersal, may also be available-this is reflected in the ability to disperse enemy/friend Target Debuf)



In this scenario, releasing a spell/skill becomes a look-up operation-find the spell ID, find its action type and damage attributes, and calculate special settings (including but not limited to the judgment of the cut-to-chop pattern, talent bonus and talent effects, glyph addition and glyph effects, etc.).

Thus, in the end, the entire spell system is divided into a group of magical buf/debuf, physical buf/debuf, which affect a factor in the damage formula or damage effect, and the damage effect is divided into immediate injury/immediate treatment and sustained injury/continuous treatment The last is a set of impact scope decision mechanism.


For example, the knight opened the Shield, and he also got a buf and a debuf.
BUF is "invincible", the effect is equivalent to set the damage formula A * (...) in front of a factor of 0 (no invincible When this factor is 1), so all damage is not valid.
Debuf is "self-discipline" because he has "self-disciplined debuf, not allowed to use" settings in his holy shield and holy healing skills, and prohibits him from using these rogue skills again in a short period of time.

The enemy Mage released the ice arrow to him, the system accepts, but inquires the knight State, found him in Invincible state, returned the big two words "immunity".

Then, one of the enemy priests used to disperse him, and the search for the priest's dispersal revealed that there was no holy shield in the dispel list of the dispersal, and that the hint could not disperse or disperse the other dissipated (magical) effect.
The enemy pastor reacted quickly, and again used brute force to disperse him, inquiring about the priest's brute force dispersal, and found that the priest had not been able to cast his spell until recently using brute force dispel.
After waiting for 3 seconds, the enemy priest found his powerful dispel cooling (cool down), again using brute force dispel, the query found that strong dispel can disperse the holy shield, and successfully removed the knight's invincible state.

Now, the enemy Mage once again released ice arrows to him, Knight switch to anti-Halo, the system inquires Knight status, find ice anti-Halo, and query Mage penetration level, and critical level, according to the formula to calculate whether the hit, can cause full damage and can be critical, and then extract the Mage and Knight both equipment, The gifted data is the formula that calculates the damage estifcation, the reduction data, and finally gives the number of damage the knight receives (including some resistance).



In the Blizzard designer's collation, the above-described results form several forms, as long as you query and replace the corresponding data, you can calculate the damage/treatment values and types; Special effects may be supplemented with LUA code stored in the database.

The final design effect is as if an interpreter is embedded, which interprets the content within the database based on the spell ID.


In this way, as long as the damage formula, damage/BUF type, animation effect, etc. in place, then a new spell is simply a new record in the database; Let a character learn a new spell, just add the spell name (or spell ID) in its list of available spells Release spells are extracted from the database based on the spell ID, and the damage is calculated by reading the damage formula according to the spell ID, then substituting the relevant fields and evaluating them.

And all this can even be done through an internal implementation of the editor, with a graphical interface.


How is it? Unparalleled extensibility and convenience, right?

This whole set of things, the core code is probably only thousands of or even hundreds of lines. This is because seemingly complex halos, buf, and so on, are actually abstracted into the same process as other spells. In the end, all of this is attributed to a few common processes, such as interpreting the execution damage formula, extracting the execution of the specified animation, This is obviously another fruit of encapsulation and normalization thought. But why can't you just think of encapsulation and normalization? It's simple, because you're being completely biased by those idiots who will only be talking about the shallow, multi-modal chatter.

I did not personally realize this, so I do not dare to conclude that this thing by hundreds of lines of code really can be fully implemented, but according to my experience on other projects, this should be hundreds of lines of code can be written out-but it is possible to write and debug the hundreds of lines of code will be one weeks or even one months.

Compared to the non-thought of writing class will inevitably lead to the huge, complex class level, and pull to pull the egg pain incomparably complex design pattern of large nets, the implementation of this thing, maintenance, modification, expansion of the convenience degree, is obviously not a magnitude: the former may be hundreds of people to strive for several years, No millions of lines of code can be implemented correctly, and inevitably bugs are everywhere, and the latter, a person, a month, thousands of lines of code, complete. If the level of implementation is sufficient, then do not touch the code after writing, but to write the graphical editing tools. After that, the extension, maintenance is simply to use their own implementation of the tool dragged to change the properties, values, and then click the disk to write to the database, finished.


Therefore, million can not be inflexible to embrace the object-oriented. The problem you are facing is the most important.
You have to improvise and give the right solution--and what the final design will be, it doesn't matter. It is more important than anything to come up with a simple, effective, and reliable solution.

Finally, the sentence I summed up in the previous article:

Encapsulation can (through a fixed interface) cope with requirements changes, normalization can be simplified (the user of the Class) design: Above, is the most basic object-oriented benefits. Everything else is just a derivative of these two foundations.

In other words, without the two basic benefits, there is no derivative benefit--the need to change/simplify the design is not a Dazoigu cannon.

Again, coping with demand change/simplifying design is not an empty propaganda slogan.

encapsulation and normalization similar to the Army system construction, the goal is to develop a standardized, three-dimensional, changeable, efficient command system, so as to win the war, fight hard to fight the abilityAnd then go easy on the crush problem. This so-called strategy.

And those who pile up useless so-called "design patterns" are actually glued to each part's surface-which, they say, adds flexibility, response to demand changes, and simplifies design: for example, if you have a bag, you can hang them on the hook that sticks on the flywheel.

But in fact, you'll never put your bag on the flywheel (but you still have to pay for "brilliant" designs that "brilliant" guys "have to avoid the hooks off the flywheel, hang on to other parts, have too much centrifugal force to damage the package that hangs on it," etc.).
Fortunately, in addition to some business projects (or other projects of a similar nature), you will not use such a rotten thing. Because these idiots ' sticky hooks will inevitably cause the whole project to turn into a sticky group, committing suicide after protracted delays.

This approach, which is clearly the opposite of the object-oriented beginner's mind-the efficient command system through encapsulation and normalization-makes it inevitable that every project in which this poison is involved will inevitably become a puddle of crap.

So, unfortunately, only the designer who kills Matt will do so. The real designer will not consider the need to "bag on a flywheel" when designing the engine (this is called "tactical speculation instead of strategic layout"). He's going to have to add a trunk to the whole car design.




Please note that this is not a metaphor.

As you can see, it's crazy to stick hooks on every part, so it's not even a joke in other industries, because no one else is going to do that.

However, in software design ... This kind of thing is so much to see that the object-oriented leader will recommend others to do so (so understand object-oriented programming); see many big players in the industry have to stand out and scold "object-oriented is a scam."

Designer Spit Groove: Object-oriented Programming there's a problem in the bones.
"Object-oriented programming is a very bad idea, and only people in Silicon Valley are capable of doing this." "-edsger Dijkstra (Turing Award winner)

Edsger W. Dijkstra

With such a heavy mental burden, this is clearly an object-oriented sin.

The disadvantage of object-oriented