[ASP. NET Introduction 6] inter-class relationship of the OO idea

Great navigators
-- Inter-class relationship of OO ideas

Multi-Dragon cloud: the relationship between me and Wei Chunhua is pure. Netease said that the relationship between me and my friend is a two-way training selection system; yang zhenningyan's Thought of The Book of Changes hinders the development of modern science in China. logistictheory: There are five types of relations between concepts: the same, inclusive, cross, separated, and mutually exclusive. Conway believes that the relationship is an ordered couple.

■ I need to be lazy and stupid-the ultimate goal of Program Design

Not long ago, in the csdn community, the article entitled "is such a programmer a qualified programmer?" Hot post, the landlord said that coding takes more time than others, but the code specification is robust, ask such a programmer can be used and how to use it? There was a sudden increase in the discussion of what is the program design goal and related project management in a specific environment in China. The mind catcher uses Mao's contradiction theory to analyze: "This is a conflict between the market and programmers." He said, "If it is a small company, don't talk about development ...... Time is the first productivity ...... If not ...... First, we solved management and budget problems. "I began to wonder how it was handled.

Regardless of the market factors, the primary goal of programming is to successfully solve a real problem. It is important to note that this real problem often changes dynamically and over time, so our code should be robust enough to adapt to this change process, instead, we should not aim at solving the real problem of a static point. Second, the Code and its structure should be concise. Only concise can make the writing easy, easy to modify, and easy to maintain, the maximum cost is saved, and the code should be reused. The greedy idea is that the Code can not only be reused to reduce repetitive work in a real problem, it can also be used repeatedly across different real-world problems. Finally, people's understanding of the world is an iterative process and the changing real-world problems, therefore, the program should be easy to expand without affecting the original code.

In theory, you can understand "Everything is object, everything needs to be encapsulated". Based on the experience in the process, you can start to solve any real problem, but you will find that during the entire development process, based on the current knowledge and insights, you will be entangled in a large number of complicated problems until you give up, but these can be completely avoided! Whether this theory or the design model, the ultimate goal of all previous experiences is to make the program design more concise, easier, and faster, why do many outstanding programmers claim to be "lazy + stupid" is not hard to understand.

■ Separation relationship-class encapsulation and dependency

Things in this world cannot be scattered in the vast ocean like Robinson islands. On the contrary, even the most remote motuo County in China is still closely related to the motherland. In suixiang 5, we know how to organize things in the real space into objects and abstract them into classes, and then sort out the relationships between them.

First, we focus on the significance of encapsulation from the perspective of program design goals. From the perspective of navigators (class users), he does not need to understand the internal structures of islands, such as geography and Society (Dimit LawLaw of Demeter), you only need to know what island production and what (the function of the class), and who to buy and buy (the Public Member interface, knowing this can quickly build a business network (designing applications ). As the ruler of the island (the real-time person), he does not have to pay attention to the ups and downs of the outside world, but only needs to focus on the Production and Consumption management in the island. The ruler calls this phenomenon High.Cohesion.

Closed greatly simplifies the complexity of program design. Inter-class communication is carried out through a narrow, well-qualified interface to ensure the reliability of the class. On the one hand, class users collect classes to quickly develop programs without attempting to change the internal structure of the classes. On the other hand, the class implementers can freely modify their internal working methods without modifying the Public Member interfaces.

However, it makes no sense to separate classes! The most common relationship is that a type of instance uses another type of instance. If the merchant ship Titanic needs to provide cargo on the island of Hawaii, then we call it a merchant ship.Dependency(Dependency) goods are provided on the island, as shown in 1, and the problem that arises is that if the island is in turmoil (the implementer of the class modifies the Public Member Interface ), it will directly affect the normal operation of the Titanic, and we will have to re-organize the internal structure of the merchant ship to adapt to changes.CouplingIt is a measure of the degree of inter-class dependencies. For classes with high change possibilities, we should avoid high coupling when dealing with dependencies.

■ Concept inclusion and crossover-merging and Inheritance of Classes

Stupid people cannot understand an object full of various complex functions, so the first design principle of the class is single, corresponding to a concept in the problem space. If the corresponding concept includes other concepts, which are the integral/partial relations called "has-a", we will consider the instances of these classes.Synthesis(Composition) a new class. For example, if a merchant ship has a power device, we will instantiate a power device class, plus other attributes and Methods except the power device category, that is, the synthesis merchant class, 2. Merging has great flexibility and does not destroy the encapsulation of classes. Therefore, we should try our best to use merging, instead of using the inheritance described below (Merging Reuse PrincipleComposite Reuse Principle ).

When I was a child, there were few ways of entertainment. In addition to the landscape, the most popular old movies were old movies with war themes of the 50 or 60 s. The faces in the old movies were so severe that I always thought that, there are only two types of people in this world: good people and bad people. If this idea is true, the synthesis will go forward. But in this world, not all are simply superimposed by some parts. Now let us assume that ships in this world have only two purposes: merchant ships and war ships. From the conceptual perspective, they have the similarity, that is, concept crossover, 6-3 left, at the same time, they also have their own characteristics. If we simply abstract the merchant ships and war ships into two classes, a large number of Class Members will overlap, therefore, we need to construct a mechanism to reflect the cross relationship between the two concepts. This isInheritance(Inheritance) is called "is-".

Inheritance is characterized by hierarchy. It looks like a Genealogy Tree in the shape of a graph. However, it is silly to use a genealogy tree to represent inheritance. It does not really reveal the essence and process of inheritance, it is a general process to a special process, as shown in 3 on the right. It is said that all humans are descendants of an ancient ape in a non-state. We will not discuss the facts or not, but it is similar to the following ,. all classes of net are directly or indirectly derived from the same base class-object class.

The most intuitive use of class inheritance is reuse ,. NET technology gives us the first image of more than five thousand public classes that Ms engineers have developed over a long period of practice. For applications, it covers almost general concepts in all fields so far. On this basis, through appropriate inheritance and synthesis, we will soon be able to build our own class systems.

Let's look at the class from the perspective of the member set. For synthesis, the member set is as follows:
Merchant Ship {location, ship direction, power device {power value}, move (Direction )}
The reference power value needs to be expressed in this way: merchant ship, power device, and power value (you can try to read "." into "). For inheritance, the member set is as follows:
· Merchant ship {maximum volume of transportation, loading (goods), moving (Direction )}
· Warship {firepower value, battle (SHIP), move (Direction )}
It can be seen that the Public Member of the ship class becomes the Public Member of the merchant class, expressed as: merchant ship. Mobile, while the private Member of the ship class is hidden in the merchant class. The reason for this is that because ships can move and merchant ships are ships, merchant ships can also be moved (the famous Socrates field theory ). Sometimes we want the derived class to access a member of the base class but hide the world outside of the class, such as the speed of the ship and the speed of all kinds of ships, therefore, the speed should be a base-class member, but we do not want external factors to directly modify the speed value in a computer system that destroys the speed (it is also affected by internal and external factors, so we introduce the third Access Controller.Protected.

There is an interesting method for a war ship: The battle (SHIP), the interface parameter is an instance of the ship class, that is, the war ship can fight with any type of ship, the render manager is your merchant ship or the war ship, so we can use this method: Bismarck. battle (Titanic), that is, the child type can replace the base type (it can still be proved by the Socrates Field Theory). This replacement method is calledRishi replacement principle(Liskov substitution principle) is used to reduce the complexity of method implementation.

There is an important defect in the Inheritance Mechanism. The base class and the derived class are strongly coupled, And the encapsulation is damaged. The problem arises: if the base class is modified due to improper design, it will affect all the derived classes. In addition, it may take half a day for a member of the derived class to find the layer where it is implemented, so during the design process, first, we should try to compress the layers of inheritance. Second, we should adhere to the principle of merging and reuse, so that we do not need to inherit the layers that can be merged.

■ Class View of the login class