"Agile Software Development Reading notes of the third"

"Agile Software Development Reading notes of the third"

Here are some of the gains I have received from the last two parts: The weather station case study and the ETS case study, as well as some of the personal perceptions and insights:

"Observer Mode" is also called regression mode, its biggest impetus comes from the principle of open closure. The motivation for using this pattern is to add new observations without changing the observed object. This allows the observed object to remain closed. Observer is an abstract class, and the specific digitalclock relies on it, and the concrete method of subject depends on it. Therefore, the dependency inversion principle is also applied in which Subject does not have an abstract method, so its dependence with the clock may violate the dip. However, subject is a class that should never be instantiated. It only makes sense in the context of a derived class. Therefore, although subject does not have an abstract approach, it is logically abstract. In C + +, we can enforce the abstraction of a subject destructor by making it pure virtual or by making its constructor a protected function.

The "Abstractserver,adapter and bridge model" reveals that there is no perfect structure, only those that attempt to balance the current costs and benefits. Over time, these structures will certainly change as the needs of the system change, and the trick to managing this change is to keep the system as simple and flexible as possible. The solution using the adapter mode is simple and straightforward. It makes all dependencies point in the right direction and is very simple to implement. Bridge mode is slightly more complex, so it is not recommended to use this mode at the outset, until it is obvious that you need to completely detach the connection policy and communication strategy and need to add new connection policies. Like the usual pattern, patterns are things that bring benefits and pay a price, and should be chosen according to the actual pattern.

Proxy,stairway to Heaven mode, also known as managing third-party APIs, is relatively easy to create and has minimal impact on objects that contain business rules, but it requires a language that implements support for multiple inheritance, such as:c++. For proxy mode, it is recommended to start with the facade mode and then use refactoring if necessary, so you can reduce unnecessary hassles for yourself.

Code can drive the development and process of design. Most people think that the demand is not so changeable, it is not, just like the weather change is unpredictable, as the forecaster must draw a boundary, from the proxy class to the implementation of the class dependency does not represent a great maintenance risk, do not need a factory model.

The Visitor Mode series gives us a number of ways to modify the behavior of a class without changing a hierarchy. In addition, they provide a mechanism for separating different kinds of functionality, so that classes do not mix with many other functions, and also help us maintain the CCP, which also uses SRP,LSP and dips. This pattern is very tempting, they can easily lose self-control, in the use of them it is best to maintain a high level of vigilance, generally need it to solve the problem of a problem with a more simple way to solve the problem.

Finite state machines are not fully used, and in many cases, using them to help create clearer, simpler, more flexible, and more accurate code, using state mode and generating code based on status migration tables, can be a great help.

The parts of the frame that deal with the computational geometry, or the part about the access to the answer file, and so on, the existence of these parameter files allows each drawing application to drive many different variants of itself, but it is not possible due to time and space constraints.

From the author's presentation, I also learned how to use examples and types to form an application domain model to analyze the problem, how classes, objects, and components are combined into static and dynamic diagrams that describe software architectures and constructs, understand the UML representations of these concepts, and how to use these representations, It is best to know how these methods are involved in the thinking of software design. In short, this book vividly introduced to me the Agile software development of relevant knowledge, analysis of relevant cases, let me feel the author's realm, sublimation of their own soul!

"Agile Software Development Reading notes of the third"