Software design - Lecture 45. The main topics covered in this chapter include: refactoring; applying refactoring; refactoring and design patterns; defining anti-patterns; motivation for anti-patterns; famous known anti-patterns; patterns fetish or pattern craze;...
1 Software Design Lecture : 45 Refactoring Refactoring Overview Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior Its heart is a series of small behavior preserving transformations. 'refactoring') Each does transformation little, but a (called sequence transformations can produce a significant restructuring a of Smells are Problem Smells (especially code smells) are warning signs about potential problems in code. Not all smells indicate a problem, but most are worthy of a look and a decision Smells usually describe localized problems. It would be nice if people could find problems easily across a whole system. But humans aren't so good at that job; local smells work with our tendency to consider only the part we're looking at right now Applying Refactoring We try to select refactoring that improve the code in each trip through the cycle. Because none of the steps change the program's observable behavior, the program remains in a working state. Thus, the cycle improves code but retains behavior. The trickiest part of the whole process is identifying the smell Measured Smells i They're dead easy to detect ii They're objective (once you decide on a way to count and a maximum acceptable score). They're horrible. And, they're common iii We can think of these smells as being caught by a software metric. Each metric tends to catch different aspects of why code isn't as good as it could be Refactoring and Design Patterns The process of improving the design of existing code with patterns, the classic solutions to recurring design problems Defining AntiPatterns Jim Coplien: “Something that looks like a good idea, but which backfires badly when applied.” 10 AntiPattern The term was coined in 1995 by Andrew Koenig, inspired by Gang of Four's book Design Patterns, which developed the concept of design patterns in the software field The term was widely popularized three years later by the book AntiPatterns, which extended the use of the term beyond the field of software design and into general social interaction 18 Simple Possible Solution 19 2. Swiss Army Knife • Occurs when … i You have more interfaces than classes ii.The number of interfaces on a class produce a severe case of instability 20 SwissArmy Knife A Basic LitmusTest Do your classes implement more than 3 interfaces? 21 Sample Code 22 Points to Understand i More != Better ii Too many interfaces creates confusion iii Maintenance problems iv Each interface requires implementation of items on that interface v Do your classes actually need to share an interface? 23 Improvements MaybeyourclassneedstoUSEanotherclass Aggregation,Composition ConsidertheFaỗadedesignpattern Faỗadeselectsinnerobjectstodothework 24 3.TheCrystalBall i Designingfortheunknownorfuturepotentials Littletonojustification ii Designreachesouttoofarandassumestoo much 25 26 The Crystal Ball Base classes are overly generic for the problem domain They implement methods/attributes that add little value Subclasses have little in common with their Siblings Remember the Sesame Street Rule: One of these things is not like the other 27 4. The God Class i One “Do It All” class • Symptoms i Major tipoff = an excessive number of methods ii Lack of specialization, low cohesion iii One class manages all behaviors for what probably should be “logical subtypes” 28 One Class Do it all 29 Same Solution with Inheritance 30 Abstraction Inversion When users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions 31 Possible Ill Effects: The user of such a reimplemented function may seriously underestimate its runningcosts The user of the construct is forced to doubt his implementation with complex mechanical details Many users attempt to solve the same problem, increasing the risk of error 32 Paper Patterns i Quizes ii Assignments iii Mid Term Exam – Open Book iv Final Paper – Open Book ... developed the concept of design patterns in the? ?software? ? field The term was widely popularized three years later by the book AntiPatterns, which extended the use of the term beyond the field of software? ? design ... They're horrible. And, they're common iii We can think of these smells as being caught by a software? ? metric. Each metric tends to catch different aspects of why code isn't as