View
21.785
Download
0
Category
Preview:
Citation preview
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
Recommended