1.6 how the design pattern solves design problems

Chapter 1 Section 6 how to solve problems in design patterns the design patterns help object-oriented designers solve many problems encountered in daily development through different methods. The following are many problems and how to solve them using the design model. Find appropriate objectsObject-oriented Programs are composed of objects. An object contains data and processes that operate on the data. These processes are usually called methods or operations. When an object receives a request or message from a client, it performs related operations. The action of an object is driven by a request or message. A request is the only way to drive the object to perform an operation. Only the methods defined by the object can change its internal data. Because of these constraints, the internal state of an object is called encapsulated. It cannot be accessed directly and is invisible outside the object. A difficult step in the process of object-oriented software design is to break down a system into objects one by one. Tasks are difficult, because there are many factors to consider: encapsulation, granularity, dependency, flexibility, performance, scalability, reusability, and so on. These conflicting factors often break down the system. Object-Oriented Methodology provides many different methods. You can first describe the problem, then pick out the nouns and verbs respectively, and finally create the corresponding classes and operations; or you can focus on the functional responsibilities of each part of the system and the collaboration between them; alternatively, you can build a real-world model and then convert each part of it into a relevant object during system analysis and design. As for the best method, no one can make a conclusion, depending on the specific problem. During the design process, we created many classes based on the analysis model. After the design process is completed, many classes do not match in the real world, for example, a low-level class like an array. There are also many other advanced classes. For example, the Composite mode introduces an abstract wit to process classes that do not have physical objects in the real world. The design pattern helps you discover non-obvious abstract classes and capture objects of these classes. For example, some objects can be expressed as a process or algorithm, and as an important part makes the design more sexual, but these do not exist in nature. The Strategy Mode describes how to execute interchangeable algorithm libraries. State mode describes various states of an object as an object. These objects are rarely displayed in the initial stage of software design during analysis, it was not found until the design was completed in order to make the software more flexible and reusable. Determines the object GranularityThe size and quantity of objects can be very different. They can represent everything, the underlying hardware, and the entire application. How can we determine the granularity of an object? The design pattern can solve this problem well. The Fa-ade mode describes how to express a complete subsystem as an object. The Flyweight mode describes how to use the best granularity to support a large number of objects. Other design patterns also describe how to break a large object into several small objects. Abstract Factory mode and Builder mode respond to the request for creating an object and produce the object. Visitor mode and Command mode respond to the request for calling another or a group of objects.

Interface of the specified object

The declaration of each operation is composed of the operation name, parameter, and return value specified by the object, which is the characteristic symbol of the object operation. A set of all feature symbols defined by an object operation is called the interface of this object. An object interface represents a complete set of all requests that can be sent to the object. Any request must match a feature symbol of the object interface, it can be sent to this object.

A type is to assign the name of a specific interface. If an object can receive all the operations defined in the "window" interface, we will say that this object has the "window" type. An object can have many types, and objects with large differences can share one type. It may also be that some object interfaces have one type, while the rest have other types, while two objects with the same type only need to share their public interfaces. An interface can also contain other interfaces as sub-interfaces. The former is called the parent type or the former is called the Child type. We often say that a child type inherits its parent type interface.

 

An interface is the basis of an object-oriented system. An object can only be accessed from the external interface of this object. In addition, there is no other way to access any element of the object or allow it to perform any operations. The interface of an object does not interfere with the execution of specific operations. Different objects can perform different operations on the request. This means that two objects can have the same interface but execute completely different operations.

 

When a request is sent to an object, the specific operation is dependent on the object sending the request and the object receiving the request. Different objects may have different implementation methods for the same request. The association between a request, an object, and an operation of the object at runtime is called dynamic binding.

Dynamic binding refers to responding to a request but not processing it until it is run. Therefore, you can write a program that waits for an object with a specific interface and knows that any object with the correct interface will process the request. In addition, the dynamic binding technology allows you to replace objects with the same interface when the program is running. This replacement is becoming a polymorphism, which is the core concept in the object-oriented system. Polymorphism assigns the responsibility to each client object, so that a client object not only supports specific interfaces, but also undertakes less responsibilities. Polymorphism simplifies the definition of client objects and reduces the coupling between objects so that the relationships between them can be dynamically changed at runtime.

 

The design pattern helps you define interfaces by identifying the key elements of each interface and the various types of data they send and receive, and it will tell you what cannot be put in interfaces. The Memento mode is a good example. It describes how to encapsulate and save the internal state of an object so that the object can be restored to the same state as the original one. This design pattern specifies that Memento objects must define two interfaces: one is the restricted interface for keeping client objects and copying mementos, one is a privileged interface that only source objects can use to save and retrieve states in memento.

 

The design mode specifies the relationship between interfaces. In particular, the design mode usually requires that some classes must have similar interfaces or forcibly constrain certain classes in interface settings. For example, the Decorator mode and the Proxy mode require that the interfaces of these objects be consistent with the objects decorated and proxies. In the Visitor mode, its interface must reflect the classes of all objects that the Visitor can access.

 

... (To be continued)