AGILE DEVELOPMENT /

o m
. c
AND UI/UX DESIGN e s s
SUBJECT CODE: 3171610 p r
r d
o
UNIT-1 . w
il t
t e
AGILE DEVELOPMENT p a METHODS:
a j
PHILOSOPHY
: / / AND PRACTICE
p s
t t
h PREPARED BY: AMITKUMAR J PATEL
 /
History of Agile Methods
o m
s . c
 Particularly in 1990s, some developers reacted
e s against
traditional “heavyweight” software development
p r processes.
 New methods were being developed and
r d development
tested,

Generally termed “light” processes o

 e.g. extreme programming, SCRUM, Feature-driven


t . w
 “Representatives” from several
l i of these methods got together
in Utah in 2001
t e

Called themselves p
a
Settled on term “Agile” as a way to describe these methods


a j the “Agile Alliance”


/
Developed a “manifesto”
Focuses on/common
:
and a statement of “principles”
themes in these alternative methodologies
s


t t p
h
 /
History of Agile Methods
o m
s . c
 Particularly in 1990s, some developers reacted
e s against
traditional “heavyweight” software development
p r processes.
 New methods were being developed and
r d development
tested,

Generally termed “light” processes o

 e.g. extreme programming, SCRUM, Feature-driven


t . w
 “Representatives” from several
l i of these methods got together
in Utah in 2001
t e

Called themselves p
a
Settled on term “Agile” as a way to describe these methods


a j the “Agile Alliance”


/
Developed a “manifesto”
Focuses on/common
:
and a statement of “principles”
themes in these alternative methodologies
s


t t p
h
 /
Manifesto for Agile Software Development
o m
s . c
e s
r
We are uncovering better ways of developing
p
software by doing it and helping others do it.
d
Through this work we have come
o r to value:

t . w
Individuals and interactions
l i over processes and tools
Working software over
t e comprehensive documentation

p
Customer collaborationa
j
over contract negotiation
Responding
/ a to change over following a plan
: /
p s
t t
h
 /
12 Principles behind the Agile Manifesto
o m
s . c
Our highest priority is to satisfy the s
e of valuable
customer
r
1.

through early and continuous delivery

d p
software.
o r
2.Welcome changing requirements,
. w even late in
il t
development. Agile processes harness change for
t e advantage.
the customer's competitive
p a
3.Deliver working
couple of a j software frequently, from a

:
preference / weeks to a couple of months, with a
/ to the shorter timescale.
p s
t t
h
 /
12 Principles behind the Agile Manifesto
o m
s . c
Business people and developers smust work
4.
r e
together daily throughout the project.
p
d individuals.
5.Build projects around motivated r
o and support they
Give them the environment
. w
need, and trust them to il tget the job done.
The most efficient t e and effective method of
a
6.

j p
conveying information to and within a
development
/ a team is face-to-face conversation.
: /
p s
t t
h
 /
12 Principles behind the Agile Manifesto
o m
s . c
Working software is the primary smeasure of
7.
r e
progress.
p
d development.
r
Agile processes promote sustainable
The sponsors, developers, oand users should be
8.

. w
il t pace indefinitely.
able to maintain a constant
Continuous attention t e to technical excellence
a
9.

and good design

j p enhances agility.
/ a
: /
p s
t t
h
 /
12 Principles behind the Agile Manifesto
o m
s . c
Simplicity--the art of maximizing s
10.
r e the amount
of work not done--is essential.
p
d and designs
11.
r
The best architectures, requirements,
o teams.
emerge from self-organizing
. w
At regular intervals,litthe team reflects on how
e
12.

a t
to become more effective, then tunes and adjusts
j p
its behavior accordingly.
/ a
: /
p s
t t
h
Individuals and Interactions over /
Processes and Tools o m
s . c
 People make biggest impact on success
e s

p r
Process and environment help, but will not create success

r d
Strong individuals not enough without good team
interaction. o
. w
it
Individuals may be stronger based on their ability to
l

work on a team
t e


p a
Tools can help, but bigger and better tools can
j
hinder more than help
Simpler toolsacan be better


: / /
p s
t t
h
Working Software over /
Comprehensive Documentation o m
. c
Documentation important, but too muchsissworse than
e

too little
p r
Keep documents short and salientrd
 Long time to produce, keep in sync with code

Focus effort on producing w o not descriptions of it


i t . code,


e l
Code should document itself
 Knowledge of code kept
a t within the team

p
Produce no document unless its need is immediate and
j

significant.
/ a
: /
p s
t t
h
Customer Collaboration over /
Contract Negotiation o m
s . c
Not reasonable to specify what’s needed s
e delivered
and then
r


p
have no more contact until final product
d
 Get regular customer feedback
o r

t . w
Use contracts to specify customer interaction rather
li and cost
than requirements, schedule,
e
a t
j p
/a
s:/
t tp
h
Responding to Change over /
Following a Plan o m
s . c
e s
Environment, requirements, and estimates of work
r


p
required will change over course of large project.
d

o r
Planning out a whole project doesn’t hold up

. w
Changes in shape, not just in time
Keep planning realisticlit
e of weeks


Know tasks for next tcouple

a



j p
Rough idea of requirements to work on next few months
Vague senseaof what needs to be done over year


: / /
p s
t t
h
Extreme Programming (XP) /
o m
s . c
e s
One of the most well-known agile methods
r


 Developed in 1990s p d
 Kent Beck, 1996
o r
. w
 Chrysler Comprehensive Compensation Project

lit
e
 Published book in 1999
t
pa
a j
:/ /
p s
t t
h
Extreme Programming Practicesm /
c o
s .
1. On-Site Customer
e s


p r
Customer is actively involved with development process
 Customer gives “User Stories”
r d
o
 Short, informal “stories” describing features

w
Keep on “story cards”
.


2. Planning Game
l i t


t e to “stories” and a budget of how much

Developers and customers together plan project

they can accomplish a

 Developers give cost estimates

j p


/ a
Can use abstract accounting mechanism

Customer:/
 Later compare to actual cost, to improve estimates over time

s
 prioritizes stories to fit within budget

t t p
h
Extreme Programming Practicesm /
c o
s .
3. Metaphor
e s


p r
Come up with metaphor that describes how the whole project will fit

d
together
 The picture in a jigsaw puzzle
r
o in team
Tools and materials often provide.w
 Provides framework for discussing project


l i t good metaphors
4. Small Releases
t e reduced


p a
Time between releases drastically

Multiple iterationsj
 A few weeks/months


/ a

: /
Can have intermediate iterations between bigger “releases”

p s
t t
h
Extreme Programming Practicesm /
c o
s .
5. Testing
e s
 Test-first programming
p r
Unit testing frequently by developers
r d
o



. w
Acceptance tests defined by customers
6. Simple Design il t
Principles discussed int eearlier lectures
Design should be a



j p quick, not elaborate

/ a
Pick the simplest thing that could possibly work
: / stuff not ready yet
s
 Resist adding

t t p
h
Extreme Programming Practicesm /
c o
s .
7. Refactoring
Code gets worse with feature adds, bugre
s
fixes
p


Rerun all unit tests to know nothingrd

 Rewrite small sections of code regularly

o broken


t . w
Means you should have designed comprehensive tests
8. Pair Programming
l i
 Discussed later
t e
9. Collective Ownership a
panything
 Anyone can edit j
a fault of the whole team
Errors are/the
: /


p s
t t
h
Extreme Programming Practicesm /
c o
s .
10. Continuous Integration
Commit changes frequently (several times a day) e
s


p r
d
 Verify against entire test suite!
11. Coding Standards
o r
w
Enables effective teamwork
.


il t
12. Sustainable Pace

e
No overtime
t


Good estimation skillsa

 Only exceptions in final week

p wasted in pairs, bullpen rooms

for budgeting will help ensure reasonable times
Time less likely tojbe


Plan time eacha




: / / day for administrative work (<1 hour), breaks

p s
t t
h
SCRUM /
o m
s . c
e s
Idea first appeared in a business journal in 1986
r


p
(applied to product development management).
Used in software developmentrd and presented in
o


1995 paper.
. w
Term is based on rugby il tterm
e

t
a teams
Small cross-functional
p


a j
:/ /
p s
t t
h
SCRUM Practices /
o m
s . c
Product and release backlog
e s
r


A
p
list of the features to be implemented in the project
d
r
(subdivided to next release), ordered by priority
o
w
 Can adjust over time as needed, based on feedback
.
lit
 A product manager is responsible for maintaining

te
p a
a j
:/ /
p s
t t
h
SCRUM Practices /
o m
s . c
 Burn-down chart
e s
 Make
p r
best estimate of time to complete what is
currently in the backlog
r d
 Plot the time on a chart o
. w
it
 By studying chart, understand how team functions

e l
 Ensure burndown to 0 at completion date
 By
a t
adjusting what’s in the backlog
j p
 By adjusting the completion date

/a
s :/
t tp
h
SCRUM Practices /
o m
s . c
 The sprint
e s


p r
The sprint is a ~1 month period after which some product is delivered

d
 Features are assigned from the product backlog to a sprint backlog

 Feature list is fixed for sprint
o r
Features divided into smaller tasks for sprint backlog

Planning meeting
. w
it


l
 Tasks can be assigned to team members


t efeatures, and keep a burn-down chart for

Team members have individual estimates of time taken per item

a
 During sprint, work through

pproduced by the end of the sprint

the sprint
New functionalityjis
After sprint, aa



: / / review meeting is held to evaluate the sprint

p s
t t
h
SCRUM Practices /
o m
s . c
Scrum meeting
e s
r


 15 minute daily meeting

d p
 All team members show up
o r
w
 Quickly mention what they did since last Scrum, any
.
lit
obstacles encountered, and what they will do next

te
 Some team member volunteers or is appointed to be the

a
Scrum Master - in charge of Scrum meeting, and responsible
p
j
for seeing that issues raised get addressed
a
:/ /
 Customers, management encouraged to observe

p s
t t
h
 SCRUM Practices /
o m
s . c
e s
p r 24 hours

r d
o Scrum
Sprint
. w
it
Sprint Meeting
Release Backlog
e l
Plan
Backlog Begin
a t 30 days End
j p
Sprint
Sprint
/a
s :/
t tp Product Sprint
Retrospective
New
Functionality
h
Backlog
SCRUM Practices /
o m
s . c
e s
p r
r d
o
. w
lit
te
pa
a j
:/ /
p s
t t
h
AGILE DEVELOPMENT /
o m
s . c
e s
p r
r d
o
. w
lit
te
pa
a j
:/ /
p s
t t
h
Drawbacks and Challenges of Agile /
Methods o m
s . c
 Undefined goals
e s
 Featurecreep
p r
 Neverending project with overruns
r d
Need clear, single, invested o

. w customer
All-or-nothing adoptionitof techniques

l
e if lots of other aspects used
 Some parts work only
a t
 Team size limited
j p (smaller teams)
/ a
: /
p s
t t
h
Planning /
o m
s . c
 Initial Exploration
e s
 Spiking, Splitting, and Velocity
p r
Release Planning r d
o


 Iteration Planning
. w
Task Planning lit
e


 The Halfway Point

a t
 Iterating
j p
/a
s:/
t tp
h
Planning /
o m
s . c
Initial Exploration
e s
r


 At
p
the start of the project, the developers and
d
r
customers try to identify all the really significant user
o
w
stories they can. However, they don’t try to identify all
user stories.
it .
e l
a t
 As the project proceeds, the customers will continue to
write new user stories.
j p
a
 The flow of user stories will not shut off until the project
/
:/
is over.

p s
 The developers work together to estimate the stories.

t t
The estimates are relative, not absolute.
h
Planning /
o m
s . c
 Spiking, Splitting, and Velocity
e s
 Splitting
p r

r d
For example, “Users can securely transfer money into, out of,
o
and between their accounts.” - big story. Estimating will be
. w
it
hard and probably inaccurate. Further Splitting above
story in
e l
 Users can log in.
a t
p
 Users can log out.

a j
 Users can deposit money into their account.

:/ /
 Users can withdraw money from their account.

s
 Users can transfer money from their account to another account.

t t p
h
Planning /
o m
s . c
 Velocity
e s

p r
If we have an accurate velocity, we can multiply the
d
estimate of any story by the velocity to get the actual time
r
o
 For example, our velocity is “2 days per story point,” and

. w
we have a story with a relative estimate of four points, then
lit
the story should take eight days to implement.

t e
 As the project proceeds, the measure of velocity will become
ever more accurate
pa
a j
 Velocity
:/ /

p s
Often, it is sufficient to spend a few days prototyping a

t t
story or two to get an idea of the team’s velocity. Such a
h prototype session is called a spike.
Planning /
o m
s . c
Release Planning
e s
r


 The
p
developers and customers agree on a date for the
d
r
first release of the project. This is usually a matter of
o
w
2–4 months in the future. The customers pick the stories
it .
they want implemented within that release and the
e l
t
rough order in which they want them implemented.
a
 The release plan can be adjusted as velocity becomes
p
a j
more accurate.

:/ /
p s
t t
h
Planning /
o m
s . c
Iteration Planning
e s
r


 typically two weeks long

d p
r
 the customers choose the stories that they want
o
w
implemented in the first iteration.
.
lit
 The order of the stories within the iteration is a technical

t e
decision that makes the most technical sense.

pa
j
 The customers cannot change the stories in the iteration

a
once the iteration has begun - Reordering is possible
/
:/
 The iteration ends on the specified date, even if all the
s
t tp
stories aren’t done.

h
Planning /
o m
s . c
 If
e s
the team got 31 story points done last iteration, then

p r
they should plan to get 31 story points done in the next.

r d
Their velocity is 31 points per iteration.
o
 If the team gains in expertise and skill, the velocity will
. w
it
rise commensurately. If someone is lost from the team,
e l
the velocity will fall. If an architecture evolves that
a t
facilitates development, the velocity will rise.
j p
/a
s:/
t t p
h
Planning /
o m
s . c
Task Planning
e s
r


 The
p
developers break the stories down into
d
r
development tasks. A task is something that one
o
w
developer can implement in 4–16 hours. The stories are
it .
analyzed, with the customers’ help, and the tasks are
e l
t
enumerated as completely as possible.
a
 A list of the tasks is created on a flip chart, whiteboard,
p
a j
or some other convenient medium. Then, one by one, the

:/ /
developers sign up for the tasks they want to
s
implement.
p
t t
h
Planning /
o m
s . c
 Developers,
e s
Database Guys, GUI guys (whole Project

p r
team) may sign up for respective kind of task.

r d
 Task selection continues until either all tasks are
assigned o
. w
lit
te
pa
a j
:/ /
p s
t t
h
Planning /
o m
s . c
The Halfway Point
e s
r


 Halfway
p
through the iteration, the team holds a
d
meeting.
o r
w
 At this point, half of the stories scheduled for the
.
lit
iteration should be complete. If aren’t complete, then
te
the team tries to reapportion tasks and responsibilities
a
to ensure that all the stories will be complete by the
p
a j
end of the iteration

:/ /
p s
t t
h
Planning /
o m
s . c
 For Example,
e s
 Suppose
p r
the customers selected 8 Stories

r d
 8 Stories Totally 24 story points  42 Tasks

o
 Halfway point 12 story points  21 Tasks should be

. w
it
completed
 At
e l
the halfway point, we want to see completed stories
a t
that represent half the story points for the iteration
j p
/a
s:/
t t p
h
Planning /
o m
s . c
Iterating
e s
r


 Every
p
two weeks, the current iteration ends and the next
d
begins.
o r
w
 At the end of each iteration, the running executable is
.
lit
demonstrated to the customers.
te
 The customers are asked to evaluate the look, feel, and

pa
performance of the project.
a j
 The customers can measure velocity. They can predict

:/ /
how fast the team is going, and they can schedule high-

p s
priority stories early.
t t
h
Test Driven Development /
o m
s . c
 What if we designed our tests before we
e s designed our
programs?
p r
d
 What if we refused to implement a function in our
programs until there was a test that
function wasn’t present? o r failed because that

What if we refused to add.w


our programs unless there l i t even a single line of code to
were a test that was failing
because of its absence?e
a t
p writing failing tests that asserted the
What if we incrementally added functionality to our
j

programs by first
/ a
existence of that functionality, and then made the test pass?
: /
s
 What effect would this have on the design of the software

t t p
we were
existence
writing? What benefits would we derive from the
of such a comprehensive bevy of tests?
h
Test Driven Development /
o m
s . c

e s
We can add functions to the program, or change the structure
r
of the program, without fear that we will break something
p
important in the process.
r d

o
we are immediately concerned with the interface of the
. w
it
program as well as its function. By writing the test first, we
l
design the software to be conveniently callable.
e

a t
we are immediately concerned with the interface of the

j p
program as well as its function. By writing the test first, we
a
design the software to be conveniently callable.
/


s :/
The act of writing tests first forces us to decouple the software!

t tp
h
Test Driven Development /
o m
s . c
An Example of Test-First Design
e s
r


I
p
trusted that I could make the test pass by writing the
d
r
code that conformed to the structure implied by the test.
o
w
This is called intentional programming.
it .
l
 The point is that the test illuminated a central design

e
a t
issue at a very early stage. The act of writing tests first
is an act of discerning between design decisions.
j p
a
 The test acts as a compile able and executable
/
:/
document that describes the program

p s
t t
h
Test Isolation /
o m
s . c
s
e that ought to
The act of writing tests before production code
r


often exposes areas in the software

d p
be decoupled. r
o UML diagram of a
For example, Lets see a w


payroll application. li t . simple

t e
pa
a j
:/ /
p s
t t
h
Test Isolation /
o m
s . c
s
e written any
This diagram is just sitting on a whiteboard after a
r


p
quick design session and that we haven’t
d
of this code yet.
o r

w
There are a number of problem
t .
 First, what database do
l i we use? Payroll needs to read
e
from some kind of tdatabase. What data do we load
p a
j
into it?
 Second, how
/ a do we verify that the appropriate check
: / We can’t write an automated test that
got printed?
looksson the printer for a check and verifies the amount
t t p
h
on it’s associated with writing these tests.
Test Isolation /
o m
s . c
e s
 It creates the appropriate
mock objects, passes them p r
to the Payroll object, tells r d
o
w
the Payroll object to pay
all the employees, and
it .
e
then asks the mock objects l
a
to verify that all the t
checks were
j pwritten

/ a
correctly and that all the

:/
payments were posted
s
p
correctly.
t t
h
Acceptance Test /
o m
s . c
e s
Unit tests are necessary but insufficient as verification
r


tools.
dp

o r
Unit tests verify that the small elements of the system
w
work as they are expected to, but they do not verify
.
lit
that the system works properly as a whole.
te
Unit tests are white-box tests that verify the individual
a


j p
mechanisms of the system.
/a
Acceptance tests are black-box tests that verify that
:/


s
the customer requirements are being met.
p
t t
h
Acceptance Test /
o m
s . c
e s
Acceptance tests are written by folks who do not
r


p
know the internal mechanisms of the system.
d

o r
They may be written directly by the customer or by
w
some technical people attached to the customer,
.
lit
possibly QA. Acceptance tests are programs and are
te
therefore executable.
pa


a j
Acceptance tests are the ultimate documentation of a
feature.
:/ /


p s
Creating an acceptance testing framework may seem
t
a daunting task.
t
h
Acceptance Test /
o m
s . c
Example of Acceptance Testing
e s
r


 Consider, the payroll application

d p
r
 we must be able to add and delete employees to and from
o
w
the database. We must also be able to create paychecks

it .
for the employees currently in the database. Fortunately, we

e l
only have to deal with salaried employees. The other kinds

a t
of employees have been held back until a later iteration.

j p
 it makes sense that the acceptance tests should be written in

/a
simple text files.

s :/
AddEmp 1429 “Robert Martin” 3215.88

p
Payday

t t Verify Paycheck EmpId 1429 GrossPay 3215.88

h
Acceptance Test /
o m
s . c
We need to find some common form
e s for those
transactions so that the amount of rspecialized


d p code
is kept to a minimum. r
o the transactions into
One solution would be towfeed

t .
the payroll applicationli in XML
t e
a
<AddEmp PayType=Salaried>

p
<Name>Robertj Martin</Name>
<EmpId>1429</EmpId>

/ a
: /
<Salary>3215.88</Salary>

p s
</AddEmp>

t t
h
Acceptance Test /
o m
s . c
s
re
 We can have the payroll application produce its
paychecks in XML
d p
<Paycheck>
<EmpId>1429</EmpId> o r
. w
it
<Name>Robert Martin</Name>

e l
<GrossPay>3215.88</GrossPay>
</Paycheck>
a t
j p
/a
s:/
t tp
h
 Refactoring – What is it? /
o m
s . c
s
e code without
r
Process of changing a computer program’s source
p
d
modifying its external functional behavior
r
oattributes:
. w
To improve some of the nonfunctional
il t
e
code readability

a t
reduced complexity to improve maintainability better design
 extensibility jp
/ a
: /
p s
t t
h
Ricardo Terra (rterrabh [at] gmail.com)
 Refactoring – What is it? /
o m
s . c
e s
p r
“By continuously improving the design of code, we make it easier

r d
and easier to work with. This is in sharp contrast to what typically
o
happens: little refactoring and a great deal of attention paid to
. w
it
expediently adding new features. If you get into the hygienic habit of

e l
refactoring continuously, you’ll find that it is easier to extend and
maintain code.”
a t
j p
a
— Joshua Kerievsky [Refactoring to Patterns]

:/ /
p s
t t
h
 Refactoring – What is it? /
o m
s . c
e s
p r
“By continuously improving the design of code, we make it easier

r d
and easier to work with. This is in sharp contrast to what typically
o
happens: little refactoring and a great deal of attention paid to
. w
it
expediently adding new features. If you get into the hygienic habit of

e l
refactoring continuously, you’ll find that it is easier to extend and
maintain code.”
a t
j p
a
— Joshua Kerievsky [Refactoring to Patterns]

:/ /
p s
t t
h
 Refactoring – What is it? /
o m
s . c
e s
p r
“By continuously improving the design of code, we make it easier

r d
and easier to work with. This is in sharp contrast to what typically
o
happens: little refactoring and a great deal of attention paid to
. w
it
expediently adding new features. If you get into the hygienic habit of

e l
refactoring continuously, you’ll find that it is easier to extend and
maintain code.”
a t
j p
a
— Joshua Kerievsky [Refactoring to Patterns]

:/ /
p s
t t
h
Refactoring – When do I use? m /
c o
s .
Bad smells! s
e even scream
r


 A structure in the code suggests, and sometimes

d p
for, opportunities for refactoring
o r
w
This humorous advice rely on the experience of programmers
.


and on the clarity of code

il t
Indications to possible t ebad smells:
Duplicated code  a



j p share one same method

Long method 
/ a
/ divide in more cohesive classes
 extract one or more smaller methods

s :
Large class
Longtp


h t parameter list  encapsulate them

Refactoring /
o m
s . c
There is a almost a hundred catalogued refactorings
e s
r

 each one has a name, a motivation, and a mechanics

d p

o r
They are usually organized into the following groups:


.
Composing Methods (e.g., Extract Method)
w

l it
Moving Features Between Objects (e.g., Move Method)

t e
Organizing Data (e.g., Encapsulate Field)


p a
Simplifying Conditional Expressions (e.g., Consolidate Conditional Expression)


a j
Making Method Calls Simpler (e.g., Rename Method)


: /
Dealing with Generalization
/
(e.g., Pull Up Method)

s
Big Refactoring (e.g., Extract Hierarchy)

t t p
h
Refactoring - Extract Method /
o m
s . c
s
ebe grouped
You have a code fragment that can r
together p
r d
o
t . w
l i
Turn the fragment into
t e a method whose name
explains the
p a purpose of the method
a j
: / /
p s
t t
h
 Extract Method –Theoretical Example /
o m
s . c
void printOwing ( double amount){
e s
printBanner( );
// print details
p r
System.out.println("name: " + this.name);
r d
o
System.out.println("amount:" + amount);

w
}

il t .
t e
p a
void printOwing (double amount) {
printBanner( ) ;

a j
/
PrintDetails(amount) ;

: /
}

p s
void PrintDetails(double amount) {

t t
System.out.println("name: " + this.name) ;

h
System.out.println("amount: " + amount);
}
Extract Method - Motivation /
o m
s . c
It is one of the most common refactorings
e s
r



d p
Long methods or look at code that needs a comment
to understand its purpose
o r
. w
So, I turn that fragment of code into its own method.
it


Reasons to do that:
e l
t



pa
Increases the chances that other methods can use a method when the

j
method is fine-grained
a
/
 Allows the higher-level methods to read more like a series of comments

: /
Overriding also is easier
s


t t p
h
Refactoring – Pull Up Method /
o m
s . c
e s
p r
You have methods with identical d
o rresults on subclasses

. w
lit⇓
et
Move them
p a to the superclass
a j
:/ /
p s
t t
h
Pull Up Method – Theoretical Example /
o m
s . c
e s
p r
r d
o
⇒. w
il t
t e
p a
a j
: / /
p s
t t
h
Pull Up Method – Motivation /
o m
s . c
 Eliminating duplicate behavior is important
e s

p r
if not, the risk that a change to one not be made to other

r
The easiest case: methods have the same body d
of course it is not always obvious asothat. So, look for the differences
w


.
Special case: you haveliatsubclass method that overrides a
and test for safety

edoes the same thing



superclass method yet

a t

j
The most awkward case:
p the method may refer to features that

/ a
are on the subclass
possible /
but not on the superclass


s : solutions: generalize methods, create abstract method on

p
superclass, change a method’s signature...

t t
h
Refactoring – Move Method /
o m
s . c
e s
p r
A method is, or will be, using or used by more features of
r d
another class than the class on which it is defined
o
. w
(Feature Envy)

l it
te
a
p
a j
Create a new method with similar body in the class

: /
it uses most. Either turn the old method into a
/simple delegation, or remove it
s
p
t t
h
Move Method – Theoretical Examplem /
c o
s .
e s
p r
r d
o
. w
il t
t e⇒
p a
a j
: / /
p s
t t
h
Move Method – Motivation /
o m
s . c
Moving methods is the bread and butter of
e s
r


refactoring
d p
 classes with too much behavior
o r
w
 classes are collaborating too much (too highly coupled)

it .
By moving methods taround: e l
a



j
make classes simpler
p
 high cohesion
/ a (classes end up being a more crisp implementation of a

: /
set of responsibilities)

p s
t t
h
Refactoring – Extract Superclass /
o m
s . c
e s
p r
r d
You have two classes with similar features
o
. w
l it
t e
Create a superclass and move the common features
athe superclass
to
p
a j
:/ /
p s
t t
h
Extract Superclass – Theoretical Example /
o m
s . c
e s
p r
r d
o
. w
il t⇓

t e
p a
a j
: / /
p s
t t
h
Extract Superclass– Motivation /
o m
s . c
e s
Duplicate code is one of the principal bad things in
r


systems
dp
 Duplicate code:
o r

. w
two classes that do similar things in the same way or two
it
l
classes that do similar things in different ways
A well-known solution: t einheritance (everything)
a do not notice the commonalities until


However, you p


a j often

/
you have created some classes
/ you need to create the inheritance structure
In this :case,
later s


t t p
h
 /
o m
s . c
e s
p r
r d
o
. w
lit
te
pa
a j
:/ /
p s
t t
h
 /
o m
s . c
e s
p r
r d
o
. w
lit
te
pa
a j
:/ /
p s
t t
h