MOD251 Modern Software Development Methods

1
MOD251 Modern Software Development Methods

• Agile Design Smells, SRP

2
Content / Agenda

• Introducing Agile Design
• Symptoms of Poor Design (Design Smells)
• Rigidity
• Fragility
• Immobility
• Viscosity
• Needless complexity
• Needless repetition
• Opacity
• SRP The Single-Responsibility Principle

3
What is Agile Design?

• Often, design is thought of as the result of
  modeling, for example using OOD and creating UML
  models.
• In agile thinking, the code represents the
  design. If we use UML diagrams, that is only to
  capture, visualize and communicate aspects of the
  design. The code is the design!
• If we want the design to afford change, we must
  write and organize our code so this can be done.
• Agile design is the process of continuously
  applying principles, patterns and practices to
  improve the structure and readability of the
  code.
• Martin talks about this as avoiding and removing
  design smells, symptoms of rotting software.

4
Smells - Rigidity

• The system is hard to change because every change
  forces many other changes to other parts of the
  system.
• Root causes are bad modularization and high
  coupling
• Simple changes will take much longer time to
  fix than estimated
• A consequence is that managers fear to allow
  developers fix non-critical problems
• In the long term, dont fix it becomes the
  official policy

5
Smells - Fragility

• Changes cause the system to break in places that
  have no conceptual relationship to the part that
  was changed.
• Is closely related to rigidity (same root causes)
• Again, managers (and now also developers) will
  fear change
• Fragility tends to get worse, and the software
  gets impossible to maintain
• In the long term, all credibility is lost

6
Smells - Immobility

• It is hard to disentangle the system into
  components that can be reused in other systems.
• May happen because modules are not designed for
  reuse, e.g. when modules depends on
  infrastructure (EJB) or when modules are too
  specialized
• Is also related to low cohesion
• The consequence is that software is rewritten
  instead of reused.

7
Smells - Viscosity

• Doing things right is harder than doing things
  wrong.
• Two forms Viscosity of the design or viscosity
  of the environment.
• If making changes that preserves the design is
  harder to do then doing hacks, the viscosity of
  the design is high.
• If the development environment is slow and
  inefficient, developers are tempted to do easy
  fixes rather than doing design preserving
  changes. Lack of refactoring support is a good
  example.

8
Smells Needless Complexity

• The design contains infrastructure that adds no
  direct benefit.
• This frequently happen when developers anticipate
  changes to the requirements, and put in
  facilities for those potential changes.
• Preparing for future changes could be a good
  thing, but the effect is often the opposite of
  what you want. Some preparations may pay off, but
  most dont.
• The design will carry the weight of all the
  unused design elements, and possibly make other
  changes difficult.

9
Smells Needless repetition

• The design contains repeating structures that
  could be unified under a single abstraction.
• A result of cut and paste
• All duplication is bad!
• Also be aware of semi-duplication, code that is
  almost the same. Is even worse to fix.
• Makes the software difficult to maintain

10
Smells - Opacity

• It is hard to read and understand. It does not
  express its intent well.
• Not following a coding standard
• Bad or inconsistent naming
• Bad or lacking commenting
• Modules too big
• Some kind of code review should be done to avoid
  opaque code.

11
Design Principles

• Agile design is the process of continuously
  applying principles, patterns and practices to
  improve the structure and readability of the
  code.
• Now, it is time to take a closer look at the
  principles
• SRP - Single Responsibility Principle
• OCP - Open-Closed Principle
• LSP - Liskov Substitution Principle
• DIP - Dependency-Inversion Principle
• ISP - Interface-Segregation Principle
• , starting with SRP ...

12
SRP - Single Responsibility Principle

• Also called cohesion
• The cohesion is low if the module does several
  things
• Cohesion should be high
• Only one single responsibility per class
• We will relate responsibility to reasons to
  change
• A class should have only one reason to change

13
SRP Ex. Rectangle (1)

• Rectangle Class with two responsibilities
• Geometrical calculations
• Drawing an object

Uses only draw()
Uses only area()
14
SRP Ex. Rectangle - problems

• Consequences
• Rectangle must always have access to the Graphics
  Library, but the Geometric Application does not
  need it.
• Changes in the Graphics Library cause unnecessary
  linking or loading in the Geometric Application.
• Changes in Rectangle, e.g. in some calculation,
  requires recompiling the Graphics Application.
• Conclusion Changes caused by one responsibility
  has impact on code related to another
  responsibility.

15
SRP Ex. Rectangle - better design

• Separate the responsibility into 2 classes
• Geometric Rectangle Geometrical calculations
• Rectangle2 Drawing an object

16
SRP - Summary

• Principle A class should only have one
  responsibility
• Responsibility a reason to change
• But Dont separate responsibilities if it is
  unlikely that there will be independent changes.
  We dont want our code to smell of Needless
  Complexity.

17
Next

• OCP Open Closed Principle
• LSP Liskov Substitution Principle