Refactoring and such

1. Refactoring and such • (Side note) Specialization • Key terms • Abstraction, state, persistence and association and their relationship to software development • Evolution and its relation to iteration • Refactoring and its relation to abstraction and iteration • Refactoring • Code Smells • Refactoring catalogue • Composing Methods • Moving features between objects • Organizing data • Simplfying conditional expressions • Making method calls simpler • Dealing with Generalization • Big refactorings

2. Abstraction • The act of abstracting, separating, or withdrawing, or the state of being withdrawn; withdrawal. • The act process of leaving out of consideration one or more properties of a complex object so as to attend to others; analysis. Thus, when the mind considers the form of a tree by itself, or the color of the leaves as separate from their size or figure, the act is called abstraction. So, also, when it considers whiteness, softness, virtue, existence, as separate from any particular objects. • Abstraction is necessary to classification, by which things are arranged in genera and species. We separate in idea the qualities of certain objects, which are of the same kind, from others which are different, in each, and arrange the objects having the same properties in a class, or collected body. - Webster's Revised Unabridged Dictionary (1913)

3. State • The circumstances or condition of a being or thing at any given time. • State is the generic term, and denotes in general the mode in which a thing stands or exists. The situation of a thing is its state in reference to external objects and influences; its condition is its internal state, or what it is in itself considered. Our situation is good or bad as outward things bear favorably or unfavorably upon us; our condition is good or bad according to the state we are actually in as respects our persons, families, property, and other things which comprise our sources of enjoyment. • A state may be considered to be a point in some space of all possible states. A simple example is a light, which is either on or off. A complex example is the electrical activation in a human brain while solving a problem. In computing and related fields, states, as in the light example, are often modelled as being discrete (rather than continuous) and the transition from one state to another is considered to be instantaneous. Another (related) property of a system is the number of possible states it may exhibit. This may be finite or infinite. A common model for a system with a finite number of discrete state is a finite state machine.

4. Persistence/Persistent & Association • The quality or state of being persistent; staying or continuing quality • Persistent: Inclined to persist; having staying qualities • Persist: To stand firm; to be fixed and unmoved; to stay; to continue steadfastly; especially, to continue fixed in a course of conduct against opposing motives • Association: The act of associating, or state of being associated; union; connection, whether of persons of things.

5. Evolution • A general name for the history of the steps by which any living organism has acquired the morphological and physiological characters which distinguish it; a gradual unfolding of successive phases of growth or development. • That series of changes under natural law which involves continuous progress from the homogeneous to the heterogeneous in structure, and from the single and simple to the diverse and manifold in quality or function. The process is by some limited to organic beings; by others it is applied to the inorganic and the psychical. It is also applied to explain the existence and growth of institutions, manners, language, civilization, and every product of human activity. The agencies and laws of the process are variously explained by different philosophers • a process in which something passes by degrees to a different stage (especially a more advanced or mature stage)

6. Iteration and Refactoring • Doing or saying again; a repeated performance • Repetition; To utter or do a second time or many times; to repeat; as, to iterate advice. • Software evolves through iteration. • Refactoring: Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves the internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence, when you refactor you are improving the design of the code after it has been written. • With refactoring, you can take a bad design, chaos even, and rework it into well designed code. Each step is simple, even simplistic. [...] Yet the cumulative effect of these small changes can radically improve the design. It is the exact reverse of the normal notion of software decay.

7. Refactoring and Unit Testing • The first step of refactoring is always the same: build a solid set of tests for that section of code. The tests are essential because even though refactorings have been created in such a manner as to reduce the opportunities to make errors, humans still make mistakes. • Modifying existing code changes its design. In the case of refactoring, we want to change the design of code so that it is better structured. We are not trying to change WHAT the code does. Unit tests help us to ensure that what the code is doing remains the same. Your strength of judgement in this respect is is solely based on the strength of your unit tests • Unit tests need to be fully automatic and check their own results.

8. Software Evolution • When developing software using refactoring, you are essentially performing 2 functions: • Adding new functionality • Refactoring • When you add functionality, you should not change existing code • When you refactor, you should not add or change functionality • When to refactor? • Refactor when you add a function to the software • Refactor when you need to fix a bug • Refactor when you do a code review

9. Refactoring • When developing software using refactoring, you are essentially performing 2 functions: • Adding new functionality • Refactoring • When you add functionality, you should not change existing code • When you refactor, you should not add or change functionality • When to refactor? • Refactor when you add a function to the software • If adding a new function is difficult, refactor to make it easy • Refactor when you need to fix a bug • Bugs can hide in bad code. Improve the code to help make bugs easier to find and fix • Refactor when you do a code review

10. Code Smells • Knowing what to refactor can be the difficult part. • Experience has shown us that poor code tends to contain certain structures or features which alert the programmer to refactoring possibilities • Based on judgement of the programmer, but the idea of “code smells” helps an abstract concept to a more concrete state.

11. Catalogue of Code Smells • Duplicated Code • Long Method • Large Class (Cohesion) • Long Parameter List • Divergent Change (Cohesion) • Shotgun surgery (opposite to divergent change) • Feature envy (Cohesion/Coupling) • Data Clumps (Cohesion) • Primitive Obsession • Switch statements • Parallel Inheritance Hierarchies • Lazy class • Speculative Generality • Temporary field (State issues) • Message chains • Middle man • Inappropriate intimacy • Alternative Classes with Different Interfaces • Incomplete Library Class • Data Class • Refused Bequest • Comments

12. Refactoring Catalogue • Chapters 6-12 form the catalogue of refactorings. Each refactoring contains: • A name • A summary • A motivation • The mechanics • Code examples (some of which are somewhat contrived) • The refactoring catalogue contains the following sections: • Composing Methods • Moving features between objects • Organizing data • Simplfying conditional expressions • Making method calls simpler • Dealing with Generalization • Big refactorings

13. Composing methods • Procedural solutions (which most people are familiar with) tend to produce long sequences of commands. (ie. Procedures). • These procedures are generally not cohesive for a given object. • Long procedures usually involve more than one type of object, therefore, the responsibility contained within the procedure should be distributed amongst multiple object methods. • The most common refactorings are: • Extract Method • Replace Temp with Query • Inline Temp • Split Temporary Variable

14. Moving features between objects • This section generally deals with cohesion problems. • When creating an object model, determining where to place various responsibilities can be a difficult task. If you have made a poor choice, moving things between objects can help improve cohesion. • Most common refactorings: • Move Method • Move Field • Extract Class/Inline Class • Hide Delegate/Remove Middle Man

15. Organizing data • Persons who have learned procedural methods of programming often deal with data in a manner which is a best fit for the OO world. • Common refactorings include: • Self encapsulate field • Replace data value with object • Replace array with object • Change unidirectional association to bidirectional • Change bidirectional association to unidirectional • Replace type code with state.

16. Simplifying conditional expressions • One of the problems with structured programming is that in order to maintain the proper structure, somewhat convoluted conditional expressions can be required • Object oriented programs generally have less conditional behavior because much conditional behavior can be handled using polymorphism • Common refactorings include: • Decompose Conditional • Consolodate Conditional Expression • Replace nested conditional with guard clauses • Remove control flag • Replace conditional with polymorphism • Introduce null object

17. Making method calls simpler • One of the keys to OO is the focus on the interface of objects rather than their internals • It is not terribly useful if object's interfaces are needlessly complex. • One of the most common mistakes is that the name of the method does not really reflect what the method is doing. • Common refactorings include: • Rename method • Add Parameter/Remove Parameter • Introduce parameter object • Replace parameter with method • Separate query from modifier • Replace constructor with Factory method

18. Dealing with Generalization • Because most people do not think well in the abstract, their inheritance hierarchies are often poorly designed. • Refactorings in this section deal mostly with moving fields and methods around the inheritance hierarchy • Common refactorings are: • Pull up field/ Push down field • Pull up method/Push down method • Extract subclass/Extract superclass • Extract Interface • Replace inheritance with delegation

19. Big refactorings • Most refactorings are small steps. There are some that are not. • The big refactorings are: • Tease apart inheritance • Convert procedural design to objects • Separate domain from Presentation • Extract Hierarchy