Android Refactoring
•
3 likes•1,443 views
The document discusses refactoring code to improve its structure and readability without changing its external behavior. It defines refactoring as restructuring software to make it easier to understand and modify. The goals of refactoring are to reduce technical debt by improving code quality. Examples show refactoring an Android app by extracting methods, renaming variables for clarity, and converting the architecture to MVP pattern to separate concerns. Lessons recommend writing unit tests first and using metrics as a guide rather than mandate when refactoring.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Android Refactoring
Similar to Android Refactoring (20)
More from Godfrey Nolan
More from Godfrey Nolan (20)
Recently uploaded
Recently uploaded (16)
Android Refactoring
- 2. "Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler
- 4. Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. "Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behavior". - Martin Fowler
- 6. "Technical debt ..[is]... the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer". - Wikipedia
- 10. Keep it Objective 9/25/17 Refactoring 10
- 11. Keep it Objective 9/25/17 Refactoring 11
- 17. What’s the Process? 9/25/17 Refactoring 17
- 24. Pull Members Up 9/25/17 Refactoring 24
- 25. Pull Members Down 9/25/17 Refactoring 25
- 26. Convert Anonymous to Inner 9/25/17 Refactoring 26
- 27. Replace Temp with Query 9/25/17 Refactoring 27
- 30. Lets Begin – Kent Beck Rules 9/25/17 Refactoring 30 • Passes all the tests • Reveals Intent • Don’t repeat yourself • Fewer Parts
- 32. Example 1 – Extract Method 9/25/17 Refactoring 32
- 33. Example 1 – Rename 9/25/17 Refactoring 33
- 34. Example 1 – Move Method 9/25/17 Refactoring 34
- 35. Example 1 – Replace Temp With Query 9/25/17 Refactoring 35
- 36. Example 1 – Extract Method 9/25/17 Refactoring 36
- 37. Example 1 – Replace Temp With Query 9/25/17 Refactoring 37
- 38. Example 1 – Replace Temp With Query 9/25/17 Refactoring 38
- 39. Example 1 – Measure Once, Cut Twice 9/25/17 Refactoring 39
- 40. 9/25/17 Refactoring 40 public String statement() { double totalAmount = 0; int frequentRenterPoints = 0; Enumeration rentals = _rentals.elements(); String result = "Rental Record for " + getName() + "n"; while (rentals.hasMoreElements()) { double thisAmount = 0; Rental each = (Rental) rentals.nextElement(); //determine amounts for each line switch (each.getMovie().getPriceCode()) { case Movie.REGULAR: thisAmount += 2; if (each.getDaysRented() > 2) thisAmount += (each.getDaysRented() - 2) * 1.5; break; case Movie.NEW_RELEASE: thisAmount += each.getDaysRented() * 3; break; case Movie.CHILDRENS: thisAmount += 1.5; if (each.getDaysRented() > 3) thisAmount += (each.getDaysRented() - 3) * 1.5; break; } // add frequent renter points frequentRenterPoints++; // add bonus for a two day new release rental if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE) && each.getDaysRented() > 1) frequentRenterPoints++; //show figures for this rental result += "t" + each.getMovie().getTitle() + "t" + String.valueOf(thisAmount) + "n"; totalAmount += thisAmount; } //add footer lines result += "Amount owed is " + String.valueOf(totalAmount) + "n"; result += "You earned " + String.valueOf(frequentRenterPoints) + " frequent renter points"; return result; }
- 41. 9/25/17 Refactoring 41 public String statement() { String result = "Rental Record for " + getName() + "n"; for (Rental each : rentals) { // show figures for this rental result += "t" + each.getMovie().getTitle() + "t" + each.getCharge() + "n"; } // add footer lines result += "Amount owed is " + getTotalCharge() + "n"; result += "You earned " + getTotalFrequentRenterPoints() + " frequent renter points"; return result; } private double getTotalCharge() { double totalCharge = 0; for (Rental each : rentals) { totalCharge += each.getCharge(); } return totalCharge; } private int getTotalFrequentRenterPoints() { int totalFrequentRenterPoints = 0; for (Rental each : rentals) { totalFrequentRenterPoints += each.getFrequentRenterPoints(); } return totalFrequentRenterPoints; }
- 42. 9/25/17 Refactoring 42 double getCharge(int numberOfDaysRented) { double result = 2; if (numberOfDaysRented > 2) { result += (numberOfDaysRented - 2) * 1.5; } return result; } public void setPriceCode(int priceCode) { switch (priceCode) { case REGULAR: price = new RegularPrice(); break; case CHILDRENS: price = new ChildrensPrice(); break; case NEW_RELEASE: price = new NewReleasePrice(); break; default: throw new IllegalArgumentException("illegal price code"); } }
- 43. Example 2 – Convert app to MVP 9/25/17 Refactoring 43
- 44. Example 2 – Extract Delegate 9/25/17 Refactoring 44
- 45. Example 2 – Create Interface 9/25/17 Refactoring 45
- 46. Example 2 – Fix Activity 9/25/17 Refactoring 46
- 47. Example 2 – Fix Presenter 9/25/17 Refactoring 47
- 50. Lessons Learned 9/25/17 Refactoring 50 • Default Android design pattern is Ball of Mud • Always create unit tests • Use the metrics as a guide not as a mandate • Measure early, measure often • Think twice before you do a complete rewrite
- 51. Resources • https://dev.to/rly • http://www.mikamantyla.eu/BadCodeSmellsTaxonomy.html • https://sonarcloud.io • https://plugins.jetbrains.com/plugin/93-metricsreloaded • https://github.com/LiushuiXiaoxia/AndroidStudioRefactor • https://github.com/mroderick/refactoring-day • https://www.safaribooksonline.com/library/view/developing -high-quality/9781771375580/ • https://medium.com/google-developers/viewmodels-a- simple-example-ed5ac416317e 9/25/17 Refactoring 51
Editor's Notes
- Why am I doing this – writing a book on MVC, MVP and Clean in Android and started using refactoring to move from one pattern to another. Lessons Learned – write lots of unit tests and UI tests so your refactoring doesn’t break anything.
- Android doesn’t promote good design, it encourages putting everything in a small number of activities. Complexity goes through the roof? Refactoring is also really useful if you want to start moving from a classic android design to an MVP type design.
- Definition
- Technical Debt If you ever hear anyone say – it’s going to be cheaper to rewrite it than add another feature – then you know you’ve lost
- Make sure you have some unit tests and Espresso tests so that when you finish your refactoring you can be sure it’s still working Remove any duplicate code
- Anything in a program's source code that suggests the presence of a designproblem.
- Comes from A Taxonomy for "Bad Code Smells” link at the end of the talk
- Bloater smells represents something that has grown so large that it cannot be effectively handled. ANDROID It seems likely that these smells grow a little bit at a time. Hopefully nobody designs, e.g., Long Methods. Primitive Obsession is actually more of a symptom that causes bloats than a bloat itself. The same holds for Data Clumps. When a Primitive Obsession exists, there are no small classes for small entities (e.g. phone numbers). Thus, the functionality is added to some other class, which increases the class and method size in the software. With Data Clumps there exists a set of primitives that always appear together (e.g. 3 integers for RGB colors). Since these data items are not encapsulated in a class this increases the sizes of methods and classes.
- Android doesn’t promote good design, it encourages putting everything in a small number of activities. Complexity goes through the roof? Refactoring is also really useful if you want to start moving from a classic android design to an MVP type design.
- The common denominator for the smells in the Object-Orientation Abuser category is that they represent cases where the solution does not fully exploit the possibilities of object-oriented design. For example, a Switch Statement might be considered acceptable or even good design in procedural programming, but is something that should be avoided in object-oriented programming. The situation where switch statements or type codes are needed should be handled by creating subclasses. Parallel Inheritance Hierarchies and Refused Bequest smells lack proper inheritance design, which is one of the key elements in object-oriented programming. The Alternative Classes with Different Interfaces smell lacks a common interface for closely related classes, so it can also be considered a certain type of inheritance misuse. The Temporary Field smell means a case in which a variable is in the class scope, when it should be in method scope. This violates the information hiding principle.
- Change Preventers are smells is that hinder changing or further developing the software These smells violate the rule suggested by Fowler and Beck which says that classes and possible changes should have a one-to-one relationship. For example, changes to the database only affect one class, while changes to calculation formulas only affect the other class. The Divergent Change smell means that we have a single class that needs to be modified by many different types of changes. With the Shotgun Surgery smell the situation is the opposite, we need to modify many classes when making a single change to a system (change several classes when changing database from one vendor to another) Parallel Inheritance Hierarchies, which means a duplicated class hierarchy, was originally placed in OO-abusers. One could also place it inside of The Dispensables since there is redundant logic that should be replaced.
- The common thing for the Dispensable smells is that they all represent something unnecessary that should be removed from the source code. This group contains two types of smells (dispensable classes and dispensable code), but since they violate the same principle, we will look at them together. If a class is not doing enough it needs to be removed or its responsibility needs to be increased. This is the case with the Lazy class and the Data class smells. Code that is not used or is redundant needs to be removed. This is the case with Duplicate Code, Speculative Generality and Dead Code smells.
- One design principle that has been around for decades is low coupling (Stevens et al. 1974) . This group has 3 smells that represent high coupling. Middle Man smell on the other hand represent a problem that might be created when trying to avoid high coupling with constant delegation. Middle Man is a class that is doing too much simple delegation instead of really contributing to the application. The Feature Envy smell means a case where one method is too interested in other classes, and the Inappropriate Intimacy smell means that two classes are coupled tightly to each other. Message Chains is a smell where class A needs data from class D. To access this data, class A needs to retrieve object C from object B (A and B have a direct reference). When class A gets object C it then asks C to get object D. When class A finally has a reference to class D, A asks D for the data it needs. The problem here is that A becomes unnecessarily coupled to classes B, C, and D, when it only needs some piece of data from class D. The following example illustrates the message chain smell: A.getB().getC().getD().getTheNeededData() Of course, I could make an argument that these smells should belong to the Object-Orientation abusers group, but since they all focus strictly on coupling, I think it makes the taxonomy more understandable if they are introduced in a group of their own.
- No better way to learn about refactoring than to see how its used.
- ename an object or resource, and all use of this object or resource, will be renamed.
- The Change Signature refactoring combines several different modifications that can be applied to a method signature. When changing a method signature, IntelliJ searches for all usages of the method and updates all the calls, implementations, and override replacements of the method that can be safely modified to reflect the change. Use this refactoring for the following purposes: To change the method name. To change the method return type. To add new parameters and remove the existing ones. To assign default values to the parameters. To reorder parameters. To change parameter names and types. To propagate new parameters through the method call hierarchy.
- The Change Class Signature refactoring lets you turn a class into a generic and manipulate its type parameters. The refactoring automatically corrects all calls, implementations and overridings of the class. Use this refactoring for the following purposes: Turn a class into a generic Manipulate its type parameters
- First we can make a class static After the refactoring we need to access myClassField through the constructor.
- And we can make a method static It converts an instance method to a static one and automatically corrects all calls, implementations and overridings of the method.
- Move refactorings allow you to move packages and classes between the source roots of a project, class members to other classes and inner classes to upper hierarchy levels. The move refactorings automatically correct all references to the moved packages, classes and members in the source code. Here we’re just moving a class to a higher level. Note the RefactorDemo class when we’re done.
- Simple call copy
- When the Extract Method refactoring is invoked , IntelliJ IDEA analyses the selected block of code and detects variables that are the input for the selected code fragment and the variables that are output for it Can also extract into a class.
- You can also extract constants, variables,
- You can also extract variables and method parameters
- The Invert Boolean refactoring allows you to change the sense of a Boolean method or variable to the opposite one.
- The Pull Members Up refactoring allows you to move class members to a superclass or an interface,
- The Push Members Down refactoring helps clean up the class hierarchy by moving class members to a subclass
- The Remove Middleman refactoring allows you to replace all calls to delegating methods in a class with the equivalent calls directly to the field delegated to. Additionally, you can automatically remove the classes delegating methods, which will now be unused. The original OrderManager holds a List to save the Order, the caller directly uses OrderManager to process the order, remove the middleman means that the call method directly to save the order of the container, the caller directly control the container.
- The Wrap Return Value refactoring allows you to select a method, and either create a wrapper class for its return values, or use an existing, compatible wrapper class. All returns from the method selected will be appropriately wrapped, and all calls to the method will have their returns unwrapped.
- This is my favorite one function, at the beginning class logic is very simple, but before too long the logic gets too complex, so you can use the shortcut keys to create an inner class.
- Encapsulate Fields lets you hide your data and access it through getters and setters.
- Move the constructor method into a factory, then its construction parameters are private, so that the caller can only be generated by the factory method And not directly by the constructor.
- Automatically add generic parameters.
- No better way to learn about refactoring than to see how its used.
- This is a sample app refactoring animated loop, where a single activity is refactored into 3 classes
- I couldn’t find anything on this that was specific to Android these are the two more general tomes. At this point, Android Studio has lots of other refactoring features for you to explore. For people who are trying to tidy their code there is nothing stopping you from using this approach.
- Ever wondered what the Refactor tab does in Android Studio? In this session we'll go through each of the refactoring options in Studio and show you how applying them to your code will improve it's maintainability, scalability and overall design.