1. XP and Refactoring David Talby

2. Development Methodologies The Software Crisis – 84% of software projects are not on time – 31% of software projects never complete – Most software is buggy, unstable and insecure – Lack of repeatability (engineering) eXtreme Programming – For small projects: up to 12 people, 100 stories Rational Unified Process – For large projects: a “heavy-weight” process – A commercial product

3. Rational Unified Process By Rational, see rational.com/ruprational.com/rup Decompose large system to sub-systems – A team and development effort per system – Architects Team does overall design, sharing Five stages of each system’s life cycle – Business modeling, Requirements, Analysis & Design, Implementation, Test – Many artifacts are not code or tests Iterative Development Highly managed, highly automated process

4. eXtreme Programming By Kent Beck, see XProgramming.comXProgramming.com Embrace change Simplicity User involvement & rapid feedback Incremental pay-as-you-go design Test-first programming

5. The 12 XP Principles Planning Game Small Releases On-Site Customer Metaphor Simple Design 40-Hour Week Pair Programming Collective Ownership Testing Refactoring Continuous Integration Coding Standard

6. The XP Principles Develop by iterations of 1-3 weeks each: Plan (user stories) -> design (simplest!) -> test (unit tests) -> code (and refactor) Testing – Functional tests: in design phase – Unit tests as part of coding Continuous Integration Quality Work – Refactoring, 40-Hour Week

7. Refactoring Improving the design of existing code, without changing its observable behavior Here ’ s the Extract Method refactoring: After: void f() { … computeScore(); } computeScore(int[] a) { // code cut & pasted here } Before: void f(int[] a) { … // compute score score = initial_score; for (int i=0; i<a.length; i++) score += a[i] * delta; }

8. Why? Why Refactor? – Improve software design – Make software easier to understand – Help find bugs – Help program faster Preconditions – Working code – Good set of unit tests

9. When? When to refactor – Before adding functionality – Before fixing a bug – During code review When not to refactor – During adding functionality – During fixing a bug – No good set of unit tests – Small programs (usually)

10. Code Smells “If it stinks, change it” – Duplicate code – Switch statements – Long method – Data class – Long parameter list – Primitive obsession – Temporary field – …

11. Documented Refactorings There’s a catalog – Fowler’s book – www.refactoring.com/catalog www.refactoring.com/catalog There are many others Way to learn good OOD principles Pay attention to the mechanics There are automatic tools as well – Java Refactoring Browser, refactorit.comrefactorit.com

12. Encapsulate Field Before: public String name; After: private String name; public String getName() { return name; } public void setName(String n) { name = n; }

13. Introduce Null Object Before: if (project == null) plan = Plan.default(); else plan = project.getPlan(); After: class NullProject implements Project { public Plan getPlan() { return Plan.default(); } // other Project methods }

14. Parameterize Method Before: class Server { handleGet( … ) handlePut( … ) handleSet( … ) } After: class Server { handle(EventType et, … ) }

15. Extract Subclass

16. Extract Interface

17. Pull Up Method

18. Replace Type Code with State/Strategy

19. Replace Inheritance with Delegation

20. Hide Delegate Obeys the Law of Demeter

21. Separate Query from Modifier Obeys Command-Query Separation Database getNextResultAndAdvanceIndex Database getNextResult AdvanceIndex

22. Introduce Local Extension Alternative: Introduce Foreign Method

23. The opposites are there too Inline method (extract method) Replace Parameter with Explicit Methods (Parameterize Method) Collapse Hierarchy (Extract subclass) Remove middle man (Hide delegate) Push down method (pull up method) Replace delegation with inheritance

24. How to Refactor Recognize the smells Refactor in small discrete steps Test after each step Refactor in pairs Use documented refactorings Don’t mix with adding functionality or fixing a bug

25. Review: OOD Principles Open-Closed Principle Liskov Substitution Principle Single Choice Principle Law of Demeter Command-Query Separation Interface Segregation Principle, a.k.a. Single Responsibility Principle Dependency Inversion Principle