![replaceable with base types (No need to change code).
For example, we have method called StoreAddress(Address address) which accepts type
“Address” as input parameter and stores it into the data store. Now if we make derived type
from the “Address” type named “HomeAddress” then I should be able to call the same
method by passing type “HomeAddress” and it stores correctly into the data store.
Interface Segregation Principle (ISP)
In nutshell, the principle states that “Clients should not be forced to depend upon interfaces
that they don’t use”. When we simplify it states that when interface is too heavy, just break it
down to the smaller and more specific interfaces which is client oriented so that clients
should only worry about their concerned part.
For example if we have <> interface which has “fly()” method and is implemented by Duck
class. Now if we have wooden duck?
Dependency Inversion Principle (DIP) [also known as Inversion of Control or
Hollywood Principle: Don’t call us, we’ll call you or Dependency Injection]
The Dependency Inversion principle refers to specific form of decoupling where conventional
dependency relationship established from high level. The principle states two things.
1. High-level modules should not depend on low-level modules. Both should depend on
abstractions.
2. Abstractions should not depend upon details. Details should depend upon abstractions.
The main goal of dependency inversion principle is to decouple high-level components from
low-level components in such a manner that reuse of low-level component implementations
become possible.
For example Adapter Pattern does the same thing. The high-level class defines its own
adapter interface which is the abstraction that the high-level class depends on. The adaptee
implementation also depends on the adapter interface abstraction. The high-level has no
dependency to the low-level module since it only uses low-level indirectly through the adapter
interface by working polymorphic methods to the interface which are implemented by the
adaptee and its low-level module.
References
http://www.objectmentor.com/resources/articles/dip.pdf
http://www.oodesign.com/dependency-inversion-principle.html
http://www.oodesign.com/design-principles.html
https://www-01.ibm.com/software/ucd/designconcepts/designbasics.html
http://en.wikipedia.org
Blog this!
Bookmark on Delicious
Digg this post
Recommend on Facebook
Share on FriendFeed
Share on Linkedin
Share on Orkut
share via Reddit](https://image.slidesharecdn.com/softwaredesignprinciples-jinaldesai-120503151436-phpapp02/85/Software-design-principles-jinal-desai-3-320.jpg)
Software design principles - jinal desai
- 1. Articles from Jinal Desai Software Design Principles 2012-05-03 19:05:33 Jinal Desai There are many design principles that have become best practices over the years. Using these principles we can develop scalable and maintainable enterprise application with time tested approaches. 1. Keep It Simple Stupid (KISS) The main goal here is keep things simple. Avoiding unnecessary complexity will help to keep it clear and easy to understand. Also this principle will help in maintenance; if it is simple then also easy to modify. Usually the simplest solution is the best solution. 2. Don’t Repeat Yourself (DRY) This principle states to not repeat things. We can abstract out repeated things and keep it at some common place where everybody can access it. We can also make common (repeating) things as general, so that it is available to all. 3. Separation of Concerns (SoC) Separating things into discrete responsibilities increases reusability, maintenance and also testability. Here concerns refer to specific features or behavior of the system. For example, Object Oriented programming languages such as C++, C# and Java (to name a few) can separate concerns into objects. A Design Pattern like MVC (Model-View-Controller) can separate content from presentation and data processing (model) from content. Service Oriented design can separate concerns into services. Procedural programming languages such as C can separate concerns into procedures. Aspect Oriented programming languages can separate concerns into aspects and objects. 4. The Pareto Principle The famous pareto principle states that 80% of effects comes from 20% of causes, i.e. 80% of sales comes from 20% of customers. The principle is named after Italian economist Vilfredo Pareto, who observed in 1906 that 80% of land in Italy is owned by 20% of the population. It can help to resist efforts to correct and optimize designs beyond critical 20%. So 80% focus is on 20% part of the stuff. In software engineering Pareto principle can be applied to optimization efforts. For example, Microsoft noted that by fixing the top 20% of the most reported bugs, 80% of the errors and crashes would be eliminated. 5. The Robustness Principle The Robustness Principle states that, “Be liberal in what you accept, and be conservative in what you send”. In other words, code that sends commands or data to other parts of the system should conform completely to the specifications, but code that receives input should accept non- conformant input as long as the meaning is clear. For example, TCP implementation follows the principle. 6. You Ain’t Gonna Need It (YAGNI) It is the principle in extreme programming, states that programmers should not add functionality until it is necessary. It tells programmers that always implement things when you actually need them, never when you just foresee that you need them. Even if you are sure that you will need it later on, do not implement it now. The principle is actually emerged from “Extreme Programming” methodologies.
- 2. 7. Loose Coupling and High Cohesion Coupling means links between separate units of a program. In OOPs, if two classes depend closely on many details of each other, we say they are tightly coupled. Coupling is a measure of the interdependence between types/entities. If every object has a reference to every other object, then there is tight coupling, which is undesirable. Because there’s potentially too much information flow between objects. Loose coupling is desirable. It means that objects work more independently of each other. Loose coupling minimizes the “ripple effect” where changes in one class cause necessity for changes in other classes Cohesion refers to the number and diversity of tasks that a class is designed for. If a class is responsible for a few related logical tasks, we say it has high cohesion. Cohesion is a measurement of strengths of the association of variables and methods within a class. High cohesion is desirable because it means the class does one job well. Low cohesion is undesirable because it indicates that there are elements in the class which have little to do with each other. Modules whose elements are strongly and genuinely related to each other are desired. Each method should also be highly cohesive. Most methods have only one function to perform. Don’t add extra instructions into methods that cause it to perform more than one function Loose Coupling has following advantages: We can understand concerned class without reading other classes We can change one class without affecting other classes Loose Coupling improves maintainability High Cohesion has following advantages: We can easily understand what is the purpose of class or method High Cohesion makes it easier to use descriptive names We can easily reuse classes or methods 8. SOLID Principles Single Responsibility Principle (SRP) The Principle states that every object should have single responsibility, and the responsibility (reason to change) should be entirely encapsulated by the class. So a class or module should have one and only one reason to change. For example, we have a print report module. There are utmost two reasons to change the module. First is content of report is changed. Second is format of report is changed. Open Closed Principle (OCP) Software entities (i.e. classes, functions or modules) should be open for extension but closed for modification. Normally we close entities modification for providing backward compatibility (regression testing) and open entities extension for extending existing entities with new functionalities. For example, we can implement this principle by using Abstract classes, and thus enforcing concrete classes extend abstract classes rather than changing it. Some of the design patterns that supports this principle is template pattern and strategy pattern. In .NET Framework Microsoft has further supported this principle by providing partial classes/methods and extension methods. You can extend existing code by using these two new features in .NET. Liskov’s Substitution Principle (LSP) The principle states that derived types must be completely substitutable for their base types. It is just an extension of Open Closed Principle in terms of behavior. Meaning that the derived types must extend without changing behavior of base types, so that derived types is
- 3. replaceable with base types (No need to change code). For example, we have method called StoreAddress(Address address) which accepts type “Address” as input parameter and stores it into the data store. Now if we make derived type from the “Address” type named “HomeAddress” then I should be able to call the same method by passing type “HomeAddress” and it stores correctly into the data store. Interface Segregation Principle (ISP) In nutshell, the principle states that “Clients should not be forced to depend upon interfaces that they don’t use”. When we simplify it states that when interface is too heavy, just break it down to the smaller and more specific interfaces which is client oriented so that clients should only worry about their concerned part. For example if we have <> interface which has “fly()” method and is implemented by Duck class. Now if we have wooden duck? Dependency Inversion Principle (DIP) [also known as Inversion of Control or Hollywood Principle: Don’t call us, we’ll call you or Dependency Injection] The Dependency Inversion principle refers to specific form of decoupling where conventional dependency relationship established from high level. The principle states two things. 1. High-level modules should not depend on low-level modules. Both should depend on abstractions. 2. Abstractions should not depend upon details. Details should depend upon abstractions. The main goal of dependency inversion principle is to decouple high-level components from low-level components in such a manner that reuse of low-level component implementations become possible. For example Adapter Pattern does the same thing. The high-level class defines its own adapter interface which is the abstraction that the high-level class depends on. The adaptee implementation also depends on the adapter interface abstraction. The high-level has no dependency to the low-level module since it only uses low-level indirectly through the adapter interface by working polymorphic methods to the interface which are implemented by the adaptee and its low-level module. References http://www.objectmentor.com/resources/articles/dip.pdf http://www.oodesign.com/dependency-inversion-principle.html http://www.oodesign.com/design-principles.html https://www-01.ibm.com/software/ucd/designconcepts/designbasics.html http://en.wikipedia.org Blog this! Bookmark on Delicious Digg this post Recommend on Facebook Share on FriendFeed Share on Linkedin Share on Orkut share via Reddit
- 4. Share with Stumblers Share on technorati Tweet about it Subscribe to the comments on this post