Evgeniy Khyst - why does software design matter and how to keep it in good shape

1. www.luxoft.com
Why does software design
matter and how to keep it in
good shape?
Evgeniy Khyst
24.03.2016

2. www.luxoft.com
Why does software design matter and how to keep it in
good shape?
● Why does software design matter?
● What is system complexity?
● What is software quality?
● What is bad software design?
● What is good software design?
● What principles help to achieve good software design?
● How to keep software design in good shape?
● When to do refactoring?

3. www.luxoft.com
Difference between design and architecture
Software architecture is the high level structures of a software
system.
● What kind of data storage is used?
● How is caching implemented?
● How do modules interact with each other?
● How is high availability achieved?

4. www.luxoft.com
Difference between design and architecture
Software design refers to the design on the individual modules.
● What are the responsibilities of the modules?
● What are the responsibilities of the classes?
● What design patterns are used?

5. www.luxoft.com
Why does software design matter?
Design has influence on system complexity and quality.

6. www.luxoft.com
What is system complexity?
System complexity results in spending more and more money building IT systems.

7. www.luxoft.com
What is software quality?
There are visible and hidden parts of software quality.

8. www.luxoft.com
What is bad software design?
Bad design is rigid, fragile and difficult to reuse.

9. www.luxoft.com
Rigidity
● A design is rigid if it can not be easily changed.
● A single change begins a cascade of changes in dependent
packages.
● If the effort of that cascade of change can not be predicted by
designers and maintainers the impact of the change can not be
estimated. This makes the cost of the change impossible to
estimate.

10. www.luxoft.com
Fragility
● Fragility is the tendency of a program to break in many places
when a single change is made.
● Often the new problems are in areas that have no conceptual
relationship with the area that was changed.
● This leads to inability to predict the quality of the product.
● Simple changes to one part of the application lead to failures in
other parts appear to be completely unrelated.
● Fixing those problems leads to even more problems.

11. www.luxoft.com
Immobility
● A design is difficult to reuse when the desirable parts of the
design are highly dependent upon other details which are not
desired.
● Often the amount of work necessary to separate the desirable
portion of the design from the other portions of the design that
are undesirable design is high.

12. www.luxoft.com
What is reusability?
● Reusability is one of the most important goals of OOD.
● Copying a bunch of code from one program and textually
inserting it into another is not a reuse it is copying.
● When code is copied it becomes yours.
● You have to change it, fix bugs and add new features instead of
original author.
● The code is reused if, and only if, developer doesn’t need to look
at the source code, but needs only include library.

13. www.luxoft.com
Viscosity
One more symptom of bad software design is viscosity.
There are 2 types of viscosity:
● viscosity of the design,
● viscosity of the environment.

14. www.luxoft.com
Viscosity of the design
● Viscosity of the design refers to the ease at which a developer
can add design-preserving code to a system.
● Design has high viscosity, if design preserving methods are
harder to employ than the hacks.
● Engineers usually find more than one way to make the change.
● Some of the ways preserve the design, others do not and are
hacks.

15. www.luxoft.com
Viscosity of the environment
● Viscosity of the environment refers to performance and
effectiveness of development environment.
● Viscosity of the environment is high if development
environment is slow and inefficient.

16. www.luxoft.com
What is good software design?
Good design is flexible, robust, maintainable and reusable.

17. www.luxoft.com
What principles help to achieve good software design?
● Fundamental principles of OOP
● The principles of OOD

18. www.luxoft.com
Fundamental principles of OOP
Object-oriented programming is a programming paradigm based
on using objects that are instances of classes, consisting of fields,
methods, and their interaction for designing applications.
Fundamental principles of OOP:
● Abstraction
● Encapsulation
● Inheritance
● Polymorphysm

19. www.luxoft.com
Abstraction
● Abstraction is a fundamental principle of software
development that allows to reduce coupling between software
modules.
● Abstraction is formulation of generalized concept disregarding
not important features, properties and relations in order to
focus on distinctive features.
● Abstraction captures only those details about an object that are
relevant to the current perspective.

20. www.luxoft.com
Abstraction
● Abstraction is an interface to data type or functionality and can
have multiple implementations.
● Concrete implementation is never referenced directly and can
be replaced with another implementation without requiring
changes in client code.
● Client code should depend on abstraction, not the particular
implementation.

21. www.luxoft.com
Polymorphysm
Polymorphysm (from Greek polys, "many, much" and morphē,
"form, shape") is the possibility of objects with the same
specification to have different implementation.

22. www.luxoft.com
The principles of OOD
● Principles of class design;
● Principles about package cohesion, telling what to put into
packages;
● Principles about the coupling between packages.

23. www.luxoft.com
Principles of class design
● The Single Responsibility Principle
● The Open Closed Principle
● The Liskov Substitution Principle
● The Interface Segregation Principle
● The Dependency Inversion Principle
These 5 principles are also known as SOLID principles.

24. www.luxoft.com
The Single Responsibility Principle (SRP)
A class should have only one reason to change.
● A responsibility is “a reason to change”.
● If there are more than one motive for changing a class, then
that class has more than one responsibility.
● This principle also called cohesion.
● Cohesion is the functional relatedness of the elements of a
module.

25. www.luxoft.com
The Open-Closed Principle
Software entities (classes, modules, functions etc.) should be open
for extension, but closed for modification.
● The behaviour of modules is changed by adding new code, not
by changing old code that already works.
● Such modules can be created by using abstract classes, Strategy
pattern (GoF) etc.

26. www.luxoft.com
The Liskov Substitution Principle (LSP)
Functions that use pointers or references to base classes must be
able to use objects of derived classes without knowing it.
● This principle is also known as “Design by Contract”.
● Any function which uses a base class must not be confused
when a derived class is substituted for the base class.

27. www.luxoft.com
The Interface Segregation Principle (IPS)
Clients should not be forced to depend upon interfaces that they
do not use.
● Classes that have fat interfaces are not cohesive and the
interfaces of the class can be broken up into groups of member
functions. Each group serving a different set of clients.
● There are objects that requires non-cohesive interfaces, but
clients should not know about them as a single class, but should
know about cohesive implemented interfaces instead.

28. www.luxoft.com
The Dependency Inversion Principle (DIP)
● High level modules should not depend upon low level modules.
Both should depend upon abstraction.
● Abstractions should not depend upon details. Details should
depend upon abstraction.

29. www.luxoft.com
The Dependency Inversion Principle (DIP)
When this principle is adhered to, both the high level policy modules, and the
low level detail modules will be reusable and maintainable.

30. www.luxoft.com
Coupling
● OCP, ISP and DIP principles are related to coupling.
● Coupling refers to the degree of direct knowledge that one
component has of another.
● An example of tight coupling occurs when a dependent class
contains a pointer directly to a concrete class which provides
the required behavior.
● Loose coupling occurs when the dependent class contains a
pointer only to an interface, which can then be implemented by
one or many concrete classes.

31. www.luxoft.com
Principles about package cohesion
In this context a package is a binary deliverable like a .jar file.
● The Reuse/Release Equivalence Principle
● The Common Reuse Principle
● The Common Closure Principle

32. www.luxoft.com
The Reuse/Release Equivalence Principle (REP)
The granule of reuse is the granule of release. Only components
that are released through a tracking system can be effectively
reused. This granuli is the package.

33. www.luxoft.com
The Common Reuse Principle (CRP)
The classes in a package are reused together. If you reuse one of
the classes in a package, you reuse them all.

34. www.luxoft.com
The Common Closure Principle (CCP)
The classes in a package should be closed together against the
same kinds of changes. A change that affects a package affects all
the classes in that package.

35. www.luxoft.com
Principles about the couplings between packages
● The Acyclic Dependencies Principle
● The Stable Dependencies Principle
● The Stable Abstraction Principle

36. www.luxoft.com
The Acyclic Dependencies Principle (ADP)
The dependency structure between packages must be a Direct
Acyclic Graph (DAG). That is, there must be no cycles in the
dependency structure.

37. www.luxoft.com
The Acyclic Dependencies Principle (ADP)
Create a new package and move common dependencies there.

38. www.luxoft.com
The Acyclic Dependencies Principle (ADP)
New module AC can be created with common dependencies for both A an C modules.

39. www.luxoft.com
The Acyclic Dependencies Principle (ADP)
Dependency inversion principle is one of the strategies for breaking circular dependencies.

40. www.luxoft.com
Stability
● Stability is a measure of the difficulty in changing a module.
● Stability is not a measure of likelihood that a module will
change.

41. www.luxoft.com
Stability
● Afferent Coupling (Ca) - the number of classes outside this
package that depend upon classes within this package.
● Efferent coupling (Ce) - the number of classes inside this
package that depend upon classes outside this package.
● Instability (I) - has the range [0, 1]. 0 indicates a maximally
stable package. 1 indicates a maximally instable package.
● I = Ce / (Ca + Ce)

42. www.luxoft.com
The Stable Dependencies Principle (SDP)
The dependencies between packages in a design should be in the
direction of the stability of the packages. A package should only
depend upon packages that are more stable than it is.

43. www.luxoft.com
The Stable Abstraction Principle (SAP)
Packages that are maximally stable should be maximally abstract.
Unstable packages should be concrete. The abstraction of a
package should be in proportion to its stability.

44. www.luxoft.com
Symptoms of bad software design
● If it is hard to come up with the name of class or method
probably the abstraction is wrong and design requires changes.
● If you can’t find a name for a class or method maybe it is
unnecessary.
● If it is hard to write unit tests, then the responsibilities are
assigned to classes incorrectly and design doesn’t follow the
principles of OOD.

45. www.luxoft.com
Symptoms of bad software design
● The name of the unit test method is crucially important.
● If you can’t find good descriptive name for test that can be
treated as a requirements probably the test is unnecessary or
the abstraction is wrong.
● Good unit test can serve as documentation.

46. www.luxoft.com
More information about principles of OOD
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Agile Principles, Patterns, and Practices in C#
by Robert C. Martin and Micah Martin
ISBN-13: 978-0131857254
ISBN-10: 0131857258

47. www.luxoft.com
How to keep software design in good shape?
● Pay off technical debt;
● Opportunistic refactoring.

48. www.luxoft.com
Technical debt
There are 2 ways to add new functionality into system:
● do it quick but dirty,
● do it preserving clean design but longer.

49. www.luxoft.com
Technical debt
● Doing things quickly but dirty will result in additional work in
future required to make design cleaner that can be considered
as debt.
● The technical debt will come in the form of the extra effort in
future development because of the quick and dirty design
choice.
● Developers can choose technical debt in order to hit deadline
understanding the consequences.

50. www.luxoft.com
When to pay technical debt off?
● It is very important to not let technical debt get out of control
and spend time in future development paying debt off.
● Not paying attention to technical debt will result in increasing
system complexity and decreasing quality.
● There is a payoff deadline when losses on extra development
become more than benefits on taking technical debt.

51. www.luxoft.com
When to pay technical debt off?

52. www.luxoft.com
Example of managing technical debt in agile project
80% of the total team’s capacity can be spent on features
development and 20% on technical debt pay off.

53. www.luxoft.com
Use refactoring to keep a design clean
● Code refactoring is the process of restructuring existing
computer code without changing its external behavior.
● Refactoring improves code readability and reduces complexity,
improves code maintainability and allows to keep design clean.

54. www.luxoft.com
Refactoring techniques
Techniques that allow for more abstraction:
● Encapsulate Fields;
● Extract Interface/Supercalss sharing;
● Use Supertype where possible;
● Replace type-checking code with State/Strategy;
● Replace conditional with polymorphism;
● Replace Constructor with Factory;
● Replace Constructor with Builder.

55. www.luxoft.com
Refactoring techniques
Techniques for breaking code apart into more logical pieces:
● Introduce Method – turn part of a larger method into a new
method. By breaking down code in smaller pieces, it is more
easily understandable;
● Introduce Variable/Constant/Field.

56. www.luxoft.com
Refactoring techniques
Techniques for improving names and location of code:
● Move Class/Method/Field/Variable – move to a more
appropriate Class or source file;
● Rename Class/Method/Field/Variable – changing the name into
a new one that better reveals its purpose;
● Change Method signature;
● Pull Up – in OOP, move to a superclass;
● Push Down – in OOP, move to a subclass.

57. www.luxoft.com
When to do refactoring?
● Opportunistic refactoring means that at any time someone
sees some code that isn't as clear as it should be, they should
take the opportunity to fix it right there and then - or at least
within a few minutes.
● Also known as “boy-scout rule” - always leave the code behind
in a better state than you found it.
● If everyone on the team is doing this, they make small regular
contributions to code base health every day.

58. www.luxoft.com
Groupthink
● Groupthink is a psychological phenomenon that occurs within a
group of people, in which the desire for harmony or conformity
in the group results in an irrational or dysfunctional decision-
making outcome.
● Group members try to minimize conflict and reach a consensus
decision without critical evaluation of alternative viewpoints, by
actively suppressing dissenting viewpoints, and by isolating
themselves from outside influences.

59. www.luxoft.com
Groupthink
1. Leaders should assign each member the role of "critical evaluator". This allows each
member to freely air objections and doubts.
2. Leaders should not express an opinion when assigning a task to a group.
3. Leaders should absent themselves from many of the group meetings to avoid
excessively influencing the outcome.
4. The organization should set up several independent groups, working on the same
problem.
5. All effective alternatives should be examined.
6. Each member should discuss the group's ideas with trusted people outside of the
group.
7. The group should invite outside experts into meetings. Group members should be
allowed to discuss with and question the outside experts.

60. www.luxoft.com
THANK YOU