Code overview-design

5.1 design challenges

1) "sinister" Problems are those that can be identified only by solving or partially solving them. That is to say, it is only known once.

2) because of the endless design, the most common answer to the above questions (when is good enough) is "until you have no time to do it ".

3) some of the key points of design are the creation of possible things, and the other part is the limitation of possible things.

4) the design process is full of uncertainty, so the design technology tends to be exploratory-"empirical Law" or "implementation may work"-rather than a repeatable process that can generate expected results.

5.2 Key design concepts

1) management complexity is the most important technical topic in software development.

2) for software developers, we should not tryProgramInstead, they should try to organize programs in some way so that they can focus on a specific part at a time. The purpose of doing so is to minimize the number of programs to be considered at any time. You can think of it as a psychological juggling program. The more balls you maintain in the air, the more likely you will miss one of them, this leads to design or encoding errors.

3) at the software architecture level, the entire system can be divided into multiple subsystems to reduce the complexity of the problem. The less dependencies between subsystems, the easier it is to focus on a small part of the problem at the same time. Keeping subprograms short and concise can also help you think less. Starting from the problem field rather than starting from the underlying implementation details to write programs, working at the most abstract level can also reduce the mental workload of people.

4) once you understand that any other technical goal in software development is less important than management complexity, the multi-design considerations become straightforward.

5) Ideal Design Features: Minimal complexity, easy to maintain, loose coupling, scalability, reusability, and high fan-in (a large number of classes use a given class) low fan-out (using a small or moderate number of other classes in a class), portability, and streamlining (ask a key question: although simple, but what will it do if I add it? ")

Hierarchy: hierarchy means to maintain the hierarchy of each decomposition layer of the system as much as possible, so that you can observe the system at any level and get a consistent view. The designed system should be able to observe at any level without entering other layers.

The hierarchy is as follows: Software System-> subsystem or package-> class-> data and subroutine-> subroutine.

Subsystem: pay special attention to the rules for communication between different subsystems. If all subsystems can communicate with other subsystems, the benefits of separating them will be completely lost. We should limit the communication between subsystems to make each subsystem more meaningful.

Common subsystems: Database Access (hiding database access), subsystems on which the system depends (isolating all system calls );Subsystems that hide implementation details can provide a valuable abstraction layer for the system to reduce program complexity.

Class in the package: the main task involved in this layer is to properly break down all subsystems and ensure that the detailed information is exactly the same. A single class can be used for implementation.

Data and subprograms in the class: defining the internal subprograms of the class often helps to better understand the class interface, which in turn helps to further modify the class interface, that is, return to the class layer in the package.

5.3 design construction block: Heuristic Method

Abstract is a capability that allows you to focus on a certain concept while ignoring some of the details with confidence-to process different details at different levels.

From the perspective of Complexity: the main benefit of abstraction is that it allows you to ignore irrelevant details.

Excellent programmers can abstract the subprogram interfaces at the level of class interfaces and package interfaces.

The differences between object-oriented design and Information Hiding are more subtle than those between rules and temporary systems. Thinking based on the principle of information hiding can stimulate and promote the formation of some design decisions, but simply thinking based on the object principle will not. Please develop into the habit of "What should I hide?", you will be surprised to find that there are many difficult design problems that will be resolved in front of you.

Coupling standards: Scale (number of connections between modules), visibility (significant degree of connection between modules), flexibility (whether the connection is easy to change ). When creating a system architecture, break down the program according to the principle of "minimizing mutual connection as much as possible.If you regard the program as a piece of wood, split it along the wood texture.

Coupling type:

Coupling of simple data parameters (passing data between modules through simple data type parameters)

Simple Object coupling (an object in another module is instantiated by the module and connected through this object)

Object parameter coupling (two modules are connected through the third module object)

Semantic coupling (a module not only uses the syntax elements of another module, but also uses semantic knowledge about the internal work details of that module --Dangerous)

High coupling leads to the loss of the module's abstract capability, and the management complexity of the module is also weakened or completely lost. Class and subroutine are suitable for the first choice and most important intellectual tools to reduce complexity. If it doesn't help you simplify your work, they will be remiss.