add missing attributes, specify the type and visibility of the property:
In the object-oriented design phase, you need to design each class in detail, omit attributes from the process, and determine the data type of each property, specify the visibility of each property, and the visibility of the property refers to the external object's access to the property, generally including private, protected, and several types;
In real-world development, except for simple and infrequently changing attributes that can be exposed directly to customers, other properties are best set to private or protected and preferably packaged with access methods such as GetXXX () and setxxx ().
assign responsibilities and define how each responsibility is performed:
Responsibility: is a class or type of contract or obligation
The responsibilities of a class in an object-oriented system can be divided into two main categories: To do the job, to do something, to provide some kind of service to other objects, to send messages to other objects, to provide some kind of tiger, to control and coordinate the services of other objects; knowing what data is inside Know which objects have a relationship with themselves
Knowing the type of responsibilities is manifested by the properties of the inner encapsulation of the class and the relationships between the classes, so the previous discussion of the properties of the class and the relationship between the classes is the process of assigning the known responsibilities to the classes in Fishigui.
Job-making is done by means of a class, in order to assign job-making responsibilities, you need to analyze what services each class should provide for other classes, what the classes themselves contain, what they should do, and then use the corresponding methods in the class to implement those responsibilities.
generic responsibility Allocation software model (GRASP):
The general responsibility assignment software model describes the effective experience and basic principles of assigning responsibilities to different objects in the system in object-oriented design. The GRASP model mainly includes the following 9 main modes:
- Expert mode: Responsibilities should be assigned to an information expert, that is, when assigning a duty, you should understand what information is required to perform that responsibility, which class or classes are used enough. If this information is owned by a class, assign responsibility to it, and if it is owned by more than one class, assign a responsibility to each class, and then use messaging and interaction to make these classes work together to accomplish that responsibility
- Creator mode: As required by creator mode, if Class A and Class B meet one of the following conditions A aggregates a B object, a contains a B object, a property of a has a record of the B object, a B object is used frequently, a B object is created, a is passed initialization data to the B object . then we can assign the responsibility of creating the B object to the A object, because the existence of the above relationship does not increase the coupling of the system by adding the responsibility of creating the object . in the Fishigui system, because Fg_timermanager aggregates multiple fg_timer, the creation and destruction of timer objects should be fg_timermanager to be responsible for
- Low coupling: The low coupling here is primarily the degree of association between classes and classes, where one class knows other classes, depends on the strength of other classes, and the coupling between Class A and Class B consists of the following: The parameter of a method of Class A refers to Class B or a method within which a local variable of class B is defined; an attribute of Class A references an instance object of Class B; a property of Class A aggregates multiple instance objects of Class B; Class A is b Indirect or direct derived classes. the coupling between the above couple is more and more strong, and the inheritance is the strongest one.
- High cohesion: Cohesion refers to the degree of correlation or concentration of the various responsibilities of a class, in general, the high cohesion of the class should contain only a few method trees, the degree of association between the method is very high, each method undertakes not too much work, the task is relatively single; when we find that a class takes on too many tasks, Too miscellaneous should assign some responsibilities to other classes, so as to guarantee the high cohesion of the design scheme
- Controller mode: The controller mode requires that the coordinate processing system messages be assigned to different control classes
- Polymorphism: When a duty behaves differently in different derived classes, we can use polymorphic patterns, that is, by using a polymorphic method of the same name to assign that responsibility to different derived classes and let them perform different behaviors
- Pure Fiction: can make up a man-made class, assigning a set of responsibilities for the cohesion of the cover to him, the man-made class is a fictitious transaction, does not represent any entity in the real world, is purely fictitious mode
- Broker Mode: Assign some responsibilities to a fictitious mediation class that allows the mediation class to coordinate multiple classes of collaboration, using the Mediator class to isolate multiple classes that can be separated by the coupling, which is prone to changing objects without affecting other objects
- Don't talk to strangers: This pattern requires a class to interact with its direct objects as much as possible, to avoid interacting with indirect objects, so that it can be coupled with the fewest classes, keeping the coupling of the whole system to a minimum. The guideline requires that, in a method of an object, you can only send a message to the following objects: the object itself; an element of the object that is an attribute of the object, an object of one of the objects in the property collection, and one of the objects created in the method
for message-driven systems, clear message delivery methods:
Object-oriented design can easily result in an increasing number of relationships between objects, resulting in complex network structures. The complexity of the relationship also leads to increased coupling between classes and objects, and a message-driven design can be a good way to cover these flaws, especially for graphical user interface frameworks such as Fishigui, where the message from operating systems such as keyboard and mouse is one of Fishigui's responsibilities. In object-oriented technology, these external hardware and software messages are mapped together with the internal communication of the Fishigui system as a message passing between classes and objects (method calls). To use a message-driven design approach, we construct the same message structure in Fishigui to encapsulate the various messages that the operating system sends to the FISHIGUI framework and the internal Fishigui framework system. All of these messages are passed between the operating system adaptation layer, the framework layer and the application layer, which drives the system to function properly. (in Figure 7-15, the dashed arrows between the layers and the layers represent the message from the lower layer, the double solid arrows represent the way the framework layer uses the services provided by the adapter subsystem through function calls, and the single solid arrow represents the application layer using the services provided by the framework layer through inheritance and function calls)
use design patterns for local design:
In the process of object-oriented design, we should try to use mature design patterns to optimize the local design of the model:
- Use appearance mode to add a unified interface to the adapter subsystem;
- By implementing the Observer pattern, the adapter subsystem sends messages to the framework layer without having to rely on the concrete implementation of the framework layer;
- For classes that exist in the system with only a unique object instance, a single-piece mode is used;
- The structure of window elements is a typical composite pattern;
- Use a template to implement an aggregation structure, such as a screen that contains multiple windows, with multiple spaces in the window ... and use the iterator pattern to traverse each of these word elements, using the Create pattern to assist the application layer to create the control, enabling the application layer to flexibly change the appearance of the control;
- Use the responsibility chain mode to distribute messages from screen objects to window elements such as window controls;
- The process of sending messages from a screen to a window element, such as a window control, is equivalent to transferring the message from the framework layer to the application layer, so in order to eliminate the dependency of the framework layer to the application layer, we first use the virtual function acceptance function provided by the responsibility chain pattern to achieve polymorphism. Then, the structure is optimized by using the control inversion characteristic provided by the template method mode.
- In the process of porting the adapter subsystem to the DOS operating system, we used the adapter mode to adapt the message management mechanism to a completely different operating system;
- When designing the business logic of the application layer, we use the MVC pattern
Object-oriented design step two-------specify the type and visibility of attributes, assign responsibilities (GRASP), message-driven, design patterns for local design
