Chapter 6 of Tao nature

Chapter 6 Architecture Analysis: functional decomposition vs object analysis

Two gains:

1. functional decomposition is a vertical hierarchy, and object analysis can form a horizontal hierarchy through reasonable combinations. In vertical hierarchy, each layer is from top to bottom, from the interface to the database, obviously brings great difficulties to software analysis and maintenance, and is not conducive to software function expansion. In Horizontal layering, the layer-to-layer coupling can be minimized by appropriate combinations, and the implementation of a single layer is simplified and easy to replace by limiting the layer-to-layer relationship, so that the team can collaborate to develop large-scale software.

2. The concepts of layers, subsystems, and packages have been very confusing before. Now I have figured it out: in general, layer> subsystem> package. These three concepts are nothing more than extensions of the object encapsulation concept.

The package is just the aggregation of classes with similar functions;

The main difference between subsystems and classes: the subsystem can only passively accept messages and cannot actively send messages. That is, the subsystem is a completely closed system. Two points of attention: 1) Note that the process-oriented subsystems are completely different; 2) subsystem design is essentially the scope of OO design, rather than the scope of OO analysis.

The main difference between a layer and a class: A layer can only send or receive messages to adjacent layers as agreed.

From the above understanding, except that the bottom layer can be used as a sub-system, the other layers cannot be used as subsystems, but can only contain subsystems.

Two questions:

1) The subsystem must implement an interface. This is a good idea, but how can we implement the interface? How can I call this interface? Must an interface be explicitly defined? Some subsystems include several classes or packages. How do I implement an interface for several classes or packages?

2) the MVC framework is conceptually understandable, but many coupling exists in the implementation of VC. For example, after clicking a button, you may not only need to perform an operation, in addition, you need to change the color of a window. Of course, you can break down the Click Event of the view layer into two events: Call the color change method of the view layer and call the logic processing of the model layer. However, there are a lot of operations that are not easy to use. This is too cool. Should it be like this: the formation of the M--V--VC architecture, V mainly realize the core logic function (no matter which interface will have some functions, such as the total value of computing ); does VC implement secondary and unstable logic functions?