Agile Software development 5

1,
In general, I think the database is the implementation details. Decisions on these details should be postponed as much as possible. Whether this particular database uses RDBMS or flat files
File) or oodbms implementation, it is irrelevant at this time. Now, I am only interested in the APIs that provide database services for other parts of the application. Then, I will find the appropriate implementation of the database.

It is uncommon but worthwhile to postpone the database details. We often make database decisions until we have more knowledge about the software and its needs. By waiting, we can avoid putting too many infrastructure into the database. We are more willing to implement only the database functions that meet the needs of applications. P186

 

2,
In the previous chapter, we have used many models. We often use them directly without showing how code evolves into a usage pattern. This may make you think that the pattern is something that is completely inserted into the code and design. This is not my recommended method. I prefer to evolve code in the direction required by the code being written. However, when I refactor the code to solve coupling, simplicity, and expressiveness problems, I may find that the code is close to a specific pattern. At this time, I changed the class and variable names to the usage mode name, and changed the code structure to use the mode in a more formal form. In this way, the Code returns to the pattern. P261

 

3,
The observer mode has two main models: Pull model and push model. P276

 

4,
The biggest driver of the observer mode is the open and closed principle (OCP ). The motivation for using this pattern is to add new observed objects without changing them. In this way, the observed object can be closed. P277

 

5,
In C ++, we can force the abstraction of subject by making its destructor purely virtual or making its constructor protected. P277

 

6,
Conclusion: Some people may want to say that the real problem in the modem scenario is that the original designer was wrong. They should have known that connection and communication are different concepts. If they do more analysis, they will find the problem and correct it. Therefore, it is easy to attribute the problem to inadequate analysis.

Nonsense! There is no such thing as full analysis. Regardless of the amount of time spent trying to find the perfect software structure, the customer will always introduce a change to destroy the structure.

This situation cannot be avoided. There is no perfect structure. Only structures that attempt to balance the current cost and benefits exist. Over time, these structures will certainly change as system requirements change. The trick to managing such changes is to keep the system as simple and flexible as possible.

The solution using the adapter mode is simple and straightforward. It points all dependencies to the correct direction and is easy to implement. The bridge mode is a little complicated. I recommend that you do not use the bridge mode at the beginning until it is obvious that you need to completely separate the connection policy from the communication policy and add a new connection policy.

As usual, the model is something that brings both benefits and costs. You should use models that are best suited to problems at hand.