"Agile Software Development Reading notes of the second"

"Agile Software Development Reading notes of the second"

Next, I will show you the third part of the "pay-for-pay case study" and the fourth part of the "packaged pay system," the two parts of the understanding, as well as the gains from it:

Here's what I learned from the third part of the pay-for-pay case study and some personal summaries:

The simplicity of the command pattern masks its versatility, which can be applied to a variety of different wonderful uses, ranging from database operations, device control, multithreaded cores, and GUI Do/undo management, which is useful in real-world software development.

Both the TEMPLATE method mode and the strategy mode can be used to separate the upper-level algorithms from the specific implementation details of the lower layers. Allows high-level algorithms to be reused independently of its specific implementation details. In addition, the strategy mode allows for detailed implementation of detail-independent algorithm reuse at the top level.

The facade mode is suitable for a wide and visible strategy, while the Medlator mode is suitable for covert and targeted strategies. Facdes is usually the agreed attention point. Mediator is hidden from the user, and its strategy is a fait accompli rather than an agreed thing.

The singleton mode uses a private constructor, a static variable, and a static method to control and limit the instantiation. The monostate mode simply turns all variables of the object into static. The former applies to constraining an existing class by derivation and does not mind that all of his callers have to use the instance () method to gain access, while the latter is more applicable to the uniqueness of the class, which is transparent to the consumer, or a polymorphic derivation object that wants to use a single object.

Using the null object pattern ensures that the function always returns a valid object, even if it fails.

The purpose of the session is to initiate a thinking activity and to provide the developer with a common intelligence model that can be used to work on it, rather than to determine the design.

The use of a large number of abstractions and polymorphism in "pay system design" has made most of the designs closed to changes in the pay system strategy. In this process, it is seldom considered whether an analysis, design, or implementation is in progress. Instead, focus on clear and closed questions, wherever possible, trying to identify potential abstractions.

Here's what I got from Part four, "Packaged pay system":

The "Design Principles for Packages" chapter describes how a dependency management metric can measure a design versus what I think is a "good" dependency, the degree to which an abstract structure pattern matches, and shows. Dependencies are good or bad, and the pattern reflects this experience. However, the measure is not omnipotent, it is just a method of measurement that replaces the arbitrary standard. But it is undeniable that there are other measures that are better than this method.

"Factory mode" is a more efficient tool that allows high-level policy modules to create instances of classes without relying on the specific implementation of these classes. They also make it possible to exchange between implementations of a completely different series of a set of classes. However, it can lead to complexity, which is often avoidable, and using them by default is often not the best practice.

The pay case study reveals whether the package structure needs to be managed, depending on the size of the program and the size of the development team. Even small teams have to divide the source code so that developers can not interfere with each other, without some form of partition structure, the big program will become obscure source file accumulation.

Agile Software Development Reading notes of the second "