This presentation discusses the SOLID principles of object-oriented design, which are a set of best practices for software engineering. The SOLID principles are: single-responsibility principle, open-closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. Adhering to these principles helps create code that is loosely coupled, highly cohesive, reusable, robust, flexible, testable and maintainable. The presentation defines each principle and discusses its benefits. It also raises questions about when and how to apply the SOLID principles without over-engineering.

1. February 18, 2016
S.O.L.I.D Development Principles
Object oriented design best practices
“It is not the beauty of a building you should look at; its the construction of the
foundation that will stand the test of time.” - David Allan Coe
Presentation by: Aniket Gadre
Presented by Agency Oasis

2. Slide 2
What is SOLID?
Single-responsibility principle (SRP)
Open-closed principle (OCP)
Liskov substitution principle (LSP)
Interface segregation principle (ISP)
Dependency Inversion Principle (DIP)
Presented by Agency Oasis

3. Slide 3
Why SOLID?
• Principled way of managing dependencies
especially in a large application
• Loose coupling (degree of interdependence
between software modules)
• More cohesion (degree to which the
elements of a module belong together)
• Code is more reusable, robust, flexible,
testable and maintainable
Presented by Agency Oasis

4. Slide 4
Single Responsibility Principle (SRP)
Formal Definition: A class should have
one and only one reason to change
(single responsibility)”
Simple Definition: Do not burden one
class with too many responsibilities.
Presented by Agency Oasis

5. Slide 5
Benefits of SRP
• Code complexity is reduced
• Readability is greatly improved
• Coupling is generally reduced
• Your code has a better chance of cleanly evolving
Presented by Agency Oasis

6. Slide 6
Open Closed Principle (OCP)
Formal Definition: Entities (classes,
functions etc.) should be open for
extension but closed for modifications
Simple Definition: You should be able to
extend a class’s behavior, without
modifying it.
My definition: Ideally, once a class is
done, it’s done.
Presented by Agency Oasis

7. Slide 7
Benefits of OCP
• Easy to extend code based on new requirements
• Easier to test only the new functionality
• More maintainable code
• Fewer bugs since existing functionality is intact
Presented by Agency Oasis

8. Slide 8
Liskov Substitution Principle (LSP)
Formal Definition: Objects in a program
should be replaceable with instances of
their subtypes without altering the
correctness of that program.
Can someone explain in simple words?
Presented by Agency Oasis

9. Slide 9
LISKOV’s Substitution Principle continued…
“Let q(x) be a property provable about objects x of type T. Then q(y) should be
provable for objects of y of type S where S in a sub-type of T”
Simple Definition: Objects of the derived class must behave in a manner
consistent with the promises made in the base class' contract.“
My definition: All derived classes should be exact sub-types of the base class NOT
kind of sub-types.
Presented by Agency Oasis

10. Slide 10
Benefits of LSP
• Extension of Open/Closed principle
• Code reusability
• Reduced coupling
• Derived classes need not implement the methods
they don’t need
• Helps in code maintenance
Presented by Agency Oasis

11. Slide 11
Interface Segregation Principle (ISP)
Formal Definition: Many client-specific
interfaces are better than one general
purpose interface.
Simple Definition: Clients should not be
forced to implement interfaces they do not
use.
My definition: Break down a large class into
smaller manageable interfaces
Presented by Agency Oasis

12. Slide 12
Benefits of ISP
• Flexible design
• Easy to extend the functionality
• More maintainable code in small chunks
• Clients not forced to implement methods
they don’t need
Ex: Membership Provider
Presented by Agency Oasis

13. Slide 13
Dependency Inversion Principle (DIP)
Formal Definition: Entities must
depend on abstractions not on
concretions.”
Simple Definition: High level module
must not depend on the low level
module, but they should depend on
abstractions.
My definition: Anytime I new up a class
it’s time to look at DIP
Presented by Agency Oasis

14. Slide 14
Benefits of DIP
• Loose coupling
• More plug and play type functionality
• Mockable and testable
• More reusable code
Presented by Agency Oasis

15. Slide 15
To SOLID or not to SOLID – That is the question?
• Over engineering/Premature optimization
• Readability
• Debatable
• Lines of code
Presented by Agency Oasis

16. Slide 16
QUESTIONS?
Presented by Agency Oasis

17. February 18, 2016
Helpful links
https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
https://channel9.msdn.com/Events/TechEd/Europe/2014/DEV-B210
Presented by Agency Oasis