Initial Design Model

Document directory

• I. What is the design model?
• Ii. Object-oriented Design
• Iii. How the design model works
• Iv. Concepts in common design patterns

I. What is the design model?

Is there a feeling that when you encounter a problem, you often first think of a similar problem that you have encountered? This feeling comes from our past experience. We have grown up because we know how to sum up the past.

 

In all walks of life, the obvious difference between a Norton and a newbie is that when you encounter problems, the Norton can use previous experience to complete the work efficiently, quickly, and with high quality. New users may not be able to get started.

 

If you want to build a house, you should not study the concept of a house from the beginning. First, you should refer to the previous House, which has a window, roof, basement, walls, and room pattern. That is to say, there is a solution to some problems. If these models are summarized, they will serve as a guide to solve similar problems and provide solutions for related problems.

 

Design Mode: a general design scheme is proposed to address repeated Design Problems in the object-oriented system, and systematic naming and motivation explanation are given.

This solution is a set of well-arranged general classes and objects to solve the problem, which can be customized and implemented to solve the problem in a specific context.

It describes the problem, solution, and under what conditions the solution is used and its effect. In addition, some design patterns also provide implementation points and examples.

 

The design model has four basic elements:

Name: Used to visually describe the problems, solutions, and effects of the design model;

Question: Describes when the design mode is used;

Solution: describes the components of the design, the relationship between them, their respective responsibilities and assistance methods;

Effect: describes the effect of the mode application and the balance between the use mode;

 

Ii. Object-oriented Design

An Object-Oriented Program consists of objects, including data and operations on data.

 

For object-oriented problems, the first consideration in design is the encapsulation of objects. By analyzing the existing models in the real world, you can find the objects to be encapsulated. However, some non-obvious abstract objects do not exist in reality, but they are easy to implement the flexibility of the problem in design.

 

The object operation method is usually implemented in the form of a function, and the set that abstracts the function structure is the interface of the object. The interface describes the set of all requests that an object can accept. Any request that matches the function structure of an interface can be sent to this object.

 

The Interface Design usually involves the concept of import type, which is used to indicate the name of a specific interface. A truck accepts the interface of a vehicle. It can be said that a truck is a vehicle type, but it can also accept the interface of a vehicle. This indicates that an object can be of multiple types and the type can be inherited.

 

An object uses a specific interface at runtime to become a specific type, that is, dynamic binding. The feature supporting replacement of objects of the same type and different objects is called polymorphism.

 

The implementation of an object is determined by its class, and the class also defines the status and operation Implementation of the object.

But the object type is only related to its interface. The class defines the object operation, and naturally defines the object type.

 

For class inheritance, the basic mechanism of application functions can be extended by reusing the parent class function. However, it is very important to describe the classes that all sub-classes share interfaces. This type is usually implemented using abstract classes. An abstract class places the implementation of an interface in its subclass, so it cannot be directly instance as an object.

When the inheritance is used properly, all Classes exported from the abstract class will share the interface of the abstract class. This means that the subclass only adds or redefines the operation implementation, and does not hide the operation of the parent class. At this time, all subclasses can respond to the request of the interface in the abstract class, that is, the subclass object can be of the abstract class type.

Therefore, instead of declaring a variable as an instance object of a specific class, the variable complies with all the interfaces defined in the abstract class, thus implementing dynamic binding.

In this way, interface programming is targeted, rather than implementation programming. The object user does not need to know the specific type of the object, but only needs to know whether the object has an interface that meets the conditions for use; you do not need to know what classes the object uses to implement. You only need to know the abstract class that defines the interface.

 

Iii. How the design model works

In the above object-oriented design, the use of design patterns can usually be good guidance for object encapsulation.

The system can be well decomposed into a collection of objects, including many design factors: Object granularity, dependency, flexibility, performance, evolution, reuse, and so on.

 

For the reuse mechanism, there are three implementation methods:

Inheritance: Reuse the parent class by inheritance (white box reuse ). It can be used during compilation, but it cannot implement the parent class during runtime. In addition, inheritance reveals the details of the parent class and destroys encapsulation in a certain sense;

Combination: creates an object composed of other objects (Black Box multiplexing), dynamically binds it during runtime, and keeps each class encapsulated;

Template: it also becomes a parameterized type, which can be reused by instantiating the parameter type;

Generally, the combination takes precedence over inheritance. The combination can implement inheritance in the way of delegation:

For example, there is a window type win and a rectangle class Rec. The win object contains a rec object. The win class can define area () to call the area () of the REC object to return the window object area;

Here, win contains rec, instead of inheriting Rec. The object receiving the request delegates the operation to its proxy.

 

The design mode can be used to guide the selection of reuse methods based on object-oriented design issues. Other factors that affect design are also considered.

 

Iv. Concepts in common design patterns

1. Framework: A group of collaborative classes that can be reused and designed for specific software.

Different from the design model:

The design pattern is more abstract than the framework. The framework can be represented by code and often executed;

A design pattern is an architectural element smaller than a framework. A framework may contain multiple design patterns, but not vice versa;

The framework is more special than the design mode, such as the example editor framework and a certain type of game server framework;

 

2. Aggregate object: an object that contains sub-objects. These sub-objects become part of the aggregate object, and the aggregate object is responsible for them.

 

3. Aggregation relationship: the relationship between the aggregation object and its part. Class defines this relationship for its objects.

 

4. Coupling: degree of dependency between software components.

 

5. acquaintance relationship: If one class points to another class, the two classes have an acquaintance relationship.

 

6. Class diagram: describes the operation of the class and its internal structure, and the static relationship between classes.

Triangle: indicates the inheritance relationship, and a -- |> B indicates that a inherits B;

Diamond Arrow: indicates the aggregation relationship. A ◇ --> B indicates that object A contains an object B;

Solid Arrow: indicates the acquaintance relationship. A --> B indicates that a has a reference pointing to B. object B may be shared by multiple A objects;

Dotted Line Arrow: Indicates creating a link...> B indicates that Class A has created Class B, which is also expressed by solid line;

Dot: indicates more than one dot. A ◇ --> · B indicates that an object contains multiple B objects;

 

7. object graph: Describes the object structure specific to the runtime.

 

8. Interaction diagram: displays the request process between objects.

 

 

The above content comes from the arrangement of the book "design model: Reusable basis for Object-Oriented Software", because I am a poor bank and have no money to buy books, after reading it, I can't remember it. I just sorted out a note here.