Agile development, reconstruction and Design Model

From: http://kmhz.blog.163.com/blog/static/6918022200832314144955/

Recently, my colleagues and friends talked to me about all aspects of the design pattern. With the development of object-oriented and agile development, more and more programmers hope to use the design model to make their code more reusable, more understandable, and more reliable.

In different situations, the modes and how to implement these modes have been clearly described in various works. However, there are few opportunities to implement the design mode.

Over-designIt means that the flexibility and complexity of the Code exceed the requirement. If we implement various models and complete planning at the initial stage of the design, as the demand changes gradually, there may be a lot of designs that are no longer needed, this is totally not in line with the idea of agile development.

Insufficient DesignPoor development methods make it difficult to maintain them later. Obviously, if we do not do any planning, adding features at Will will make the project more and more chaotic, so that in order to add some features, we have to re-design them.

It is absolutely impossible not to make reasonable planning, but the planning cost is too high in the initial stage, and there seems to be no solution. However, when you think of the basic steps of TDD (test-driven development), you will find that most of the implementation modes can be completed in the refactoring process.

1. compile test cases based on requirements;

2. Compile the privilege code to make the test pass completely;

3. refactor the code.

Refactoring makes the code clearer and easier to maintain, without the need to spend a lot of time on detailed planning at the beginning.

Model obsessionIt means that someone is too dependent on the mode and cannot implement the mode in the code. For beginners to practice the design patterns they have learned, there will be a large number of inappropriate implementations. Developers familiar with all kinds of design patterns may also have such dependencies. During a design, the first thing that comes to mind is what mode it applies to, and even forgets that a switch may be simpler and easier to understand.

In the reconstruction process, under what circumstances should we use the design pattern? What mode should I use?

Bad code taste	Reconstruction Method
Duplicate code	Form Template Method Use Factory Method to introduce polymorphism Creation Chain Constructor Replace one/more points with Composite Extract Composite Unified API through Adapter Introduce Null Object
Method too long	Combination Method Move the aggregation operation to Collecting Paramter Replace conditional Scheduling with Command Move the aggregation operation to Visitor Replace conditional logic with Strategy
Conditional logic is too complex	Replace conditional logic with Strategy Move the decoration function to the Decorator Replace the State change statement with State Introduce Null Object
Basic Type infatuation	Replace type code with Class Replace the condition change statement with State Replace conditional logic with Strategy Replace hidden tree with Composite Replace Implicit Language with Interpreter Move the decoration function to the Decorator Composite encapsulation with Builder
Improper exposure	Encapsulate classes with Factory
Solution spread	Move the created knowledge to the Factory
Classes with similar functions	Unified API through apter
Redundancy	Restrained Singleton
Class is too large	Replace the conditional scheduling statement with Command Replace the State change statement with State Replace Implicit Language with Interpreter
Branch statement	Replace the conditional scheduler with Command Move the aggregation operation to Visitor
Combination explosion	Replace implicit statements with Interpreter
Weird Solution	Unified API through Adapter

Previous Page
1...
-1-1-1-1-1-1-1-1...
-1 next page