Capitolo 2 – Design Patterns – Refactoring
Di seguito trovate il libro: Design Patterns: Elements of Reusable Object-Oriented Software – Kent Beck
Questo libro tratta gli argomenti della costruzione dei Design Pattern utili al refactoring e all’abbattimento del debito tecnico. E’ molto specifico sulla creazione e utilizzo dei Design Pattern.
Si consiglia la lettura della sintesi riportata nel capitolo conclusivo: 6. Conclusion e in particolare What to Expect from Design Patterns e il paragrafo dedicato a Refactoring.
Design Patterns can affect the way to design object-oriented software, based on ourday-to-day experience with them, through:
- A Common Design Vocabulary
- A Documentation and Learning Aid
- An Adjunct to Existing Methods
- A Target for Refactoring
“A Target for Refactoring” – pag. 390-392
“One of the problems in developing reusable software is that it often has to be reorganized or refactored [OJ90]. Design patterns help you determine how to reorganize a design, and they can reduce the amount of refactoring you need to do later. The lifecycle of object-oriented software has several phases. Brian Foote identifies these phases as the prototyping, expansionary, and consolidating phases.
The prototyping phase is a flurry of activity as the software is brought to life through rapid prototyping and incremental changes, until it meets an initial set of requirements and reaches adolescence. At this point, the software usually consists of class hierarchies that closely reflect entities in the initial problem domain. The main kind of reuse is white-box reuse by inheritance. Once the software has reached adolescence and is put into service, its evolution is governed by two conflicting needs: (1) the software must satisfy more requirements, and (2) the software must be more reusable. New requirements usually add new classes and operations and perhaps whole class hierarchies. The software goes through an expansionary phase to meet new requirements. This can’t continue for long, however. Eventually the software will become too inflexible and arthritic for further change. The class hierarchies will no longer match any problem domain. Instead they’ll reflect many problem domains, and classes will define many unrelated operations and instance variables.
To continue to evolve, the software must be reorganized in a process known as refactoring. This is the phase in which frameworks often emerge. Refactoring involves tearing apart classes into special-and general-purpose components, moving operations up or down the class hierarchy, and rationalizing the interfaces of classes. This consolidation phase produces many new kinds of objects, often by decomposing existing objects and using object composition instead of inheritance. Hence black-box reuse replaces white-box reuse. The continual need to satisfy more requirements along with the need for more reuse propels object-oriented software through repeated phases of expansion and consolidation—expansion as new requirements are satisfied, and consolidation as the software becomes more general.
This cycle is unavoidable. But good designers are aware of the changes that can prompt refactorings. Good designers also know class and object structures that can help avoid refactorings—their designs are robust in the face of requirement changes. A thorough requirements analysis will highlight those requirements that are likely to change during the life of the software, and a good design will be robust to them. Our design patterns capture many of the structures that result from refactoring. Using these patterns early in the life of a design prevents later refactorings. But even if you don’t see how to apply a pattern until after you’ve built your system, the pattern can still show you how to change it. Design patterns thus provide targets for your refactorings.
Nel Glossario Appendix A: Glossary trovate delle definizioni utili. pag. 397 – 403. Riportiamo alcuni Termini con le definizioni:
black-box reuse – A style of reuse based on object composition. Composed objects reveal no internal details to each other and are thus analogous to “black boxes.”
design pattern – A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.
white-box reuse – A style of reuse based on class inheritance. A subclass reuses the interface and implementation of its parent class, but it may have access to otherwise private aspects of its parent.
Code Refactoring:
To deliver business value with well-designed software in every short iteration, XP teams also use refactoring. The goal of this technique is to continuously improve code. Refactoring is about removing redundancy, eliminating unnecessary functions, increasing code coherency, and at the same time decoupling elements. Keep your code clean and simple, so you can easily understand and modify it when required would be the advice of any XP team member.
Article Extreme Programming (vedi articolo citato nel precedente Capitolo 1)