After the book of "Daofa Nature" came, many of the enthusiastic readers sent a message to explore the relevant technical issues. For example, a few days ago, a reader confident that the principle of "Decomposition" pointed out a mistake in the Road Method. Here, I am sincere gratitude to the reader and post his letter and Wang Haowu's reply to the message for your reference.
I have recently bought your new book "Da Fa Nature" in the bookstore. It feels very well, just like Mr. Li Wei, rich in content, collects and organizes a large number of object-oriented knowledge, and with a practical project to enhance these knowledge organizational, rich and inherently uniform. Very attractive, I have read more than 100 pages. It is very careful, and I think a lot, so in the process of reading, I found some small mistakes or questions, listed here, discuss with you.
P.9, LINE 2: A typical error: Coordination -> Willing
p.140: Arrow should be represented by Class4 to Class3, Friends, I think it is.
P.113, Figure 6-3: Individual dependencies, I think it is not very good, it should be depends on Domain Logic by the data persistence layer. Because Domain Logic is the essence and core of the problem domain, is the most stable of. All layers are dependent on the Domain layer, and the Domain class can get the best consideration. This also complies with Robert Martin's dependencies in "agile software development". You can refer to "Agile Software Development" Chinese version of Page 256 and Chapter 11. It is also possible to refer to the "Characteristics Drive Development Method" Chinese version of the Page 156.
P.113, Figure 6-4: Layer dependencies seem to be over. The truth and the previous one are the same.
The above two are actually the DIP (Dependancy Inversion Principle) said by Robert Martin. Its meaning is:
Subsystems are only dependent on the interface, which has been mentioned in your book. Another meaning is to place the definition of the interface to the upper subsystem. That is, the change in the interface is mainly caused by changes in the upper subsystem, and the impact of the sub-system is small. For example, the Domain layer has an interface between the Domain layer and the data management layer, not the data management layer owns this interface. This difference is very subtle, but it seems important. Recommendation: It is recommended to rely on your book to your book.
These are my personal opinions, the purpose of proposes is to discuss with you.
Maybe on this point, you are wrong. But I am not hidden, I am glad that I bought a good book.
October 20, 2004
Thank you for your support and encouragement, I am also very grateful for you.
P.140 About the description of the friend class does have a significant error. The pictures and code are as follows:
INCLUDE "class4.h"
Class3
{
Friend class class4;
// ......
}
The pictures and code are unified, no errors, but the previous text has a note:
The original text is: that is, Class3 is not only depends on Class4, but also Class3 is also a Class4 friend class.
It should be: 即 Class4 is not only depends on Class3, but also Class4 or Class3's friend class (Class4 hopes to access Class3's non-public member).
Regarding the principle of relying on the inversion, I have also carefully thinking when I write "Dahua Nature". Here are a few aspects to explain my understanding:
First of all, since theoretically, Robert Martin is defined in this way: depending on abstraction, not to rely on embassy (see: "The road method is naturally 3.4.3). More detailed definitions are:
The upper module should not depend on the lower module, which relies together to an abstraction. Abstraction can't rely on the real elephant, depending on the abstraction. Second, use FishGUI as an example, from the perspective of practice. Suppose the FishGUI framework system must be ported to a different operating system (such as Windows and UNIX), in order to make the change of the operating system do not affect the frame layer, an operating system adapter interface must be abstracted, and the class in the FishGUI framework is only dependent on The interface, and the derived class of the interface is implemented to the call of different operating systems. This implementation is in line with dependence inversion. As shown below:
If we believe that the adapter interface class belongs to the frame layer, the developer of the frame layer is designed, and this interface is designed to be well-developed. However, it is easy to encounter a problem. When you need to port to another new operating system, this interface may not be suitable for the implementation of the operating system, which is very troublesome when specific adapters. At this time, the two-layer dependency is shown below, and the lower layer depends on the upper layer.
If we believe that the adapter interface is a suitable layer, it is developed by the developer of the adapter layer, and this interface will summarize the characteristics of a variety of operating systems, making the transplant very convenient. But it is easy to cause difficulties in the framework. At this time, the two-layer dependency is shown in the following figure, the upper layer depends on the lower layer.
These two different options are easily encountered in specific design. The results obtained by the two design seem to be opposite, and it is a difficult problem.
Finally, from the requirements of the traditional layered architecture mode, the next layer of service should be used on the upper layer, depending on the lower layer; the next layer can never use the upper layer of service, depending on the upper layer. Moreover, from the FishGui framework layer and adapter layer, it is indeed, the frame layer will call the adapter layer, and the adapter layer will never call the frame layer, and the adapter layer is only reversed depending on the adapter interface.
These points of the above analysis seem to have a lot of contradictions. I think I can perfectly unite these contradictions perfectly as long as I understand the two points below.
Relying on the inversion is not to turn "the upper layer" transition into "the lower layer depends on the upper layer" (the module does not have no connection, there is always a module to be dependent by others, the conversion dependence is no meaning), but the two dependence A abstract interface. The principle of opening and closing, the full replacement principles and rely on the inversion principle are the results of the same core principle from different perspectives. This core principle is that I have continuously emphasized the interface in the "Road Method Natural" book, but not for the implementation program. " These principles belong to the category of OOD, should be used during the OOD. According to these two points, I think is the example of the FishGui above. When the system is divided into a framework layer and an adaptation layer, do not consider relying on the inversion principle, but from the macro look, due to the framework The layer is dependent on the adaptation layer, and the upper layer depends on the lower layer.
When entering the object-oriented design phase, these OOD principles can play a role. At this time, according to the principle of "programming for interface, not to program", the upper layer can be eliminated by the adapter interface. Such design can also meet the principle of opening and closing principles, complete replacement principles and relying on the principle of inversion, so, depending on the principle of relying on the inversion, it is not true to rely on, but the coupling between the layers, so that they are more It is easy to adapt to the demand for changes.
At this time, it is not necessary to force which layer belongs to which layer belongs to, but should be solved by two-story designers to address the two-story interface. This is some thinking about the principle of relying on the principle of "Dao Fa Nature", I hope to hear your ideas. Through this communication, we can deeper our understanding of the principle of OO, so that OO technology has better applications in practice, this is the most fundamental idea I have written "Dao Fa Nature" book.
Wang Haowu October 25, 2004
