Some design smells

1. Design smells

2. Design smells taxonomy
✤ Bloaters
✤ Object-Orientation Abusers
✤ Change Preventers
✤ Dispensables
✤ Couplers

3. Bloaters

4. Bloaters
Bloaters are code, methods and classes
that have increased to such gargantuan
proportions that they are hard to work
with. Usually these smells do not crop up
right away, rather they accumulate over
time as the program evolves (and
especially when nobody makes an effort
to eradicate them).

5. Bloaters
✤ Long method
✤ Large class
✤ Long parameter list
✤ Primitive obsession
✤ Data clumps

6. Long Method (1/5)
Signs and Symptoms
Large number of lines

7. Long Method (1/5)
Reasons for the Problem
“Columbo syndrome”, was the detective who always
had “just one more thing”.
"But it's just two lines, there's no use in creating a whole
method just for that..."

8. Long Method (1/5)
Treatment
✤ Use Extract Method to break up the method into smaller pieces
✤ If local variables and parameters interfere with extracting a method,
use Replace Temp with Query, Introduce Parameter Object or
Preserve Whole Object.
✤ If none of the previous recipes help, try moving the entire method to a
separate object via Replace Method with Method Object.
✤ Conditional operators and loops are a good clue that code can be
moved to a separate method. For conditionals, use Decompose
Conditional. If loops are in the way, try Extract Method.

9. Long Method (1/5)
Payoff
✤Improves communication
✤May expose duplication
✤Often helps new classes and abstractions emerge

10. Long Method (1/5)
Performance
Now that you have clear and understandable code, you
are more likely to find truly effective methods for
restructuring code and getting real performance gains if
the need ever arises

11. Large Class (2/5)
Signs and Symptoms
A class contains many fields/methods/lines of code.

12. Large Class (2/5)
Reasons for the Problem
Classes usually start small. But over time, they get
bloated as the program grows.
As is the case with long methods as well, programmers
usually find it mentally less taxing to place a new feature
in an existing class than to create a new class for the
feature.

13. Large Class (2/5)
Treatment
✤ Extract Class helps if part of the behavior of the large class can be spun off
into a separate component.
✤ Extract Subclass helps if part of the behavior of the large class can be
implemented in different ways or is used in rare cases.
✤ Extract Interface helps if it is necessary to have a list of the operations and
behaviors that the client can use.
✤ If a large class is responsible for the graphical interface, you may try to move
some of its data and behavior to a separate domain object. In doing so, it
may be necessary to store copies of some data in two places and keep the
data consistent. Duplicate Observed Data offers a way to do this.

14. Large Class (2/5)
Payoff
✤Refactoring of these classes spares developers from
needing to remember a large number of attributes for a
class.
✤In many cases, splitting large classes into parts avoids
duplication of code and functionality.

15. Long Parameter List (3/5)
Signs and Symptoms
More than three or four parameters for a method.

16. Long Parameter List (3/5)
Reasons for the Problem
xxx

17. Long Parameter List (3/5)
Treatment
xxx

18. Long Parameter List (3/5)
Payoff
xxx

19. Long Parameter List (3/5)
Performance
xxx

20. Primitive Obsession (4/5)
Signs and Symptoms
Use of primitives instead of small objects for simple tasks (such
as currency, ranges, special strings for phone numbers, etc.)
Use of constants for coding information (such as a constant
USER_ADMIN_ROLE = 1 for referring to users with
administrator rights.)
Use of string constants as field names for use in data arrays.

21. Primitive Obsession (4/5)
Reasons for the Problem
xxx

22. Primitive Obsession (4/5)
Treatment
xxx

23. Primitive Obsession (4/5)
Payoff
xxx

24. Primitive Obsession (4/5)
Performance
xxx

25. Data Clumps (5/5)
Signs and Symptoms
Sometimes different parts of the code contain identical
groups of variables (such as parameters for connecting
to a database). These clumps should be turned into their
own classes.

26. Data Clumps (5/5)
Reasons for the Problem
xxx

27. Data Clumps (5/5)
Treatment
xxx

28. Data Clumps (5/5)
Payoff
xxx

29. Data Clumps (5/5)
Performance
xxx

30. Some examples

31. Object-oriented abusers

32. Object-
Orientation
Abusers
All these smells are incomplete or
incorrect application of object-oriented
programming principles.

33. Object-Orientation Abusers
✤ Switch statements
✤ Refused bequest
✤ Temporary field
✤ Alternative classes with different interfaces

34. Some examples

35. Change preventers

36. Change
preventers
These smells mean that if you need to
change something in one place in your
code, you have to make many changes in
other places too. Program development
becomes much more complicated and
expensive as a result

37. Change preventers
✤ Divergent change
✤ Parallel inheritance hierarchies
✤ Shotgun surgery

38. Some examples

39. Dispensables

40. Dispensables
A dispensable is something pointless and
unneeded whose absence would make the
code cleaner, more efficient and easier to
understand

41. Dispensables
✤ Comments
✤ Duplicate code
✤ Lazy class
✤ Data class
✤ Dead code
✤ Speculative generality

42. Some examples

43. Couplers

44. Couplers
All the smells in this group contribute to
excessive coupling between classes or
show what happens if coupling is
replaced by excessive delegation

45. Couplers
✤ Feature envy
✤ Inappropriate intimacy
✤ Message chains
✤ Middle man
✤ Incomplete library class

46. Some examples

47. Questions?

48. Zankiu!