SOLID Principle
- The principles are from Robert "Uncle Bob" Martin
- Michael Feathers is credited with coming up with the SOLID acronym
- S = Single Responsibility Principle
- O = Open/Closed Principle
- L = Liskov Substitution principle
- I = Interface Segregation Principle
- D = Dependency Inversion Principle
Why?
- OOP does not always lead to quality software
- Poor dependency management leads to code that is brittle, fragile, and hard to change
- Proper dependency management leads to quality code that is easy to maintain.
- The 5 principles focus on dependency management
The one thing you can always count on in software engineering is CHANGE, no matter how well you design an application over time an application must grow and change or it will die.
Single Responsibility Principle
- Every Class should have a single responsibility.
- There should never be more than one reason for a class to change.
- Your classes should be small. No more than a screen full of code.
- Avoid ‘god’ classes.
- Split big classes into smaller classes.
You can avoid these problems by asking a simple question before you make any changes: What is the responsibility of your class/component?
If your answer includes the word “and”, you’re most likely breaking the single responsibility principle. Then it’s better to take a step back and rethink your current approach.
Example: please follow the github link with bad and good example. explanation is class comment.
Real world example:
- Java Persistence API (JPA) specification. defines a standardized way to manage data persisted in a relational database by using the object-relational mapping concept.
- Spring Data Repository
- Logging
Open/Closed Principle
- Your classes should be open for extension but closed for modification
- You should be able to extend a classes behavior, without modifying it.
- Use private variables with getters and setters - ONLY when you need them.
- Use abstract/interface base classes
- Design should be ploymorphic to allow different implementations which you can easily substitute without changing the code that uses them
Example: please follow the github link with bad and good example. explanation is class comment.
Liskov Substitution Principle
- By Barbara Liskov, in 1998
- Objects in a program would be replaceable with instances of their subtypes WITHOUT altering the correctness of the program.
- Violations will often fail the “Is a” test.
- A Square “Is a” Rectangle
- However, a Rectangle “Is Not” a Square
- Can most usually be recognized by a method that does nothing, or even can’t be implemented.
- The solution to these problems is a correct inheritance hierarchy/ correct interface
- If it looks like a Duck, Quacks like a Duck but needs batteries. You probably Have the wrong abstraction.
Example: please follow the github link with bad and good example. explanation is class comment.
Interface Segregation Principle
- No matter what should never be forced to implement an interface that it does not use or the client should never be obliged to depend on any method, which is not used by them.
- Make fine grained interfaces that are client specific
- Many client specific interfaces are better than one “general purpose” interface
- Keep your components focused and minimize dependencies between them
- Changing one method in a class should not affect classes that don't depend on
- Notice relationship to the Single Responsibility Principle?
- ie avoid ‘god’ interfaces
Example: please follow the github link with bad and good example. explanation is class comment.
Dependency Inversion Principle
- Abstractions should not depend upon details
- Details should depend upon abstractions
- Important that higher level and lower level objects depend on the same abstract interaction
- Able to change an implementation easily without altering the high level code.
- This is not the same as Dependency Injection - which is how objects obtain dependent objects
Example: please follow the github link with bad and good example. explanation is class comment.
Some of other design principles
- Encapsulate what varies ( identify the aspect of your application that vary and separate them from what stays the same)
- Program to an interface not an implementation
- Favor composition over inheritance ( HAS- A can better than IS - A)
- Composition gives you a lot more flexibility. Not only does it let you encapsulate a family of algorithms into their own set of classes, but it also lets you change behavior at runtime as long as the object you are composing with implements correct behavior interface.
No comments:
Post a Comment