Object-oriented design

Ood is the continuation of the Ooa method, whose basic ideas include abstraction, encapsulation, and extensibility, in which extensibility is achieved mainly through inheritance and polymorphism. In Ood, the data structure and the operation algorithms defined on the data structure are encapsulated within an object. Because things in the real world can be abstracted out of objects, the Ood approach is a more natural way of designing systems that are closer to the real world.

Design Software class

A class encapsulates information and behavior and is an important part of an object-oriented, generic term for a collection of objects with the same properties, methods, and relationships. In the system, each class has a certain responsibility, which refers to the task that the class holds. A class can have a variety of responsibilities, and well-designed classes generally have at least one responsibility to break down the responsibilities of a class into classes ' properties and methods when defining a class, where properties are used to encapsulate data, and methods are used to encapsulate the behavior. The most important component of Ood in the design class is also the most complex and time-consuming part.

1. Entity classes

The entity class maps each entity in the requirement, and the entity class holds the information that needs to be stored in the persistent storage body. Entity classes are usually permanent, and they have properties and relationships that are long-term and sometimes need to be in the entire life cycle of the system.

An entity class is the most meaningful class for a user, usually named after a business domain term, typically a noun, in which a participant generally corresponds to an entity class in a use case model to a domain model transformation. It is often possible to start looking for entity classes from those in the SRS that correspond to database tables (which require persistent storage). Typically, an entity class must have an attribute, but not necessarily an action.

2. Control class

A control class is a class used to control the work of a use case, usually a noun that is transformed by a goose phrase ("verb + noun" or "noun + verb") of the dynamic-object structure, for example, the use case "authentication" can correspond to a control class "authenticator", It provides all the operational control classes associated with authentication to model the control behavior specific to one or several use cases, and control objects (instances of control classes) typically control other objects, so their behavior is coordinated.

The control class encapsulates the unique behavior of a use case, and the behavior of the control object is closely related to the implementation of a particular use case, and when the system executes the use case, it produces a control object that often dies after its corresponding use case has been executed. Typically, the control class has no attributes, but there must be a method.

3. Boundary class

Boundary classes are used to encapsulate information or data flows that flow inside and outside of a use case. The boundary class is located at the junction of the system with the outside world, including all forms, reports, printers and scanners and other hardware interfaces, as well as interfaces with other systems. To find and define boundary classes, you can examine the use-case model, with at least one boundary class for each actor and use-case interaction, and boundary classes that enable participants to interact with the system. A boundary class is a class that is used to model the interaction between the external environment of the system and its internal workings. Common boundary classes are windows, communication protocols, printer interfaces, sensors, and terminals. In fact, when the system is designed, the resulting report can be handled as a boundary class.

Boundary classes are used for system interfaces to interact with external systems, and boundary objects separate the system from its external environment (for example, changes in interface with other systems, changes in user requirements, and so on) so that these changes do not affect other parts of the system. Typically, boundary classes can have both properties and methods.

Object-Oriented design principles

For the design of OO system, it is a crucial problem to improve the reusability of the system while supporting maintainability, and how to improve the maintainability and reusability of the system at the same time is one of the core problems that ood need to solve. In Ood, the reuse of maintainability is based on design principles. The common Ood principles include the open and close principle, the Richter replacement principle, the dependency inversion principle, the combination/aggregation multiplexing principle, the interface isolation principle and the least knowledge principle. These design principles are first and foremost a reuse-oriented principle, and adherence to these design principles can effectively improve the reusability of the system while improving the maintainability of the system.

1. Opening and closing principle

The open and closed principle means that software entities should be extended in response to the extended opening, and to the modification, as far as possible without modifying the original code. The "entity" here can refer to a software module, a local structure consisting of multiple classes, or a separate class.

The application of open and closed principle can extend the existing system, and provide new behavior to meet the new requirements of software, so that the changing system has some adaptability and flexibility. For the existing software modules, especially the most important abstraction layer module, can not be modified, which makes the system in the change has a certain degree of stability and continuity, such a system at the same time to meet the reusability and maintainability. In Ood, the open and close principle is generally realized by adding abstraction layer (for example, interface or abstract class) to the original module, which is also the basis of other ood principles, and other principles are the concrete measures to realize the open and closed principle.

2. The Richter replacement principle

The Richter replacement principle is proposed by Barbara Liskov, which basically means that if a software entity is using a base class object, it must apply to its subclass object, and the difference between the base class object and the subclass object, that is, the base class is replaced by all of his subclasses, the behavior of the program does not change. The reverse is not necessarily true, and if a software entity applies a subclass object, it does not necessarily apply to the base class object.

When using the Richter scale substitution principle, try to design some classes or classes that need to be extended as abstract classes or interfaces, and use them as base classes to program the base class objects as much as possible. Because of the subclass base base class and the way in which it is implemented, when the program runs, the subclass object can replace the base class object, and if you need to modify the behavior of the class, you can extend the base class and add new subclasses without modifying the code that invokes the base class object.

3. Dependency Inversion principle

The dependency inversion principle means that abstractions should not be dependent on detail, and details should be dependent on abstraction. In other words, you want to program for the interface, not for the implementation. When passing parameters in program code or in a combination (or aggregation) relationship, try to refer to a high-level abstraction layer class, that is, using interfaces and abstract classes for variable type declarations, parameter type declarations, method return type declarations, and data type conversions, rather than using specific classes to do these things. To ensure the application of this principle, a concrete class should implement only the methods declared in the interface and the abstract class, not the redundant methods, otherwise, the new method added to the subclass cannot be called.

The key to realize the opening and closing principle is abstraction, and the concrete realization from abstraction, if the principle of Ood is the goal, then the principle of dependency inversion is the main mechanism of Ood. With the abstraction layer, can make the system has very good flexibility, in the program as far as possible to use the abstract layer programming, and the specific class written in the configuration file, so that if the system behavior changes, then only need to extend the abstraction layer, and modify the configuration file, without modifying the original system source code, without modification of the situation to expand the system function To meet the requirements of open and closed principle. The dependency inversion principle is one of the basic principles behind the technologies and frameworks of COM, CORBA, EJB, and spring.

4. Combination/Aggregation multiplexing principle

The combination/aggregation multiplexing principle, also known as the synthetic multiplexing principle, is to use some existing objects in a new object by combining them into a single part of the new object, and the new object is reused for its existing functions by delegating methods that call existing objects. Simply put, use the combination/aggregation relationship as much as possible, with less inheritance.

5. Interface Isolation principle

The principle of interface isolation refers to the use of multiple specialized interfaces rather than a single total interface. Each interface should assume a relatively independent role, not too much, do not do what should be done, the job is to do all.

6. Minimum knowledge principle

The least knowledge principle is also known as the Dimitri Rule (law of Demeter)

　　

Object-oriented design