CSCD01 Engineering Large Software Systems. Refactoring. Joe Bettridge. Winter With thanks to Anya Tafliovich (Based on Refactoring by M.

Transcription

1 CSCD01 Engineering Large Software Systems Refactoring Joe Bettridge Winter 2018 With thanks to Anya Tafliovich (Based on Refactoring by M. Fowler)

2 What is Refactoring? Process of changing a software system in ways that does not affect the internal behaviour of the software, yet improves the internal structure A disciplined way to clean up code that minimizes the probability of introducing bugs Improving the design of the code after it is written Taking lots of small steps in order to accomplish these things

3 Why Refactor? Over time, even initially good code can become spaghetti code (the quality of design deteriorates over time). As a system grows, you learn more about how it ideally should be designed. The more you know, the more assumptions you can confirm, or reject, and thus make better choices. Keeping up with these choices requires old code to be changed. Without refactoring, automation can be very difficult to achieve!

4 Consolidate Conditionals Original Code: def determineeligableamount(): if (age > 65): return 0.0 if (isparttime): return 0.0 if (age < 18): return 0.0 #determine specific amount. return amount Refactored Code: def determineeligableamount(): if (age > 65) or (isparttime) or (age < 18): return 0.0 #determine specific amount. return amount Can anything further be done?

5 Extract Method Original Code: def determineeligableamount(): if (age > 65) or (isparttime) or (age < 18): return 0.0 #determine specific amount. return amount Refactored Code: def determineeligableamount(): if (isnoteligable()): return 0.0 #determine specific amount. return amount def isnoteligable(): return (age > 65) or (isparttime) or (age < 18) Although the refactored code is longer, it is easier to read, and the method created may be useful elsewhere!

6 Consolidate Duplicate Conditional Fragments Original Code: Refactored Code: if(isspecialprice) { total = price * 0.85; submitsale(total); else { total = price; submitsale(total); if(isspecialprice) { total = price * 0.85; else { total = price; submitsale(total); Look for code that is run in all conditional branches (including any else conditions. Pull this code out and place it below the conditional block. Be weary of false applicability of this however, if there is no else block for example!

7 Remove Control Flags (start break war) Original Code: Refactored Code: protected void validatesecurity (ArrayList<Person> people) { boolean found = false; for(person person : people) { if (!found) { if (person.equals("joe")) { //run actions for Joe //... found = true; if (person.equals("paco")) { //run actions for Paco //... found = true; //rest of program protected void validatesecurity(arraylist<person> people) { for(person person : people) { if (person.equals("joe")) { //run actions for Joe //... break; if (person.equals("paco")) { //run actions for Paco //... break; //rest of program

8 Replace Nested Conditionals Original Code: public int getresultantamount() { int result = 0; if (issingle) { result = singleamnt(); else { if (isseperated) { result = seperatedamnt(); else { if (ismarried) { result = marriedamnt(); return result; Refactored Code: public int getresultantamount() { if (issingle) { return singleamnt(); if (isseperated) { return seperatedamnt(); if (ismarried) { return marriedamnt(); return 0; Nested conditions are often the result of someone quickly entering new code in to solve for a very small specific problem without thinking about the larger design. Any time these are seen, it is a good idea to re-visit the logic, and see if there is a better way to format the conditionals, and land at the same result.

9 Replace Nested Conditions Original Code: def getadjustedcapital(): result = 0.0 if (_capital > 0.0): if (_intrestrate > 0.0) and (_duration > 0.0): result = (_income / _duration) * ADJ_FACTOR return result Refactored Code: def getadjustedcapital(): if (_capital > 0.0) and (_intrestrate > 0.0) and (_duration > 0.0): return (_income / _duration) * ADJ_FACTOR return 0.0 def getadjustedcapital(): if (_capital <= 0.0) or (_intrestrate <= 0.0) or (_duration <= 0.0): return 0.0 return (_income / _duration) * ADJ_FACTOR def getadjustedcapital(): if noadjustment(): return 0.0 return (_income / _duration) * ADJ_FACTOR def noadjustment(): return (_capital <= 0.0) or (_intrestrate <= 0.0) or (_duration <= 0.0)

10 Replace Magic Numbers with Constants Original Code: public double potentialenergy (double mass, double height) { return mass * 9.81 * height; Refactored Code: public static final double GRAVITY = 9.81; public double potentialenergy(double mass, double height) { return mass * GRAVITY * height; This should be fairly self-explanatory. By replacing with constants, code readability goes up significantly, and if something ever changes, it only needs to be changed in one position in the code.

11 Encapsulate Fields Original Code: public String name; Refactored Code: private String name; public String getname() { return name; public void setname(string name) { this.name = name; Note that a getter should always be made (even if it s protected), but setter is much more optional, depending on the purpose of the code

12 Encapsulate Collections Original Code: public class Student { public Set<Course> courses; Refactored Code: public class Student { private Set<Course> courses; public Set<Course> getcourses() { return courses; public void setcourses(set<course> courses) { this.courses = courses; This code, although better, still isn t fully encapsulating the collection. Why?

13 Encapsulate Collections - Continued Original Code: public class Student { private Set<Course> courses; public Set<Course> getcourses() { return courses; Refactored Code: public class Student { private Set<Course> courses; public Set<Course> getcourses() { return Collections.unmodifiableSet(courses); public void setcourses( Set<Course> courses) { this.courses = courses; public void initcourses(set<course> courses) { this.courses = new HashSet<Course>(); for (Course c : courses) { this.courses.add(c); public void addcourse(course c) { this.courses.add(c);

14 Parametrize Methods Original Code: class Employee { double salary; void fivepercentraise() { salary = salary * 1.05; Refactored Code: class Employee { double salary; void raise(int percent) { salary = salary * (1+(percent/100)); void tenpercentraise() { salary = salary * 1.10; void fivepercentraise() { raise(5); void tenpercentraise() { raise(10); Why were methods fivepercentraise and tenpercentraise left behind?

15 Replace Parameter with Explicit Method Original Code: def setvalue(name, vale): if (name == "width"): self.width = value if (name == "height"): self.height = value Refactored Code: def setwidth(vale): self.width = value def setheight(value): self.height = value def setvalue(name, vale): if (name == "width"): setwidth(value) if (name == "height"): setheight(value) Although the refactored code is longer, it is easier to read, and the method created may be useful elsewhere!

16 Introduce Explaining Variables Original Code: public double price() { //base price - volume discount + shipping return this.itemprice * quantity - Math.max(0, this.quantity - 500) * this.itemprice * Math.min(this.itemWeight * this.itemprice * 0.01, 100.0); Refactored Code: public double price() { final double baseprice = this.itemprice * quantity; final double volumediscount = Math.max(0, this.quantity - 500); final double shipping = Math.min(this.itemWeight * this.itemprice * 0.01, 100.0); return baseprice - volumediscount + shipping; This form of refactoring is purely about readability. The code created after refactoring is much easier to read for a future user. What other refactoring could be done on the refactored code?

17 More Interesting Refactoring These previous examples have all been fairly simple ways to refactor code, which are primarily based upon a mix of readability and efficiency of code. They are all based on specific methods or fields within an existing class. Next, we are going to dig into some more complex forms of refactoring. These will primarily focus on the design of the software, and will impact classes more than methods.

18 Extract Superclass Starting off with two classes that seem to be highly related, we want to determine if there is a way to build a logical superclass, which contains some of the common functionality and fields from the two distinct classes.

19 Extract Subclass Sometimes we will want to move in the opposite direction, and extract a subclass. When you start seeing large if blocks checking if flags are set on a class, usually this is a good time to see if the flagged items are unique enough to merit a new subclass be created.

20 Pull up method / field Sometimes, subclasses will all contain a similar method that in the majority of cases acts the same way. We want to reduce the amount of duplicate code, so these code pieces should be pulled up higher

21 Push Down Methods / fields Sometimes our super classes have fields not being used by all the subclasses. In these cases, we want to push the methods down.

22 Replace Inheritance with Delegations Sometimes, inheritance is not the best solution, and we are better to use delegations. Notice that the arrow has changed from a filled arrowhead to an open arrowhead. This means that the Stack will contain a vector that it will use.

23 Replace Inheritance with Delegation class Stack<E> { private Vector<E> vector; public Stack() { vector = new Vector<>(); public void push(e e) { vector.insertelementat(e, 0); public E pop() { E e = vector.elementat(0); vector.removeelementat(0); return e; public int size() { return vector.size(); public boolean isempty() { return vector.isempty();

24 Replace Delegation with Inheritance Sometimes, delegation is not the best strategy. While initially designing we may have decided to use the Object Adapter, based on the specific circumstance presented. Later, it might become apparent that a class Adapter was a much better choice When can we not do this?

25 Replace a Method with a Method Object public class Account { // don't try to figure out what this does public int gamma ( int inputval, int quantity, int yeartodate ) { int importantvalue1 = (inputval * quantity) + delta(); int importantvalue2 = (inputval * yeartodate) + 100; if.. // a very long and complicated computation // that makes heavy use of importantvalues return importantvalue3 factor() * importantvalue1;

26 Replace a Method with a Method Object public class Gamma { private final Account account; private int inputvalue;... private int importantvalue1; Gamma(Account account, int inval, int q, int ytd) { this.account = acc;... public class Account { // don't try to figure out what this does public int gamma ( int inputval, int quantity, int yeartodate ) { int importantvalue1 = (inputval * quantity) + delta(); int importantvalue2 = (inputval * yeartodate) + 100; if.. // a very long and complicated computation // that makes heavy use of importantvalues return importantvalue3 factor() * importantvalue1;

27 Replace a Method with a Method Object public class Gamma {... public int compute () { importantvalue1 = (inputval * quantity) + this.account.delta(); importantvalue = (inputval * yeartodate) + 100;. // and so on public class Account { public int gamma ( int inputval, int quantity, int yeartodate ) { return (new Gamma(this, inputval, quantity, yeartodate)).compute();

28 Replace Condition with Polymorphism private enum EmployeeType {ENGINEER, SALESMAN, MANAGER public double payamount() { switch (type) { case ENGINEER: return monthlysalary; case SALESMAN: return monthlysalary + commission; case MANAGER: return monthlysalary + bonus; default: throw new RuntimeException("Incorrect Employee");

29 Replace Condition with Polymorphism public class Employee { private EmployeeType type; double payamount() { return type.payamount(); public abstract class EmployeeType { public abstract double payamount(); public double payamount() { return monthlysalary; public double payamount() { return monthlysalary + commission; public double payamount() { return monthlysalary + bonus; In Engineer In SalesPerson In Manager

30 Replace Condition with Polymorphism What design pattern was this refactoring switching to?

31 Introduce null Object Sometimes we are required to make a very large number of null checks throughout our code in languages like Java where we can never be sure if a return is an object or a null. Customer customer if ( customer == null ) { plan = BillingPlan.basic(); else { plan = _customer.getplan(); if ( customer!= null ) { customer.setname(n); if ( customer!= null ) { points = _customer.getpoints(); else { points = 0;... Customer customer plan = customer.getplan(); customer.setname(n); points = customer.getpoints(); class NullCustomer extends Customer { public BillingPlan getplan() { return BillingPlan.basic(); public int getpoints() { return 0; public void setname(string n) {

32 Introduce Local Extension Sometimes there are classes that we want to add to, but we are unable to modify (such as a server side class).

33 Tease Apart Inheritance Sometimes we will find after inspecting our structure that there seems to be two jobs being done at once by all classes in a hierarchy

34 How to decide when to refactor It is always to your benefit to refactor if you have the time to do it. The challenge is, how do you find the easy to refactor pieces of code quickly? One way to determine this is using code smells. These are common issues that appear within code and begin to smell off. When we see (or smell) these issues, we want to take the appropriate actions, and refactor our code appropriately

35 Code Smells We have all come across code that just doesn t seem right when we look at it. Code smells are an attempt to cleanly classify what is causing us to say something is wrong, and give us options on how to quickly fix it. These smells are usually things you get better at identifying over time, but it is good to think about them early in your careers, and begin to take notice of them in code you are reviewing.

36 Code Smells (In reality, no one is going to be this mean to you! It is always good to understand what kind of things other developers are going to be looking for in your code, and what to look for in their code so that we can all make better software!)

37 Code Smells Bad smelling code can stink in one of two areas: 1. Within a specific class / method 2. Between classes (sometimes called design smells) There is no one exhaustive list of all the possible smells that may be detected in code, but there are many good lists out there. We will review several of the more common smells, and what to do about them, but I would also suggest reading more on your own time about these smells. A good starting place is What s a better name for Code Smells? COdours

38 Code Smell Taxonomy Bloaters Object Oriented Abusers Change Preventers Dispensables Couplers Long Method Large Class Primitive Obsession Long Parameter List Data Clumps Switch Statements Temporary Field Refused Bequest Alternative Classes with Different Interfaces Divergent Change Shotgun Surgery Parallel Inheritance Hierarchies Lazy class Data class Duplicate Code Dead Code Speculative Generality Comments! Feature Envy Inappropriate Intimacy Message Chains Middle Man

39 Bloaters What are they? Bloaters are smells representative of something that has grown too big. They can be too big themselves (Such as long methods) or something that inherently is seen when bloating is occuring (such as primitive obsession).

40 Long Methods The Smell: Long methods that have endless (exaggeration) amounts of code Why it s bad: When methods get very long, we immediately lose the ability to do two key things. The code becomes hard to expand further as the logic is hard to see, and the code becomes hard to read in general, requiring more time to be spent on it, when a necessary update occurs. The Solution: There are many solutions to this specific smell, depending on what has caused the method to grow. The first step is usually to see if there are any methods that can be extracted. There may be cases for introducing new parameters, or to simply build a method object

41 Large Classes The Smell: Seeing classes that are on the large slide, perhaps they have many parameters to their constructors, or they have a massive number of available methods Why it s bad: Large classes often have too many responsibilities, resulting in them having to be modified any time a new requirement is determined. Further to this, since they are large, each of these changes usually has a cascading effect throughout the code base The Solution: Extract a new class or classes to do some of the work. Extract subclasses or a new class hierarchy, extract interfaces to begin segregating different methods.

42 Primitive Obsession The Smell: You only see primitives or near primitives (strings, Arrays) anywhere you look in the code. Why it s bad: Again, we are using objects for a reason! Objects let us deal with pieces of code in a logical way for the given problem at hand. Primitives are great if you are doing something primitive. If you are doing something more advance, build a class to help! The Solution: Replace data values with objects. Encapsulate commonly seen together primitives in their own class, and begin to replace these uses with this class. Likely you will find certain operations continually being made on these primitives. These methods can later become class methods for the new class.

43 Long Parameter List The Smell: Seeing a very large list of parameters going into a method. Why it s bad: In procedural programming, this may make sense, but in Object Oriented Programming it likely makes more sense to pull together the data we need in cases like this into it s own object, and access as required by the method. This is a smell that suggests this method is going to be highly volatile. The Solution: Replace the parameters with an object, replace the whole method with an object, replace some parameters with a pre-calculation method*

44 Data Clumps The Smell: Do you always see the same couple pieces of data together in the code? Like any time there is a String name, there is also an int age? Then likely these data points belong together. Why it s bad: Likely we can make this code easier to follow and more efficient by replacing these clumps of data. The Solution: Bring together these data pieces into logical objects.

45 Object Oriented Abusers What are they? Object oriented abusers are any smells that come off of code that does not take full advantage of object orientation. If we are going to be object oriented in our code, we need to be diligent about it!

46 Switch Statements The Smell: Seeing the same switch statements elsewhere in the code. Why it s bad: This is really showing a lack of well built object orientation. Take advantage of polymorphism! (What pattern can you use here?) The Solution(s): Fowler Options: Introduce null object Replace type code with State/Strategy Kerievsky Options: Replace conditional dispatch with command Move accumulation to visitor Not that switch!

47 Temporary Fields The Smell: You will likely come across code at some point that has a field named tmp/temp/x/z/blah/asd that sometimes is used, and other times is not. This is a bad smell Why it s bad: This creates difficult to use code, and is often the result of someone attempting to fix another problem (usually Long Parameter List) unsuccessfully. The Solution: Depending on the situation either extract a class or method to assist in this specialized functionality, or perhaps create a null object if this field is being used for null cases. Sometimes, the correct solution is simply renaming the field to something more relevant!

48 Refused Bequest What do a dog and a table have in common? Should a dog inherit from a table? The Smell: Sometimes, contrary to what should be done, people make poor inheritance choices. Why it s bad: This creates lots of confusing and often dead methods (table s bark method returns null) The Solution: Replace inheritance with delegation if there is a need for something from one object!

49 Alternative Classes with Different Interfaces The Smell: Two classes that behave the same on the inside, but look very different on the outside. Why it s bad: Often the commonality of the two classes can be pulled into a new class that is not requiring duplicate code. This is often a symptom of many small teams working on one large code base. Each requiring it s own way of doing very similar things The Solution: Based on above, the most common clean solution is to replace a full class with an adapter class, altering the interface just enough for what is required.

50 Change Preventers What are they? Change preventers are smells that are going to make it difficult to complete future changes. They are smells belonging to pieces of code that will likely prevent us from easily meeting our next mile stone. These types of smells are often signs of poor architectural choices being made.

51 Divergent Change The Smell: The given class is being changed a lot, for a lot of different reasons Why it s bad: This implies that the class must be doing many different things, and thus does not only have a single responsibility The Solution: The only real solution here is to look at what can be extracted into a new class or new classes

52 Shotgun Surgery The Smell: Making a change to one class causes cascading changes throughout the entire code base, regardless of the size of the initial change Why it s bad: This means you have high coupling throughout your code! The Solution: You will need to move around fields, and methods to try and make things less interdependent. Try looking for ways to create consolidated interfaces for the code

53 Parallel Inheritance Hierarchies The Smell: Any time Object family A grows by a class, object family B also grows by a class Why it s bad: This is really a special case of shotgun surgery (at the architecture level). You are going to likely need to modify hierarchies. The Solution: Look at ways of decoupling the two interdependent hierarchies. Can anyone think of a case where this was actually suggested by course material? What gives?

54 Dispensables What are they? Dispensables are the saddest of smells. They are not really needed. They are the useless, leftover, pointless items that for some reason, somebody included. They usually cause us to spend a great deal more time pondering their existence than we ought to have. They really would be better just not there. Why am I even here?

55 Lazy Class (Freeloader) The Smell: There is a class that whenever it is called upon, it passes its responsibility off to some other class or classes. It really isn t pulling its weight. Why it s bad: If something isn t doing enough, it should be taken out for both efficiency and readability of the code The Solution: Collapse the hierarchy, move responsibilities to their rightful owners

56 Data Class The Smell: Classes that only contain Fields, setters, and getters. Why it s bad: These classes, similar to lazy classes, are likely passing their responsibilities off to others to complete. These often appear as a result of someone attempting to fix primitive obsession. The Solution: Move methods into these classes, make them valuable!

57 Duplicate Code The Smell: The number one most common smell. This is seen more than any other smell. This is also known as copy paste code. This is referring to explicitly copied code. There can also be a lesser smell of subtly different copies code. Why it s bad: What happens when you need to modify that segment of logic? How do you know where all the copied code is? The Solution: If you hit ctrl+c, then move elsewhere in a file, and press ctrl+v question your choice. Prevention is the best cure! If you can t prevent (because it wasn t your mistake!) then look at factoring out a method to replace this repeated code. There are many other solutions, depending on the specific violation.

58 Dead Code The Smell: This is code that is never being used. Not rarely, but never. Code that either used to have a purpose, but no longer does, or code that may be used in the future (more on this later). Why it s bad: Dead code is useless, and can potentially introduce extra complexities to the logic of our programs that are unnecessary. The Solution: Delete it. (Use version control of course).

59 Speculative Generality The Smell: Futureproofing the code. Coding for what we think will happen. You will see code that is not used, and was never asked for by business. Often hidden below an if(false) statement or something similar to block its usage. Why it s bad: We can t predict the future, often times this is just wasted space and time. Sometimes, it can be even worse and make people believe a feature is there, that is not actually available. The Solution: Delete it! Version control will keep it if it was actually needed. The users would love that feature! Make it for when they ask! They will ask!

60 Comments The Smell: Comments inline comments especially. Why it s bad: Good code documents itself The Solution: Read the code associated with the comments, try and rename fields and variables to make it more comprehensible, so that the comments can be removed.

61 Couplers What are they? These smells represent a high level of coupling. As we ve talked about earlier this semester, coupling is bad. We want to strive to remove as much tight coupling as possible within our code base. These smells are good for identifying where coupling is occurring. By finding where, you can fix the problem. This is what leads to emergent architecture! Finding areas that ended up being more coupled than expected initially often suggest a change is needed to the system design.

62 Feature Envy The Smell: When a class is always calling on another class to help it in preparing it s data and getting it s variables in order, likely you have feature envy. Why it s bad: This is creating strong coupling between classes that may be entirely unnecessary The Solution: When a method is called more by another class than the class it is in, likely that method belongs in the other class, move it!

63 Inappropriate Intimacy The Smell: Do you see two classes together all the time? If class A is there, class B is surely to be called along soon? Or perhaps, they communicate in ways that are not appropriate (such as avoiding an interface and directly interacting) Why it s bad: This type of tight coupling often implies there is more going on with these classes than there should be. It can cause delays, or even expose information in ways we do not wish it to be. The Solution: Replace inheritance with delegation, move methods or fields around, change a currently bidirectional relationship with a unidirectional association. Attempt to reduce the coupling!

64 Message Chains The Smell: When you see a very long, consistent chain of fields or method calls being made in a row any time a piece of information is needed Why it s bad: This makes your code highly dependent on everything within this chain. These different objects have a high probability of being unrelated, and thus, might all have changes on different schedules. The Solution: Try and adjust where methods are, either by moving them up or down the chain, or perhaps, create a new interface (adapter) to help in the preparation.

65 Middle Men The Smell: If a class is delegating all of its work between other classes, or is working simply as a tunnel between two classes, what is its purpose? Why it s bad: These delegations are dependencies in disguise! We want to avoid creating large numbers of unnecessary calls. The Solution: Replace delegation with inheritance often will help in these cases. If not, kill the middle man. Middle man could also potentially be classified as a disposable.

66 Code Smells What s important to know It s important to understand that each given code smell comes with a list of common refactoring practices that can fix it. Knowing how to identify when refactoring is needed will help you in your career, as well as on being a better developer.

67 Questions?