AntiPatterns. EEC 421/521: Software Engineering. AntiPatterns: Structure. AntiPatterns: Motivation

Transcription

1 AntiPatterns EEC 421/521: Software Engineering Definition: An AntiPattern describes a commonly occurring solution to a problem that generates decidedly negative consequences Refactoring Reference: Refactoring by Martin Fowler 3/27/08 EEC 421/521: Software Engineering 1 3/27/08 EEC 421/521: Software Engineering 3 AntiPatterns: Motivation Much of the focus in software engineering research is on positive and constructive solutions (from a clean slate) Sometimes it is easier to recognize what is wrong than to do it right in the first place Especially when most of the work is maintenance, as opposed to new development AntiPatterns: Structure Description of general form (or situation) Primary causes which lead to the general form Symptoms describing how to recognize the general form Consequences of the general form Refactored solution describing how to achieve a healthier situation 3/27/08 EEC 421/521: Software Engineering 2 3/27/08 EEC 421/521: Software Engineering 4

2 A Typical Software Project Engineer comes up with an idea Engineer whips together a quick prototype to illustrate the idea Engineer shows the prototype to manager Manager suggests some added functionality, which the engineer adds to the prototype Manager shows the prototype to sales team Sales team likes the product, and wants to market it! Typical Software Project (contd.) As features are added, the product keeps breaking; the core piece was not made to be bullet-proof The engineering team tries to do what it takes to maintain the software and keep it going Keep It Working Pattern But in keeping the system working, several issues come up Due to time pressures, these are not issues that can be dealt with right away, and are therefore postponed Sweeping It Under The Rug Pattern 3/27/08 EEC 421/521: Software Engineering 5 3/27/08 EEC 421/521: Software Engineering 7 Typical Software Project (contd.) Marketing pressures force engineering team to use the prototype as the basis of the product! What should really have been thrown away is used as a core piece of the software product! Throwaway Code Pattern As the product evolves, more and more feature requests keep coming from management and marketing These features are added as ad-hoc pieces to the core piece Piecemeal Growth Pattern The Big Ball of Mud Pattern What results from these kinds of development activities is a piece of software that cannot be changed easily, is not very useful, and is too big for comfort In other words, a Big Ball of Mud! 3/27/08 EEC 421/521: Software Engineering 6 3/27/08 EEC 421/521: Software Engineering 8

3 Refactoring Definition: Change a software system so that the external behavior does not change but the internal structure is improved Improve the design of existing code in small steps If it stinks, change it. [Grandma Beck, discussing child rearing philosophy] Comments in Code Often just deodorant for bad smelling code Refactor code so that the comment becomes extraneous Introduce assertions Comments are good for explaining why you did something, not what you are doing (that should be apparent from the code) 3/27/08 EEC 421/521: Software Engineering 9 3/27/08 EEC 421/521: Software Engineering 11 Bad Smells in Code Like evaluating user interfaces, we also need to be able to evaluate software designs Following are some indicators of potential problems or bad smells ; solutions involve judgment and balance Duplicated code, Long method, Large class, Long parameter list, Data clumps, etc. 7 Deadly Sins of Software Development Haste ( If it works, ship it! ) Apathy (sweep it under the rug) Narrow-mindedness Sloth (always choosing the easy answer) Greed (too complex) Ignorance (don t want to learn) Pride ( if it ain t built here, it s wrong! ) 3/27/08 EEC 421/521: Software Engineering 10 3/27/08 EEC 421/521: Software Engineering 12

4 Refactoring: Example A program to calculate and print a statement of a customer s charges at a video store: Customer can rent movies Movies have different pricing Movies are rented for a number of days Customer can collect frequent renter points Initial Design: Sequence Diagram 3/27/08 EEC 421/521: Software Engineering 13 3/27/08 EEC 421/521: Software Engineering 15 Initial Design: Class Diagram Problems with Design Procedural, not object-oriented statement() routine does too much Customer class is a blob or god class Potentially difficult to make changes e.g., HTML output e.g., new charging rules 3/27/08 EEC 421/521: Software Engineering 14 3/27/08 EEC 421/521: Software Engineering 16

5 Step 1: Decompose statement() method: extract logical chunk of code as a new method Apply Extract Method You have a code fragment that can be grouped together Turn the fragment into a method whose name explains the purpose of the method Enhance readability of amountfor() method Rename variables Step 3: Eliminate thisamount temporary in statement(): replace redundant temporary variable with query apply Replace Temp with Query You are using a temporary variable to hold the result of an expression Extract the expression into a method. Replace all references to the temp with the expression. The new method can then be used in other methods. 3/27/08 EEC 421/521: Software Engineering 17 3/27/08 EEC 421/521: Software Engineering 19 Step 2: Move amountfor() to Rental class: method uses rental information, not customer information move method to the right class apply Move Method A method is, or will be, using or used by more features of another class than the class on which it is defined Create a new method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether. 3/27/08 EEC 421/521: Software Engineering 18 Step 4: Extract frequent renter point calculation from statement() Apply Extract Method and Move Method Step 5: Eliminate totalamount temporary in statement() replace redundant temporary variable with query apply Replace Temp with Query Step 6: Eliminate frequentrenterpoints temporary in statement() 3/27/08 EEC 421/521: Software Engineering 20

6 New Design What have we achieved? 3/27/08 EEC 421/521: Software Engineering 21 Kinds of Refactoring Creating methods intended to help reduce the size of methods and improve the readability of the code e.g., Extract Method, Inline Method, Replace Temp with Query Moving features between objects sometimes, responsibility is placed in the wrong class or a class ends up with too many responsibilities e.g., Move Method, Move Field, Extract Class 3/27/08 EEC 421/521: Software Engineering 23 Comments on the New Design The design is more object-oriented Objects are doing their own work Extensibility Say we wanted to create statements in HTML 3/27/08 EEC 421/521: Software Engineering 22 Kinds of Refactoring Organizing data sometimes, objects can be used instead of simple data items e.g., Replace Data Value with Object, Replace Array with Object Simplifying conditional expressions conditional expressions and logic can be difficult to understand e.g., Replace Conditional with Polymorphism 3/27/08 EEC 421/521: Software Engineering 24

7 Kinds of Refactoring Making method calls simpler complicated programming interfaces can be difficult to use e.g., Rename Method, Add Parameter Dealing with generalization getting methods and subclasses to the right place e.g., Pull Up Method, Push Down Method, Extract Subclass, Extract Superclass 3/27/08 EEC 421/521: Software Engineering 25 Refactoring and Indirection Refactoring typically adds more indirection decomposes big objects and methods into smaller ones distributes responsibilities Benefits of indirection: share logic (e.g., methods in superclasses) encode design intent within class structure (e.g., good names of methods and classes) express conditional logic (e.g., polymorphism) Potential limitations too much indirection (performance impact) changing published interfaces are significant design changes possible? 3/27/08 EEC 421/521: Software Engineering 27 Refactoring Rules of Thumb Reduce risk of change Do not change functionality One thing at a time Test each step (more on this when we look at Test-Driven Development) Iterate 3/27/08 EEC 421/521: Software Engineering 26