ASP.net Once upon a time, we live in the land of sleeping in the seabed, the mainland is also closely linked together, thousands of years have passed on the seven continents of the crustal plate slowly moving, the Himalayas slowly increased, the world is changing, the only constant change.
The paradox of software development-turning change into a plan
In the process of software development activities, is often entangled by a paradox: Do not write code can not understand what to do, do not know what to do and how to write code.
People's thinking is a very casual thing, different people, or the same person at different stages of the same thing, the views will be different, can be described as far from the ridge side into the peak, the difference in height and distance. Random plus changes often cause a project miscarriage or the duration of a significant delay.
The reason for software engineering is to try to save our dead brain cells and the lost renminbi. Cim/iso bureaucracy, each link must carry out the so-called scientific management and evaluation, quality is poor on rework, strive for each kind of construction activity only once. The difficulty is that development activities are difficult to quantify, the so-called evaluation is often everyone together to the wine table, some of the early errors in the subsequent infinite amplification; some elephant of commercial-driven RUP, requiring the shortest time to spell Einstein's rough first stool to the user, confirmed on the basis of the continuous cycle of reconstruction, Until the user satisfied with the nth, the need for a large number of users to participate, but the user is not a software engineer to grasp the complex activities of the program, it is difficult to them. In short, both have defects, correction errors and iterative development is inevitable, so the software architecture design at the beginning of the need to consider adapting to changes in demand, force will change the impact of reducing to the minimum. The OO development paradigm is roughly: dividing objects → abstract classes → classifying class organizations into hierarchical structures (inheritance and synthesis) → using classes and instances to design and implement several stages. In this process, the proper use of OO language will affect the adaptability of software to demand changes, and its use of proficiency is often the benchmark for evaluating software developers.
As far as possible away from switch-polymorphic and abstract classes
The foundation of OO thought is to treat objects with States and methods as elementary particles of the system, and to describe the behavior of the system by interaction (or communication) between particles. Typically, methods define method interfaces and implementations in the scope of a class, and are used to modify the state of a class, such as: Titanic. Move (direction), the method is the class of supporting, for class services, that is, class methods.
The method of a class may have many forms, as long as the signature (return value and argument list) is different, we can use method overload to achieve the unity of concept (method name), such as: Titanic. Moving (direction) with the Titanic. Moving (direction, current), the implementation of these two conditions is different, but as the user concept of the class, It's all Titanic moving. In the process-oriented era, the polymorphism of a method is often handled by a switch statement.
At the beginning of structured language, unstructured language was heavily attacked and focused on a single statement--goto. Say it destroys the organization of the program, as if it were the root of all evils; Similarly, more than 10 years later, when Oo language became popular, people also found a statement to criticize it as a rigid poison, It is the switch statement. Switch statement is a typical structured programming idea, the common properties of many modules are mapped to a point in the domain of the flag variable, simply arranged in a piece, the following example:
Switch (ship type) {
Case "merchant Ship"
Mobile computing method of merchant ships; break;
Case "warship."
The mobile computing method of warships; break;
}
In the example above, the problem with the switch statement is that it murders many ships. The structural nature of mobile computing methods lacks the abstraction necessary for similar methods. The consequence is the presence of its bloated figure everywhere. Once demand changes, we have to search around and fix it.
The Move method here is actually a public method of the ship's class system. As a user of the class system, he must want to be the same as the overload of the concept (method name) of unity, and by the signature of the method to distinguish between the merchant ship or warships are moving, so we adjust the following:
void control movement (ship class ships) {
ship. Moving;
......
}
Warship Bismarck = new warship ();
Merchant Marine Titanic = new merchant ship ();
Control movement (Bismarck);
Control movement (Titanic);
In the control movement (Titanic) method, we replaced the ship with the Move method of the merchant ship. This is actually the Richter substitution principle mentioned in "Random Six", where the subtype can be substituted for the base type. The polymorphism of the class system method is implemented by the upload (upcast) mechanism, as shown in Figure 7-1. As with overloading, it is done automatically by the OO language.
Upload mechanism has a very intuitive advantage, if the ship base class and temporarily increase the race ship subclass, we do not modify the existing code on the premise of easy completion of the original software expansion, that is, "open-closed" principle (open-closed principle). Adding the following code does not affect the control Move method:
Regatta Magellan = new sailing boat ();
Control movement (Magellan);
Only so the function extension does not affect the control movement method, because the control movement method relies only on the ship class system base class. If the common methods of a class system are concentrated, are defined as abstract classes (abstract), other classes only have dependencies on abstract classes, as long as the method interface of an abstract class is unchanged, and the internal adjustment of its inherited subclasses does not affect the external use, and the maximum extent to which the outside and the architecture of the class system (when referring to dependencies) stabilizes. As an abstract class, it has two important characteristics: one is that the interface definition is not implemented, and the second is that subclasses (Non-abstract class inheritance) must implement all the methods of the abstract class. Abstract classes cannot be instantiated, and there is no need to instantiate, just a empty shelf toss what ah.
I'm the lead-interface and delegate
Oo thought of the general emphasis on class as the protagonist, the method is a kind of supporting role, especially the abstract class system, the base class and all subclasses are strong coupling relationship, if it falls, the heart will disperse, the team is difficult to bring. Once the abstract class needs to be changed (the public method of adding a pruning class), the impact on a software architecture is no less than Russia's shock to Europe over the price of Ukraine's gas, which could bring about a domino effect. When the method is not only one but the abstract of the public behavior of multiple classes, we must upgrade the supporting method to the protagonist, and let it dominate the related class system by independent of the common method interface, defined as the interface (interface), and then implemented by the related class one by one. Then we can call it the class of the method. All external relationships are no longer based on abstract classes but on interfaces, as shown in Figure 7-2. When defining an interface, be careful not to overdo it, and a class's dependency on another class should be based on the minimum interface. Complex interfaces can be separated by multiple inheritance or delegation of interfaces.
The reason why the method is upgraded from a supporting role to the protagonist is because we want to isolate the unstable components in demand and construct the system with relatively stable components as a framework. The life cycle of a general concept is much larger than that of a particular concept, such as position > CEO > Xingdong, so it relies on abstraction rather than on concrete, that is, the dependency inversion principle (dependence inversion principle), as discussed earlier "open-closed" Principle is its extension.
Furthermore, although the method changes from a supporting role to a protagonist, its implementation is in the scope of the class. Sometimes the method is more out of line, the delegate class in addition to defining the method signature and notify its start message, the implementation of the method completely out of control, it even came to the stage to know today's protagonist is who. This is the principal (delegate) mechanism. The essence is a method of directly referencing another class, so long as the delegate method is consistent with the Trustee method interface, the purpose is to completely separate the interface of the method from the implementation.
Class merchant Ship {
Delegate class
private int power;
Private delegate int resistance calculation delegate (); Define delegate public void movement (resistance calculation delegate resistance) {
int force = force-resistance ();
......
}
}
Class test{
Trustee Class
private int Wind resistance calculation () {...};
static void Main () {
Merchant ship Titanic;
Titanic. Mobile (new resistance calculation delegate (wind resistance calculation)//Delegate Instance
}
}
Delegates can be so understood, in the example of the Merchant Shipping class for the principal party John, Test class for the trustee Li Lawyer, John (merchant) said I want to sue Harry (resistance calculation commissioned), Li lawyer chest a beat: No problem, I follow the Civil procedure (Wind Resistance calculation method) to do.
