Design Principles
-
Upload
kartheeknagasuri -
Category
Documents
-
view
523 -
download
1
description
Transcript of Design Principles
![Page 1: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/1.jpg)
Design Principles
ByKartheek Nagasuri & Amit Grewal
![Page 2: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/2.jpg)
Design
• What is the meaning of the Design?
• What is the Difference if compared to Analysis?
Design is about “How”
Analysis is about “What”
![Page 3: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/3.jpg)
Design
Why do we need (good) design?
To Manage Change
To Deal with Complexity
To Deliver Faster
![Page 4: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/4.jpg)
Design
• How do we know a design is bad?
“W*F? “
“W*F? “
“W*F? ““W*F? “
“W*F? “
“W*F? “
“W*F? “
“W*F? “I can’t Fix this code
I fixed the problem but it broke at other places..
![Page 5: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/5.jpg)
Immobility
Design
• Lets talk about criteria of bad design • Are there any Symptoms of bad design?
Rigidity
Fragility Viscosity
![Page 6: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/6.jpg)
Rigidity
• The Impact of the change is Unpredictable– Every change causes a cascade of changes in
dependant modules.– A nice 2 days work become endless “Marathon”– Costs become unpredictable.
![Page 7: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/7.jpg)
![Page 8: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/8.jpg)
Immobility
• Its almost impossible to reuse interesting parts of the software– The useful modules have somany depandancies– The cost of rewriting is less compared to the risk
faced to separate those parts
![Page 9: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/9.jpg)
Fragility
• The Software tends to break in many places on every change.– The breakage occurs in areas with no conceptual
relationship.– On every fix the software breaks in unexpected
ways.
![Page 10: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/10.jpg)
Viscosity
• A hack is cheaper to implement than the solution with in the design– preserving design moves are difficult to think and
to implement.– Its much easier to do wrong thing than the right
one.
![Page 11: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/11.jpg)
• What is the reason why design becomes rigid, fragile, immobile and viscous?
Design
Improper dependencies
between the modules
![Page 12: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/12.jpg)
Good Design
• What are the characteristics of a good design
High Cohesion
Low coupling
![Page 13: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/13.jpg)
How can we achieve good design?
![Page 14: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/14.jpg)
Let’s Go SOLID…
• Single Responsibility Principle• Open Close Principle• Liskov Substitution Principle• Interface Segregation Principle• Dependency Inversion Principle
![Page 15: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/15.jpg)
Single Responsibility Principle
![Page 16: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/16.jpg)
Single Responsibility Principle
• A software module should have one and only responsibility
• A software module should have one reason only to change
• It translates directly in high cohesion
![Page 17: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/17.jpg)
Single Responsibility Principle
• Is SRP violate here?Interface modem{
Public Void Dial (string pno);Public void hangup();Public void send (char c);Public char receive();
}
![Page 18: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/18.jpg)
Single Responsibility Principle
• Is SRP violate here?Interface Employee
{Public pay calculate();Public void report(Writer w);Public void save();Public void reload();
}
![Page 19: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/19.jpg)
How to Solve?
public abstract class BankAccount { double Balance { get; } void Deposit(double amount) {} void Withdraw(double amount) {} void AddInterest(double amount) {} void Transfer(double amount, IBankAccount toAccount) {}
}
![Page 20: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/20.jpg)
public abstract class BankAccount {
double Balance { get; }void Deposit(double amount); void Withdraw(double amount); void Transfer(double amount, IBankAccount toAccount);
}
public class CheckingAccount : BankAccount { }
public class SavingsAccount : BankAccount{
public void AddInterest(double amount); }
![Page 21: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/21.jpg)
Open Closed Principle
![Page 22: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/22.jpg)
Open Closed Principle
• Modules should be open for extension but closed for modification.
• “You should be able to extend the behavior of a module without changing it”
![Page 23: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/23.jpg)
public class ProductFilter {
public IEnumerable<Product> ByColor(IList<Product> products, ProductColor productColor)
{ foreach (var product in products) {
if (product.Color == productColor) yield return product;
} } }
![Page 24: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/24.jpg)
public class ProductFilter {
public IEnumerable<Product> BySize(IList<Product> products, ProductSize productSize)
{ foreach (var product in products) {
if (product.Size== productSize) yield return product; } } }
![Page 25: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/25.jpg)
public class ProductFilter {
public IEnumerable<Product> BySize(IList<Product> products, ProductColor productColor, ProductSize productSize)
{ foreach (var product in products) {
if (product.Size== productSize && product.color==productColor)
yield return product; } } }
![Page 26: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/26.jpg)
Any Problem?
• Every time a user asks for new criteria to filter a product, do we have to modify the ProductFilter class?
– Yes! This means it is not CLOSED for modification.• Every time a user asks for new criteria to filter a product, can
we extend the behavior of the ProductFilter class to support the new criteria, without opening up the class file again and modifying it?
– No! This means it is not OPEN for extension.
![Page 27: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/27.jpg)
Solution
• Template
public abstract class roductFilterSpecification { public IEnumerable<Product> Filter(IList<Product> products) {
return ApplyFilter(products); } protected abstract IEnumerable<Product> ApplyFilter(IList<Product> products);
}
![Page 28: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/28.jpg)
public class ColorFilterSpecification :ProductFilterSpecification
{ private readonly ProductColor productColor;
public ColorFilterSpecification(ProductColor productColor) {
this.productColor = productColor; } protected override IEnumerable<Product>
ApplyFilter(IList<Product> products) { foreach (var product in products) { if (product.Color == productColor) yield return
product; } } }
![Page 29: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/29.jpg)
public IEnumerable<Product> By(IList<Product> products, ProductFilterSpecification filterSpecification)
{ return filterSpecification.Filter(products);
}
![Page 30: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/30.jpg)
Are we Fine now?
![Page 31: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/31.jpg)
Liskov Substitution Principle
![Page 32: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/32.jpg)
Liskov Substitution Principle
• Functions that use ... references to base classes must be able to use objects of derived classes without knowing it.
• A user of a base class should continue to function properly if a derivative of that base class is passed to it.
![Page 33: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/33.jpg)
Interface Segregation Principle
![Page 34: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/34.jpg)
Interface Segregation Principle
• ISP States that clients should not know about fat classes.
• Instead they should rely on clean cohesive interfaces
• Many client specific interfaces are better than one general purpose interface
![Page 35: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/35.jpg)
• A class with many clients, and one large interface to serve them all
Interface Segregation Principle
![Page 36: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/36.jpg)
Interface Segregation Principle
![Page 37: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/37.jpg)
Dependency Inversion Principle
![Page 38: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/38.jpg)
Dependency Inversion Principle
• High level modules should not depend on low level modules, both should depend
• Abstractions should not depend upon details, details should depend upon abstractions
• Every dependency in the design should target an interface, or an abstract class. No dependency should target a concrete class.
![Page 39: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/39.jpg)
Dependency Inversion Principle
![Page 40: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/40.jpg)
Dependency Inversion Principle
![Page 41: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/41.jpg)
Dependency Inversion Principle
• Don’t depend on anything concrete, depend only upon abstraction
• High level modules should not be forced to change because of a change in low level/technology layers
• Drives you towards low coupling
![Page 42: Design Principles](https://reader038.fdocuments.in/reader038/viewer/2022110114/547eb251b4af9f741d8b482b/html5/thumbnails/42.jpg)
Conclusion
• The main forces driving your design should be “High Cohesion” and “Low coupling”
• SOLID principles put you on right path.