Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Refactoring Patterns in Software Engineering: Lecture 10 by Raman Ramsin, Slides of Software Engineering

A series of lecture notes from a university course on software engineering at sharif university of technology. The notes cover the topic of refactoring patterns, including definitions, benefits, and symptoms of bad code. The document also introduces various refactoring patterns and categories, such as composing methods, moving features between objects, and dealing with generalization. Students will find this document useful for understanding the concepts of refactoring and how to improve the design of existing code.

Typology: Slides

2011/2012

Uploaded on 02/19/2012

hester
hester 🇮🇷

4.5

(13)

85 documents

1 / 20

Toggle sidebar

Related documents


Partial preview of the text

Download Refactoring Patterns in Software Engineering: Lecture 10 by Raman Ramsin and more Slides Software Engineering in PDF only on Docsity!

Patterns in Software Engineering Lecturer: Raman Ramsin^ Lecture 10^ Refactoring Patterns

Part 1

1

Sharif University of Technology

Part^

1

Patterns in Software Engineering – Lecture 10 Refactoring: DefinitionRefactoring:

Definition

„^ Refactoring:^

A change made to the internal structure of software tomake it^ „^ easier to understand, and^ „^ cheaper to modify.

^ The observable behavior of the software should not bechanged.

2

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Refactoring: Why?Refactoring:

Why?

„^ Why Should You Refactor?^

Refactoring Improves the Design of Software

Refactoring Makes Software Easier to Understand Refactoring Helps You Find Bugs Refactoring Helps You Program Faster

3

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Refactoring: When?Refactoring:

When?

„^ When Should You Refactor? „^ When

Should You Refactor?

^ Refactor the third time you do something similar (The Rule ^ Refactor

the third time you do something similar (The Rule
of Three)

Refactor When You Add Function Refactor When You Need to Fix a Bug Refactor As You Do a Code Review

4

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Symptoms of Bad Code (1)Symptoms

of Bad Code (1)

1.^ Duplicated Code2.^ Long Method3.^ Large Class

g

4.^ Long Parameter ListDi

t Ch^

Wh^

l^ i^

l^ h^

d i^ diff

t

5.^ Divergent Change:

When one class is commonly changed in different

ways for different reasons. 6 Shotgun Surgery:

When every time you make a kind of change

you

6.^ Shotgun Surgery:

When

every time you make a kind of change, you

have to make a lot of little changes to a lot of different classes. 7 Feature Envy:

A method that seems more interested in a class other than

7.^ Feature Envy:

A^ method that seems more interested in a class other than the one it actually is in. 8 Data Clumps:

Bunches of data that regularly appear together

5

Sharif University of Technology

8.^ Data Clumps:

Bunches

of data that regularly appear together.

Patterns in Software Engineering – Lecture 10 Symptoms of Bad Code (2)Symptoms

of Bad Code (2)

9.^ Primitive Obsession:

Excessive use of primitives, due to reluctance to

p^

,

use small objects for small tasks. 10. Switch Statements11. Parallel Inheritance Hierarchies:

Where every time you make a

subclass of one class, you also have to make a subclass of another. 12. Lazy Class:

A class that isn't doing enough to justify its maintenance. 13 Speculative Generality:

Classes and features have been added just

13.^ Speculative Generality:

Classes

and features have been added just

because a need for them may arise someday. 14 Temporary Field:

An instance variable that is set only in certain

14.^ Temporary Field:

An^ instance variable that is set only in certain

circumstances. 15. Message Chains:

Transitive visibility chains.

6

Sharif University of Technology

15.^ Message

Chains:

Transitive

visibility chains.

Patterns in Software Engineering – Lecture 10 Symptoms of Bad Code (3)Symptoms

of Bad Code (3)

16 Middle Man:

Excessive delegation

16.^ Middle Man:

Excessive

delegation.

17.^ Inappropriate Intimacy:

Excessive interaction and coupling.

18.^ Alternative Classes with Different Interfaces:

Classes that do the

same thing but have different interfaces for what they do. 19. Incomplete Library Class20. Data Class:

Classes that have fields, getting and setting methods for the fields, and nothing else. 21. Refused Bequest:

When subclasses do not fulfill the commitments of

h^

l their superclasses. 22. Comments:

When comments are used to compensate for bad code.

7

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Refactoring Patterns: CategoriesRefactoring

Patterns: Categories

„^ Composing Methods:
Packaging code properly
p^
g^
g^ g^
p^ p^
y
„^ Moving Features Between Objects:
Reassigning responsibilities
O^
i i^
D t^
M ki^
d t^
i^ t^
k^ ith
„^ Organizing Data:
Making data easier to work with
„^ Simplifying Conditional Expressions:
Making conditional logic
less e
o^ p one
less error-prone „ Making Method Calls Simpler:
Making interfaces easy to
understand and useunderstand and use „ Dealing with Generalization:
Moving features around a hierarchy
of inheritanceof inheritance „ Big Refactorings:
Large-scale changes to code

8

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Composing Methods:

Extract Method

Composing

Methods:

Extract
Method

„^ Extract Method^ ^

You have a code fragment that can be grouped together You^ have a code fragment that can be grouped together. Turn the fragment into a method whose name explains the purpose of themethod.

9

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Composing Methods:

Inline Method

Composing

Methods:

Inline
Method

„^ Inline Method^ ^

A method

's body is just as clear as its name

^ A method s body is just as clear as its name. ^ Put the method's body into the body of its callers and remove the method. Department of Computer Engineering

10

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Composing Methods:

Replace Method with Method Object

Composing

Methods:

Replace
Method with Method Object

„^ Replace Method with Method Object^ ^

You have a long method that uses local variables in such a way that you cannot You^ have a long method that uses local variables in such a way that you cannotapplyExtract Method. Turn the method into an object so that all the local variables become fields onthat object

It can then be decomposed into other methods on the same object that object. It can then be decomposed into other methods on the same object.

11

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Moving Features Between Objects:

Move Method

Moving

Features Between Objects:

Move
Method

Mo e Method „ Move Method^ ^ A method is, or will be, using or used by more features of another class than theclass on which it is defined.^ ^ Create a new method with a similar body in the class it uses most. Either turnthe old method into a simple delegation, or remove it altogether. Department of Computer Engineering

12

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Moving Features Between Objects:

Move Field

Moving

Features Between Objects:

Move
Field

„^ Move Field^ ^

A field is, or will be, used by another class more than the class on which it isdefined. Create a new field in the target class, and change all its users.

13

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Moving Features Between Objects:

Extract Class

Moving

Features Between Objects:

Extract
Class

„^ Extract Class^ ^

You have one class doing work that should be done by two. Create a new class and move the relevant fields and methods from the old class Create a new class and move the relevant fields and methods from the old classinto the new class.

14

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Moving Features Between Objects:

Inline Class

Moving

Features Between Objects:

Inline
Class

„^ Inline Class^ ^

A class isn't doing very much. Move all its features into another class and delete it Move all its features into another class and delete it.

15

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Moving Features Between Objects:

Hide Delegate

Moving

Features Between Objects:

Hide
Delegate

„^ Hide Delegate

g

^ A client is calling a delegate class of an object. ^ Create methods on the server to hide the delegate. Department of Computer Engineering

16

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Moving Features Between Objects:

Remove Middle Man

g^

j

„^ Remove Middle Man^ ^

A class is doing too much simple delegation. Get the client to call the delegate directly.

17

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Moving Features Between Objects:

Introduce Method/Class

g^

j

„^ Introduce Foreign Method^

^

A server class you are using needs an additional method, but you can'tmodify the classmodify the class. Create a method in the client class with an instance of the server classas its first argument.

g

„^ Introduce Local Extension^

^

A server class you are using needs several additional methods, but youcan't modify the class.C^ t

l^ th t

t i

th^

t^

th d^

M k^

thi

^ Create a new class that contains these extra methods. Make thisextension class a subclass or a wrapper of the original.Department of Computer Engineering

18

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 Moving Features Between Objects:
Introduce Local Extension
g^
j

19

Sharif University of Technology

Patterns in Software Engineering – Lecture 10 R fReference „ Fowler, M.,

Refactoring: Improving the Design of Existing Code,

Addison-Wesley, 1999.Department of Computer Engineering

20

Sharif University of Technology