www.luxoft.com

Why does software design matter and how to keep it in good shape?Evgeniy Khyst24.03.2016

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?

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?

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?

www.luxoft.com

Why does software design matter?

Design has influence on system complexity and quality.

www.luxoft.com

What is system complexity?

System complexity results in spending more and more money building IT systems.

www.luxoft.com

What is software quality?

There are visible and hidden parts of software quality.

www.luxoft.com

What is bad software design?

Bad design is rigid, fragile and difficult to reuse.

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.

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.

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.

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.

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.

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.

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.

www.luxoft.com

What is good software design?

Good design is flexible, robust, maintainable and reusable.

www.luxoft.com

What principles help to achieve good software design?

●Fundamental principles of OOP●The principles of OOD

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

www.luxoft.com

Principles about the couplings between packages

●The Acyclic Dependencies Principle●The Stable Dependencies Principle●The Stable Abstraction Principle

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.

www.luxoft.com

The Acyclic Dependencies Principle (ADP)

Create a new package and move common dependencies there.

www.luxoft.com

The Acyclic Dependencies Principle (ADP)

New module AC can be created with common dependencies for both A an C modules.

www.luxoft.com

The Acyclic Dependencies Principle (ADP)

Dependency inversion principle is one of the strategies for breaking circular dependencies.

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.

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)

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.

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.

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.

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.

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-0131857254ISBN-10: 0131857258

www.luxoft.com

How to keep software design in good shape?

●Pay off technical debt;●Opportunistic refactoring.

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.

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.

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.

www.luxoft.com

When to pay technical debt off?

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.

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.

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.

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.

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.

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.

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.

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.

www.luxoft.com

THANK YOU