Scribd
Upload
62 views

Principles of Object-Oriented Design

The document discusses principles of object-oriented design including the SOLID principles: single responsibility, open-closed, Liskov substitution, interface segregation, and dependency inversion. It provides examples to illustrate each principle and how they can be applied to create software designs that are maintainable and extensible over time.

Uploaded by

Ranjith
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
62 views

Principles of Object-Oriented Design

The document discusses principles of object-oriented design including the SOLID principles: single responsibility, open-closed, Liskov substitution, interface segregation, and dependency inversion. It provides examples to illustrate each principle and how they can be applied to create software designs that are maintainable and extensible over time.

Uploaded by

Ranjith
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Principles of Object-Oriented Design

As a part of an overall strategy of agile and adaptive


programming, a number of object-
oriented design principles were
proposed for the design and programming of computer
software
system that is easy to maintain and extend over time. These
principles are guidelines
intended for programmers to apply while
working on software to remove "code smells"
(potentially buggy
code) by refactorizing the source code until it is both legible
and extensible.
In this page, we introduce the SOLID
principles, that is, Single responsibility, Open-closed,
Liskov
substitution, Interface segregation and Dependency inversion. The
following
information was integrated from various sources on the
Web.

Single Responsibility Principle (SRP)

The SRP requires that a class should have only a single


responsibility.

Example: If a class SalesOrder


keeps information about a sales order, and in addition has a
method saveOrder() that saves the SaleOrder
in a database and a method exportXML() that
exports the SalesOrder in XML format, this design
will violate the SRP because there will be
different types of
users of this class and different reasons for making changes to
this class. A
change made for one type of user, say change the
type of database, may require the re-test,
recompilation, and
re-linking of the class for the other type of users.

A better design will be to have the SalesOrder


class only keeps the information about a sales
order, and have
different classes to save order and to export order, respectively.
Such a design
will confirm to SRP.

Open-Closed Principle (OCP)

The OCP requires that each software entity should be open for
extension, but closed for
modification.

Example: Suppose an OrderValidation


class has a method validate(Order order) that is
programmed to validate an order based on a set of hard-coded
rules. This design violates the
OCP because if the rules
change,  the OrderValidation class has to be
modified, tested, and
compiled.

A better design will be to let the OrderValidation


class  contain a collection of ValidationRule
objects each of which has a validate(Order
order) method (perhaps defined in a Validation
interface) to validate an Order using a specific
rule, and the validate(Order order) method of
OrderValidation class 
can
simply iterate through those ValidationRule objects
to validate the
order. The new design will satisfy the OCP,
because if the rules change,  we can just create a
new ValidationRule
object and add it to an OrderValidation instance at
run time (rather than to
the class definition itself).

This is can also be achieved by using  subclasses of a base


class AbstractValidationRule that has
an
override-able function validate(Order order).
Subclasses can implement the method
differently without changing
the base class functionality.

Liskov Substitution Principle (LSP)


The LSP requires that objects in a program should be replaceable
with instances of their
subclasses without altering the
correctness of that program.

The users must be able to use objects of subclasses via


references to base classes without
noticing any difference. When
using an object through its base class interface, the object of a
subclass must not expect the user to obey preconditions that are
stronger than those required
by the base class.

Example: Suppose a Rectangle


class has two instance variables height and width,
and a method
setSize(int a, int b), which set height
to a and width to b.
Suppose Square is a subclass of
Rectangle
and it overrides the inherited method by setting both height
and width to a. This
design will
violate LSP. To see this, consider a client uses a reference
variable of type Rectangle
to call the setSize()
method to assign different values of a and b,
and then immediately verify
if the sizes were set correctly or the
area is correctly computed. The results will be different if
the
variable references to a Rectangle object than to a
Square object.  

It turns out that in OO programming, a Square


is not a Rectangle at all because it
behaves
differently from a Rectangle.

Interface Segregation Principle (ISP)

The ISP requires that clients should not be forced to depend on


interfaces that they do not use.

Example: Suppose a Vehicle interface


shown in the figure is designed for clients to use

This violates ISP because clients are forced to depend on methods


they do not use: HighWay does
not use stopRadio()
or ejectCD(), and ParkingLot does not
need accelerate() or ejectCD().

A better design is to design smaller interfaces for different types


of clients as shown in the
following figure

Dependency Inversion Principle (DIP)

The DIP requires that high level modules should not depend on low
level modules, both should
depend on abstraction. Also,
abstraction should not depend on details, details should depend
on
abstractions.

Example: Making a class Button


associate to another class Lamp (because a Lamp
has a Button) is a
violation of DIP. A better design
will be associate an AbstractButton with an
AbstractButtonClient,
and define Button as a subclass of the AbstractButton and a Lamp a
subclass of the AbstractButtonClient.

Example: Making an EBookReader


class to use PDFBook class is a violation of DIP
because it
requires to change the EBookReader class
to read other types of e-books. A better design is to let
EBookReader 
use an interface EBook and let PDFBook
and other types of e-book classes implement
EBook.
Now adding or changing e-book classes will not require any change
to EBookReader class.

You might also like