object oriented design principles, COUPLING & COHESION, Open-Closed (open for extension; closed for modification) Principle Liskov Substitution Principle (LSP) Dependency Inversion Principle (DIP) Single Responsibility Principle (SRP) Interface Segregation Principle (ISP)

1. OO Design Principles

2. Key OO Design Principles
 Object Oriented programming’s goal is to make it
possible to write code that is maintainable, easy to
understand, and reusable.
 The principle goal of the OO Principles and Design
patterns is to come up with designs that can, as
easily as possible, be modified when the program
requirements change.
 Following these OO Design Principles will help you
write better OO code.

3. COUPLING & COHESION
 Is a measure of strength
of association established
by a connection from one
object or s/w component
to another.
 It is a binary
relationship.
 Increase with increase in
complexity of interfaces.
 Is the interaction within
a single object or
software component.
 Reflects the single –
purposeness of an object.
 Highly cohesive
components can lower
coupling.

4. COUPLING
Interaction coupling.
This involves the
amount and complexity
of messages between
components.
These have only little
interactions.
Inheritance coupling.
Coupling between
super class and subclass
Subclass is coupled
with super class in terms
of attributes and
methods.

5. Important OO Design Principles
1. Open-Closed (open for extension; closed for
modification) Principle
2. Liskov Substitution Principle (LSP)
3. Dependency Inversion Principle (DIP)
4. Single Responsibility Principle (SRP)
5. Interface Segregation Principle (ISP)

6. Open-Closed Principle
 Software entities should be open for extension,
but closed for modification.
 Open for extension: behavior can be changed to
suite new requirements
 Closed for modification: module itself doesn’t
change
 Whenever a software system must support a set
of alternatives, ideally only one class in the
system knows the entire set of alternatives

7.  The Open-Closed Principle (OCP) says that we
should attempt to design modules that never
need to be changed.
 To extend the behavior of the system, we add new
code. We do not modify old code.
 Modules that conform to the OCP meet two
criteria:
 Open For Extension - The behavior of the module can be
extended to meet new requirements
 Closed For Modification - the source code of the module is
not allowed to change
 How can we do this?
 Abstraction, Polymorphism, Inheritance, and Interfaces

8. OCP
If new shapes are needed,
Circle Square
DrawAllShapes Shape

9. OCP
Circle Square
DrawAllShapes
Triangle Pentagon
Shape

10. OCP Violation
If new shapes are needed,
Square
Circle
ShapeDrawAllShapes

11. OCP Violation
Circle
Square
DrawAllShapes
Triangle
Pentagon
Shape

12. OCP Summary
 Open for extension
 Add new code for new functionality, don't modify existing
working code
 Concrete implementations of interfaces somewhere
 Closed for modification
 Need to anticipate likely modifications to be able to plan
ahead in the design . e.g. ordering shapes? No closure
against this requirement ... but could be added in a design-
preserving way .

13. Liskov Substitution Principle (LSP)
 If for each object o1 of type S there is an object
o2 of type T such that for all programs P
defined in terms of T, the behavior of P is
unchanged when o1 is substituted for o2 then S
is a subtype of T.
 Modules that use references to base types must
be able to use references to derived types
without knowing the difference

14. LSP
 Derived classes must fully substitute base class
 Violating LSP may break OCP

15. Dependency Inversion Principle (DIP)
 Depends upon abstract, not upon concrete classes
 No variable should hold a reference to a concrete class
 No class should derive from a concrete class
 No method should override an implemented method of its base class
(if it is something that can be changed, separate it into its own class).
 High-level modules should not depend on low-level modules.

16. DIP Summary
 Use DI to avoid:
 deriving from concrete classes
 associating to or aggregating concrete classes
 dependency on concrete components

17. Single Responsibility Principle
 There should never be more than one reason for
a class to change.
 Plan your classes based on what is likely to
change. If there is more than one thing that may
change, split the class until there is only one
thing likely to change in each class.

18. Interface Segregation Principle
 Some classes with good informational cohesion
support many services/operations
 Most clients only need subset of services; this
is like “tramp data!”
 So, split class interface into multiple interfaces
such that most clients use all the operations
they see, and don’t see operations they don’t
need

19. ISP
 When a class (Server) collects interfaces for various
purposes (Clients)
 Use separate interfaces to hide parts of the Server interface for
Clients
 Similar to data hiding
 Or split the Server in several parts