software design principles
DESCRIPTION
Software design principles represent a set of guidelines that helps us to avoid having a bad designTRANSCRIPT
![Page 1: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/1.jpg)
Software Design Principles
Software design principles represent a set of guidelines that helps us to avoid having a bad design
![Page 2: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/2.jpg)
Why Design? Manage complexity of a system
Improve software quality factors
Manage changes easily with minimum cost
Facilitate reusability
![Page 3: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/3.jpg)
Abstract Design Guideline
High Cohesion
Low Coupling
![Page 4: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/4.jpg)
Art of Unix Programming Rule of Clarity: Clarity is better than
cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines
Rule of Simplicity: Design for simplicity; add complexity only where you must
![Page 5: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/5.jpg)
Art of Unix Programming Rule of Transparency: Design for visibility to
make inspection and debugging easier
Rule of Robustness: Robustness is the child of transparency and simplicity
Rule of Least Surprise: In interface design, always do the least surprising thing
Rule of Silence: When a program has nothing surprising to say, it should say nothing
![Page 6: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/6.jpg)
Art of Unix Programming Rule of Repair: When you must fail, fail noisily
and as soon as possible
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time
Rule of Optimization: Prototype before polishing. Get it working before you optimize it
Rule of Extensibility: Design for the future, because it will be here sooner than you think
![Page 7: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/7.jpg)
Symptoms of Rotting Design
RigidityFragilityImmobilityViscosity
![Page 8: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/8.jpg)
Rigidity• Difficult to change• Ripple Effect• Entering roach motel
A software can be called a rigid when it is difficult to change even in a sample way
When the manager’s fears become so acute that they refuse to allow changes to software, official rigidity sets in. Thus, what starts as a design deficiency, winds up being adverse management policy.
![Page 9: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/9.jpg)
Fragility• Conceptually irrelevant pieces
breaking in multiple places• Such software is impossible to
maintain. Every fix makes it worse, introducing more problems than are solved
• Managers and Customers have a feeling that Developers have lost control over the project
Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed
![Page 10: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/10.jpg)
Immobility
• Inability to reuse software
• Software is simply rewritten instead of reused
Immobility is the inability to reuse software from other projects or from parts of the same project. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote
I am asking for someone NOT everyone
![Page 11: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/11.jpg)
Viscosity
• It is easy to do the wrong thing, but hard to do the right thing
• When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high
• Viscosity of environment comes about when the development environment is slow and inefficient
![Page 12: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/12.jpg)
These four symptoms are the tell-tale signs of poor architecture. Any application that exhibits them is suffering from a design that is rotting from the inside out. But what causes that rot to take place?
Changing Requirements Changing Technologies Human Error Dependency Management
![Page 13: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/13.jpg)
OO Design Principles• Single Responsibility Principle (SRP)• Open Closed Principle (OCP)• Liskov Substitution Principle (LSP)• Interface Segregation Principle (ISP)• Dependency Inversion Principle (DIP)• Tell Don’t Ask• DRY – Don’t Repeat yourself• Once and only once• The Law of Demeter• Package Principles• DRY• YAGNI
![Page 14: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/14.jpg)
Single Responsibility Principle (SRP)
There should never be more than one reason for a class to change.
![Page 15: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/15.jpg)
SRP (Cont’d)
![Page 16: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/16.jpg)
SRP (Cont’d)
![Page 17: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/17.jpg)
Open Closed Principle (OCP)
• A module should be open for extension but closed for modification
![Page 18: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/18.jpg)
OCP (Cont’d)
![Page 19: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/19.jpg)
OCP (Cont’d)
![Page 20: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/20.jpg)
Liskov Substitution Principle (LSP)
• Subclasses should be substitutable for their base classes.
![Page 21: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/21.jpg)
LSP (Cont’d)
![Page 22: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/22.jpg)
Interface Segregation Principle (ISP)
• Many client specific interfaces are better than one general purpose interface
![Page 23: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/23.jpg)
ISP (Cont’d)
![Page 24: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/24.jpg)
Dependency Inversion Principle (DIP)
• Depend upon Abstractions. Do not depend upon concretions
![Page 25: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/25.jpg)
DIP (Cont’d)
![Page 26: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/26.jpg)
DIP (Cont’d)
![Page 27: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/27.jpg)
Tell Don’t Ask
• Don't call us we will call you• Hollywood Principle
![Page 28: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/28.jpg)
Tell Don’t Ask (Cont’d)
if(getStateOfSomething()) doThis();else doThat();
object.doSomethingForMe();
V/S
![Page 29: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/29.jpg)
DRY – Don’t Repeat yourself
Once and only once
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system
Refactoring has as a primary objective getting each piece of functionality to exist in exactly one place in the software. –Ron Jeffries
![Page 30: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/30.jpg)
The Law of Demeter
• Any method of an object should only call methods belonging to:– itself– any composite objects– any parameters that were passed in to the
method– any objects it created
![Page 31: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/31.jpg)
Train Wreck?
• Methods belonging to objects that were returned from some other call.
my_television.front_panel.switches.power.on();
v/smy_television.power_up();
• Talk only to your neighbors, not with their neighbors.
![Page 32: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/32.jpg)
YAGNI (You ain’t gonna need it)
"Always implement things when you actually need them, never when you just foresee that you need them.” – Ron Jeffries
The need for combining it with the supporting practices, rather than using it standalone
![Page 33: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/33.jpg)
Package Principles
Cohesion Principles
Coupling Principles
![Page 34: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/34.jpg)
Package Cohesion Principles
Classes are a necessary, but insufficient, means of organizing a design. The larger granularity of packages are needed to help bring order. But how do we choose which classes belong in which packages. There are three principles known as the Package Cohesion Principles, that attempt to help the software architect.
Release Reuse Equivalency Principle (REP)- The granule of reuse is the granule of release.
Common Closure Principle (CCP) - Classes that change together, belong together.
Common Reuse Principle (CRP) - Classes that aren’t reused together should not be grouped together.
![Page 35: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/35.jpg)
Package Coupling Principles
three packages govern the interrelationships between packages. Applicationstend to be large networks of interrelated packages. The rules that govern these interrelationship are some of the most important rules in object oriented architecture.
Acyclic Dependencies Principle (ADP)-The dependencies between packages must not form cycles.
Stable Dependencies Principle (SDP)- Depend in the direction of stability.
Stable Abstractions Principle (SAP)
- Stable packages should be abstract packages.
![Page 36: Software design principles](https://reader033.vdocument.in/reader033/viewer/2022052822/554bd60cb4c9058f6c8b50d5/html5/thumbnails/36.jpg)
DIP IoC DI & Factory Pattern
• Dependency Injection Principle• Inversion of Control• Dependency Injection
• Practice: Information retrieving from several file types. By applying DIP, IoC, DI and Factory Pattern