Design Patterns Learning Notes-basic Knowledge Chapter

1. The importance of design patterns

The 1.1 design pattern solves the specific software function in the software process. There are many ways to achieve the same function, which design is easy to extend, easy to reuse, loosely coupled, maintainable? Design Patterns Guide us to find the best solution.

1.2 Design flaws are often found in designs that include:

Rigidity: It is difficult to make changes to the software, even if it is a small change in function

Vulnerability: can cause problems in many places when minor changes occur

Stubbornness: The effort and risk of separating some of the common functions of the system is huge

Viscosity: When faced with changes, there are many changes in the scheme, some will maintain the design, some will destroy the design, when the use of maintenance design method than the destruction of design methods more difficult to cope with changes, the original design has a high viscosity

Obscure: The module is difficult to understand

Unnecessary duplication: Code cannot be reused, often using copy-paste to achieve similar functions

Unnecessary complexity: The design contains unused ingredients that are often caused by over-design

1.3 If you find the above problems (defects) in the development process, then you need to use design patterns to improve the original design, that is, to reconstruct the original design. If you are the original designer, then you also need to apply design patterns to find an optimal solution. The design pattern is not a programming language, it is the programmer's internal strength. Therefore, it is very necessary for a developer to learn the design pattern.

2. For beginners, the necessary knowledge preparation is essential and it is difficult to understand them without these foundations.

2.1 Object-Oriented basics

Design patterns are design guidelines for object-oriented programming, so to understand what is object-oriented before learning to design patterns, here is simply a list of the main object-oriented concepts, and if beginners have to consult the relevant information, for the veteran already know, right when review and comb it.

2.1.1 Three main features of object-oriented: encapsulation, inheritance, polymorphism

2.1.2 Classes and instances

2.1.3 Construction (destructor) method

2.1.4 Overloading

2.1.5 Access Modifiers

2.1.6 Properties/Fields/methods

2.1.7 Abstract class

2.1.8 interface

2.2 UML Class diagram

When learning design patterns, there is usually only a class diagram, so reading UML class diagrams is very helpful for understanding patterns. The following describes the relationships in UML class diagrams

　　

2.2.1 Dependency relationship (Dependency), denoted by a dashed line and arrows. such as animals (Animal) depend on air. There are several types of code that represent dependencies:

1) as a parameter

        PublicClassAir {Publicvoid Getoxygen () {Console.WriteLine (" get oxygen from air.  ");}} public abstract class< Span style= "color: #000000;" > Animal {///<summary> ///</summary> /// <param name= "Air" ></param> public void Breathe (air air) {air. Getoxygen (); } } 

2) defined inside the method

            <summary>                         ///The animal relies on air to breathe, instantiating new objects within the method void, air. Getoxygen (); }

3) static method invocation

            <summary>///             Call static method in method            void Test () {Classname.usestaticmethode ();}   

2.2.2 Inheritance Relationship (Inherit), denoted by solid lines and hollow arrows, such as Eagles (Eagle) inherited from Animals (Animal)

        <summary>//         Eagle inherits from Animal        class Eagle:animal {}   

2.2.3 Implementation Relationship (realize), denoted by a dashed line with a hollow arrow, such as Eagle to achieve flight capability (iflyable)

        <summary>         ///Eagle inherits from Animal        classvoid Fly () {Console.WriteLine (" Eagle can fly.") "); } }

2.2.4 The relationship between association and aggregation before talking about combinatorial relation

1) Association Relationship (Association): for two relatively independent objects, the relationship between the two objects is associative when there is a fixed correspondence between one object instance and some specific instance of another object. For example: The relationship between a company and its employees

　　　　　　

Code representation, implemented by instance fields or attributes

        Class Emplolyee        {public string name{get; set;}        }        Class/// private emplolyee[] employees;}    

2) Aggregation Relationship (Aggregate): It is a kind of correlation relation, it is a kind of strong association relation, emphasizing the relation between whole and part. For example, the relationship between the computer and the monitor is the relationship between the whole and the part, that is, the aggregation relationship

　　　　　　

Code representation, which is also implemented by instance fields or attributes

        PublicClassDisplayer {///<summary> //////</summary> public string Model {setpublic class computer { ///<summary> // ////</ summary> private Displayer Displayer;}    

3) Combinatorial relationships, which are a special form of aggregation, indicate that an instance of an object cannot be owned by two of all objects at the same time. As the above example: The eagle has a pair of wings, its wings can not belong to other eagles at the same time.

Code representation, which is also implemented by instance fields or attributes　　　　　　

        PublicClassWing {}///<summary>///Eagle inherits from Animal///</summary>Publicclass Eagle:animal, iflyable {private Wing leftwing; private Wing rightwing; public Eagle () {//< Span style= "color: #008000;" > The wings are instantiated in the constructor to prevent the wings from being changed leftwing = new wing (); rightwing = Span style= "color: #0000ff;" >new Wing ();} public void Fly () { Console.WriteLine ( " Eagles can fly.  "       

　　　　　　The difference between Association and aggregation: the two objects involved in an association relationship are at the same level, such as the relationship between a programmer and a computer is an association, not an aggregation, because the programmer is not made up of computers. The two objects involved in the aggregation relationship are at an unequal level, one representing the whole, and the other representing the part. The relationship between a computer and a monitor is a clustered relationship, because the monitor is part of the computer.

　　　　　　the difference between an aggregation relationship and a composition relationship is that the aggregation relationship is in the held object and can be held by another object. If a polymorphic computer can share the same monitor. The objects held in a composite relationship can only be referenced by one object and cannot be shared with other objects, and the life cycle of the object being held is also controlled by the owner, and when the owner is refactored, its object must be deconstructed with it.

Design Patterns Learning Notes-basic Knowledge Chapter