Professional Documents
Culture Documents
Agile Unit 2
Agile Unit 2
o m
. c
AND UI/UX DESIGN e s s
SUBJECT CODE: 3171610 p r
r d
o
UNIT-2 . w
il t
t e
AGILE DESIGN p a
a j
: / /
p s
t t
h PREPARED BY: AMITKUMAR J PATEL
What Is Agile Design? /
o m
s . c
e s
If agility is about building software in tiny increments,
how can you ever design the software?
p r
r d
How can you take the time to ensure that the software
o
has a good structure that is flexible, maintainable,
. w
it
and reusable?
e l
If you build in tiny increments, aren’t you really setting
t
a
the stage for lots of scrap and rework in the name of
p
refactoring?
a j
/
Aren’t you going to miss the big picture?
The big:/picture evolves along with the software. With each
p s
tittis as good as it can be for the system as it is now.
iteration, the team improves the design of the system so that
h
What Goes Wrong with Software? /
o m
s . c
You start a project with a clear picture
e s of what you
want the system to be.
p r
r
The design of the system is a vital d image in your mind.
Then, something goes wrong. o The software starts to
. w
t e
Ugly festering soresa and boils accumulate in the code,
pand harder to maintain.
making it harder j
a required to make even the simplest
The sheer /
: / becomes so onerous that the developers
effort
s
of changes
andtp
t
front-line managers cry for a redesign.
h redesigns rarely succeed
Such
Symptoms of Poor Design /
o m
s . c
Rigidity: The design is hard to change.s
r e
Fragility: The design is easy to break p
Immobility: The design is hardrd
o to reuse.
Viscosity: It is hard to do.w
l i t the right thing.
Needless Complexity:
t e Overdesign.
p
Needless Repetition:a Mouse abuse.
j
/a
Opacity: Disorganized expression.
s :/
t tp
h
Design Smells -The Odors of Rotting Software /
o m
s . c
e
Rigidity: The system is hard to change because every s change forces
many other changes to other parts of the system.
p r
d changed.
Fragility: Changes cause the system to break
conceptual relationship to the part thatrwas
in places that have no
o
. w
Immobility: It is hard to disentangle the system into components that
can be reused in other systems.t
l i
t
Viscosity: Doing things righte is harder than doing things wrong.
Needless Complexity:aThe design contains infrastructure that adds
no direct benefit. jp
/ a
: / under a single abstraction.
Needless Repetition: The design contains repeating structures that
s
could be unified
p
t t
Opacity: It is hard to read and understand. It does not express its
h
intent well
Principles /
o m
s . c
Object-oriented design that help developers
e s
r
p
eliminate design smells and build the best designs
d
for the current set of features.
o r
The principles are as follows:
. w
il t Principle
1. SRP: The Single Responsibility
2. OCP: The Open-Closed t e Principle.
p a
a j
3. LSP: The Liskov Substitution Principle.
/
4. DIP: The Dependency Inversion Principle.
5. ISP: The:/Interface Segregation Principle.
p s
t t
h
SRP: The Single Responsibility Principle /
o m
s . c
Each class should only be responsible for s
e is an axis of
a single
p r
cohesive responsibility. Each responsibility
change. When the demand changes,
be reflected as the change in o r d the change will
the responsibility of the
class. A class should have.w
change. If a class liassumest only one reason for its
a j
/
responsibilities together. Designs that violate SRP can
usually be/reconstructed
: using facade mode or agent
mode tosseparate business responsibilities.
t t p
h
SRP: The Single Responsibility Principle /
o m
s . c
e s
p r
r d
o
. w
il t
More than one responsibility
p s
t t
computational geometry, but it definitely draws the rectangle on the
hscreen
SRP: The Single Responsibility Principle /
o m
s . c
e s
p r
r d
o
. w
il t
t e
a
A better design is to separate the two responsibilities into two
p classes as shown above.
j
completely different
a
: / /
This design moves the computational portions of Rectangle into
Now p
s
the GeometricRectangle class.
t t changes made to the way rectangles are rendered
h
cannot affect the ComputationalGeometryApplication.
SRP: The Single Responsibility Principle /
o m
s . c
Responsibility:
e s
r
p
We define a responsibility to be “a reason for change.”
d
If you can think of more than one
r motive for changing a
class, then that class has moreothan one responsibility.
t . w
l i
interface Modem {
t e
public void dial(Stringapno);
j
public void hangup(); p
/ a
public void send(char c);
/
public char:recv();
p s
}
t t
h
OCP: The Open–Closed Principle m /
o c
s .
e s
Software entities (classes, packages, modules, etc.)
p r
should be extensible, but unmodifiable, that is, they are
r d
open for expansion and closed for modification. When
o
expanding the behavior of an entity, there is no need
. w
it
to change the source code or binary code, that is The
e l
Open-Closed Principle. The key to the principle of
a t
opening and closing is abstract design. It is impossible
j p
for complete OCP. The most likely and most frequent
/ a
changes should be abstracted. Following the principle
:/
of opening and closing, rejecting immature abstraction
s
t tp
is as important as abstraction itself.
h
OCP: The Open–Closed Principle m /
o c
s .
A module will be said to be opens if it is still
r e it should be
available for extension. For example,
d p
possible to add fields to the r data structures it
o the set of functions it
contains, or new elements to
. w
performs. il t
A module will be said t e to be closed if it is available
a
e s
public class Square { }
p r
public static class Drawer {
r d
o
public static void DrawShapes(IEnumerable<object> shapes) {
. w
foreach (object shape in shapes) {
it
if (shape is Circle) {
l
DrawCircle(shape as Circle);
e
t
} else if (shape is Square) {
a
DrawSquare(shape as Square);
p
}
}
a j
/
}
:/
private static void DrawCircle(Circle circle) { /*Draw
s
circle*/ }
tp
private static void DrawSquare(Square square) { /*Draw
t
Square*/ }
}
h
OCP: The Open–Closed Principle m /
o c
s .
public interface IShape { void Draw(); }
e s
p r
public class Circle : IShape { public void Draw() { /*Draw
d
circle*/ }}
o r
public class Square : IShape { public void Draw() { /*Draw
. w
Square*/ } }
a
foreach (IShape shape in shapes) {
p
shape.Draw();
}
a j
/
}
:/
}
p s
t t
h
OCP: The Open–Closed Principle m /
o c
s .
e s
But the real challenge is anticipation, anticipating is
r
p
hard In real world, when you anticipate the risk is
d
high that:
r
We do anticipate variationso that won’t vary.: Always
implement things when you.w
t
you just foresee that liyou need them. Developing and
actually need them, never when
t e
a
maintaining an abstraction has a cost and if we won’t need
p
j
it this cost is negative.
a
/ be needed. But once the need for variation
The risk is also
that will:/really
high that we don’t anticipate the variation
p
becomess real this is your developer responsibility to refactor
t
t create the right abstractions and the right stable code
and
h that will act upon these abstractions
LSP: The Liskov Substitution Principlem /
c o
s .
Subtypes must be able to completely replace s
e principle
their
base types. The types satisfying the rLiskov
satisfy the following properties: ifdp
r of type S, so that in
there is an object
O2 of type T for every object o O1
. w
il tthe program Change, then S
all programs written for T, after replacing O2 with O1,
t t
designs
p
reflected through its client program. Some inheritance
that violate the LSP can use the method of
h
extracting common parts instead of inheritance.
LSP: The Liskov Substitution Principlem /
c o
s .
There are other, far more subtle, wayssof violating
r e uses the
the LSP. Consider an application which
d p
Rectangle class
o r
class Rectangle
t . w
{
l i
t e h) {itsHeight=w;}
public: void SetWidth(double w) {itsWidth=w;}
a
void SetHeight(double
j
double GetHeight()
p const {return itsWidth;}
const {return itsHeight;}
a
double GetWidth()
private:
: / /
s
Point itsTopLeft;
p
double itsWidth;
}; t
t
double itsHeight;
h
LSP: The Liskov Substitution Principlem /
c o
s .
Imagine that this application workss well and is
r e case with all
installed in many sites. As is the
d p
r
successful software, its users demand changes
o demand the ability
from
. w
time to time. One day, the users
to manipulate squares iint addition to rectangles.
l
It is often said tethat inheritance is the IS-A
a words, if a new kind of object
relationship. In p
j other
can be saidato fulfill the IS-A relationship with an
/
old kind:/of object, then the class of the new object
p s
t t
should be derived from the class of the old object.
h
LSP: The Liskov Substitution Principlem /
c o
s .
For all normal intents and purposes, sa square is a
t . w
This use of the IS-A relationship
i
h
class.
ISP: Interface Segregation Principlem /
c o
s .
Customers should not be forced to srely on the
r e
methods they do not use.
p
d and harmful
Fat interfaces can cause abnormal r
o programs. When a
coupling between their client
. w
client program requires il t a change to the fat
e other client programs.
interface, it will taffect
p a
Therefore, client
a j programs should only depend on
/
what they actually call The method can achieve this
goal by:/separating the fat interface into multiple
p s
t t
specific client program interfaces.
h
ISP: Interface Segregation Principlem /
c o
s .
Each client-specific interface only sdeclares the
r e to call, and
methods that its client program needs
d p
the implementation class implements
o r all client-
specific interfaces, releasing
relationships so that ithe t . w these coupling
j
virtual bool
p IsDoorOpen() = 0;
a
};
:
This class /
/ abstract so that clients can use objects
is
s to the Door interface, without having to
that p
conform
t t on particular implementations of Door.
h
depend
ISP: Interface Segregation Principlem /
c o
s .
Let’s consider TimedDoor, needs to sound s
e too long. In
an alarm
r
t . w
class Timer {
l i
public:
t e timeout, TimerClient* client);
a
void Register(int
};
j p
/ a
/
class TimerClient {
s :
public:
}; p
virtual void TimeOut() = 0;
t t
h
ISP: Interface Segregation Principlem /
c o
s .
When an object wishes to be informed s
e of the Timer.
about a
r
p
time-out, it calls the Register function
d
The arguments of this function r are the time of
o a TimerClient object
the
time-out, and a pointer to
. w
whose TimeOut function il t will be called when the
time-out expires. te
We force Door,panda therefore TimedDoor, to inherit
a j
/
from TimerClient. This ensures that TimerClient can
register :/itself with the Timer and receive the
p s
t t
TimeOut message.
h
ISP: Interface Segregation Principlem /
c o
s .
Chief among these is e s
r
have :/to /
Door are created, those derivatives will
provide degenerate
p s
t t
implementations for the TimeOut
h
method-a potential violation of the LSP.
ISP: Interface Segregation Principlem /
c o
s .
Moreover, the applications thats use those
p
level modules, both should rely on abstraction;
Each higher level declares anrdabstract interface
o the lower level
e l
may look appropriate, it has
a t
the insidious characteristic that the Policy layer is sensitive to
j p
changes all the way down in the Utility layer.
/ a
Dependency is transitive.
:/
The Policy layer depends on something that depends on the
s
t tp
Utility layer; thus, the Policy layer transitively depends on the
Utility layer. This is very unfortunate.
h
DIP: The Dependency Inversion Principlem /
c o
s .
Each of the upper-level
e s
layers declares an abstract
interface for the services that
p r
it needs.
r d
The lower-level layers are o
w
then realized from these
it .
abstract interfaces
This is sometimes known ase
l
a t
p
the Hollywood principle:
j
“Don’t call us, we’ll call
The lower-levela modules
you.”
: /
/ that are
provide the implementation
s
for interfaces
p
t upper-level modules.
declared
by,tthe
within, and called
h
DIP: The Dependency Inversion Principlem /
c o
s .
e s
Abstraction should not depend on details, details should
depend on abstractions;
p r
r d
All the dependencies in the program should end in an
o
abstract class or interface, that is:
. w
it
No variable should hold a pointer or reference to a specific
class;
e l
a t
No class should be derived from a concrete class;
j p
No method should override the methods already implemented in
a
any of its base classes;
/
:/
If a concrete class is unlikely to change, and other similar
s
derived classes will not be created, then relying on it will
p
t t
not cause damage. For example: java.lang.String.
h
DIP: The Dependency Inversion Principlem /
c o
s .
Consider the case of the Buttonre
s
object and the
Lamp object
d p
Figure shows a naive design. r
o The Button object
w
i .
receives Poll messages, tdetermines if the button has
been pressed, and e l
then simply sends the TurnOn or
t
TurnOff messageato the Lamp.
j p
/ a
: /
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
/
o m
s . c
e s
p r
r d
o
. w
lit
te
pa
a j
:/ /
p s
t t
h