principles of object oriented class design

What do you mean by a good class
design??

Good class design
• Represents any real world entity

• Better code readability/ understanding

• Loosely coupled with other classes

• Compact & Optimized

• Easily testable

Single Responsibility Principle (SRP)

• One responsibility.

• One, and only one, reason to change.

• Change in the class should not force
programmers to change into other classes.

• BankAccount class- Example

Single Responsibility Principle (SRP) - Example

Class BankAccount{
private double bal; //setters & getters
public String getCurrentBalanceInRupees (){…}
public String getCurrentBalanceInUSD(){…}
public double getBalance(){
//return balance in round figures upto 2 decimals}
public double debit (double amount){…}
//how to handle diff.currency addition
public double credit (double amount){…}
//so on
}

Single Responsibility Principle (SRP)-Responsibility

• Responsibility of Bank Account class
▫ Currency conversion
▫ Checking currency for addition & subtraction
▫ Rounding-off the balance
▫ Debit the amount
▫ Credit the amount
▫ Details of account holder
▫ Transaction history
▫ //so on…

Single Responsibility Principle (SRP) - Solution

Class Money{
private double value;
private String currencyType; //setters & getters
public double getValue (){
//convert money value according to currencyType
// class currency converter
//round-off value upto 2 decimals
}
public double addMoney(Money amount){…}
public double subtractMoney(Money amount){…}
}

Single Responsibility Principle (SRP) - Solution

Class BankAccount{
private Money balance; //setters & getters
public double getBalance (){…}
public double debit (Money amount){
//call balance.addMoney(amount)…}
public double credit (Money amount){
//call balance.subtractMoney(amount)…}
}

Single Responsibility Principle (SRP)-Responsibility

• Responsibility division for BankAccount class
▫ CurrencyConverter Class – Currency conversion
▫ Money Class – Check currency for addition or
subtraction
▫ BankAccount class – Debit/Credit the amount
▫ Details of account holder – Person class
▫ Transaction history – TransactionHistory class
▫ //so on…

Single Responsibility Principle (SRP)

• Any Questions on SRP???

So, What is Single Responsibility Principle (SRP)?

Open Closed Principle (OCP)
• Open for Extension and closed for Modification.

• Don’t change existing code or classes.

• Add new functionality by adding new subclasses or
methods, or by reusing existing code through delegation.

Advantage:
• Prevents you from introducing new bugs in existing
code.

Open Closed Principle (OCP) - Example
Polymorphism for conforming to the OCP:

void LogOn (Modem m, string user, string pw)
{
if (m instanceOf Hayes)
DialHayes((Hayes)m, user);

else if (m instanceOf courrier)
DialCourrier((Courrier)m, user);

else if (m instanceOf ernie)
DialErnie((Ernie)m, user)
// ...so on
}

Consider the class design something like this:

Here LogOn has been closed for modification.

Abstract Class Modem{
Void Dial(String s);
Void send(Char c);
Char recv();
Void HangUp();
Void LogOn(Modem m, string user, string pw)) {
m.Dial();
}
}

Here LogOn method conforms to the OCP. Its behavior can be
extended without modifying it.


Goals of OCP:

• Create modules that are extensible, without being
changed.

• Use Unit tests if you are adding in the existing code


Any questions??

So, What is Open Closed Principle (OCP)??

Liskov Substitution Principle (LSP)

The LSP applies to inheritance hierarchies.

• It specifies that you should design your classes so that client
dependencies can be substituted with subclasses.
• All subclasses must, therefore, operate the same manner as their
base classes.
• The specific functionality of the subclass may be different but must
conform to the expected behavior of the base class.
• To be a true behavioral subtype, the subclass must not only
implement the base class' methods and properties but also conform
to its implied behavior.

It helps to get answers of following questions:

• Provides the design rules that govern the particular use
of inheritance.

• Characteristics of the best inheritance hierarchies

Liskov Substitution Principle (LSP) - Definition
• If for each object o1 of type S
S o1 = new S();

and,

there is an object o2 of type T
T o2 = new 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.

• Subtypes must be substitutable for their base types.

• In simpler version,
▫ Functions that use pointers or references to base classes
must be able to use objects of derived classes without
knowing it.

The canonical example is the Rectangle/Square dilemma.

Class Rectangle{
int length, breadth;
void setLength(){…}
void setBreadth(){…}
}
Class Square extends Rectangle{
void setLength(int a){ // similarly for setBreadth
Super.setLength(a);
Super.setBreadth(a);
}
}


Consider the following function:

void func(Rectangle r){
r.SetLength(20);
r.SetBreadth(32);
}

• Ugly fix for LSP violation for Rectangle & Square

void f(Shape shape){
If(shape instanceOf Rectangle){
//call funcForRectangle();
} else {
//call funcForSquare();
}
}
which rule is violating here??

Thus, violations of LSP are latent violations of OCP.

Why is the LSP important?

• Because if not, then class hierarchies would be a
mess.
▫ Mess being that whenever a subclass instance was
passed as parameter to any method, strange
behavior would occur.

• It provides the design rules that govern the particular
use of inheritance, and Characteristics of the best
inheritance hierarchies


• Any Questions on LSP???

So, What is Liskov Substitution Principle (LSP)??

Interface Segregation Principle (ISP)

• Many client specific interfaces are better than one
general purpose interface.

• The clients should not be forced to implement interfaces
they don't use.
▫ Instead of one fat interface many small interfaces are
preferred based on groups of methods, each one serving one
sub-module.

The methods needed by each client are placed in single interface that are
specific to the client.

Fat Service with Integrated Interfaces

The methods needed by each client are placed in special interfaces that are
specific to that client.

Segregated Interfaces


How would you handle if two clients have some common
methods?

Something like:

Client A – method1, method2, method3, method4
&
Client B – method1 , method2, method5, method6

Interface Segregation Principle (ISP) - Example

• Manager class – Represent the person which manages the workers.

• 2 types of workers – They can work & need daily lunch break to eat.
▫ some average, and
▫ some very efficient workers.

• But now some robots came in the company they work as well , but
they don't eat so they don't need a lunch break.

• One on side the new Robot class need to implement the IWorker
interface (work() & eat()) because robot works. On the other side,
the don't have to implement it because they don't eat.


// interface segregation principle - bad example

interface IWorker {
public void work();
public void eat();
}
class Worker implements IWorker{
public void work() {
// ....working
}
public void eat() {
// ...... eating in lunch break
}
}


class SuperWorker implements IWorker{
public void work() { //.... working much more}
public void eat() { //.... eating in lunch break}
}

class Manager {
IWorker worker;
public void setWorker(IWorker w) {
worker=w;
}
public void manage() {
worker.work();
}
}

Interface Segregation Principle (ISP) - Solution

// interface segregation principle - good example

interface IWorkable {
public void work();
}

interface IEatable{
public void eat();
}


class Worker implements IWorkable, IEatable{
public void work() {
// ....working
}
public void eat() {
// ...... eating in launch break
}
}

class SuperWorker implements IWorkable, IEatable{
public void work() { //.... working much more}
public void eat() { //.... eating in launch break}
}


class Robot implements IWorkable {
public void work() { //.... working}
}

class Manager {
IWorkable worker;
public void setWorker(IWorkable w) {
worker=w;
}
public void manage() {
worker.work();
}
}


Any Questions??

So, What is Interface Segregation Principle (ISP)?

Dependency Inversion Principle (DIP)

• Depend upon Abstractions. Do not depend upon
concretions.

• In other words, it is the strategy of depending upon
interfaces or abstract functions & classes, rather than
upon concrete functions & classes.

• High level modules should not depend upon low-level
modules. Both should depend upon abstractions.

Dependency Inversion Principle (DIP) - Example

Example: ATM & Bank Account

Class ATM{
private BankAccount ba = new BankAccount();
public String displayBalance(){
return “ Your balance is: ” + ba.currentBalance();
}
}

Dependency Inversion Principle (DIP) - Example

Class BankAccount{
private Double bal; //setters & getters
public String currentBalance (){
return bal.toString();
}
}

Dependency Inversion Principle (DIP) - Solution

Solution: Use Interfaces

Because the dependency of one class to another one
should depend on the smallest possible interface.


1) BankAccount Interface
Public Interface BankAccount{
public String currentBalance ();
}

2) StubBankAccount class
Class StubBankAccount implements BankAccount{
return “3000”;
}
}


3) Implementation of BankAccount class

Class BankAccountImpl implements BankAccount
{
Your balance is: ” + ba.currentBalance();
}
}


4) Class ATM{

private BankAccount ba;
ATM(BankAccount ba){
this.ba = ba;
}
public String displayBalance(){
return “ Your balance is: ” + ba.currentBalance();
}
}


5) Class ATMTest{

@Test
public void shouldDisplayTheBalance(){
StubBankAccount sba = new StubBankAccount();
ATM atm = new ATM(sba);
assertEquals( “ Your balance is: 3000”,
atm.displaybalance());
}
}


5) Class SomeClassUsingATM{

BankAccountImpl ba = new BankAccountImpl();
ATM atm = new ATM(ba);
sopln (atm.displayBalance());

}

• What Inversion means in DIP??
▫ It is primarily about reversing the conventional direction
of dependencies from "higher level" components to "lower
level" components such that "lower level" components are
dependent upon the interfaces owned by the "higher level"
components.

Dependency Inversion Principle (DIP) - Advantage

• Choose which implementation is better suited for your
particular environment
• Either at compile time in the application, or
• At the runtime by configuration.

• Simplifies the unit testing.

• Loosely coupled design.

Inversion Of Control (IOC)

• Inversion of Control is a design pattern where an Objects
gets handed its dependency by an outside framework,
rather than asking a framework for its dependency.

• The benefits of IoC are:
▫ You have no dependency on a central framework, so this
can be changed if desired.
▫ Since objects are created by injection, preferably using
interfaces, it's easy to create unit tests that replace
dependencies with mock versions.
▫ Decoupling off code.

Inversion Of Control (IOC)

• The "inversion" in DIP is not the same as in Inversion of
Control.
▫ The first one is about compile-time dependencies,
while the second one is about the flow of control between
methods at runtime.


• Any Questions on DIP???

So, What is Dependency Inversion Principle (DIP)?

Summary
Principles of class design (aka SOLID):

• Single Responsibility Principle (SRP)
▫ Create as many classes you want but
 They should follow some real world entity
 And have single responsibility
• Open Closed Principle (OCP)
▫ Open for Extension, Closed for Modification

Summary

• Liskov Substitution Principle (LSP)
▫ Object of derived class can be passed instead of
object of base class without changing the behavior
of program.
• Interface Segregation Principle (ISP)
▫ Create multiple client specific interface rather
than creating single interface for multiple clients.

Summary

• Dependency Inversion Principle (DIP)
▫ It is the strategy of depending upon interfaces or abstract
functions and classes, rather than upon concrete functions
and classes

Bibliography
• http://
www.objectmentor.com/omSolutions/oops_what.htm

• http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedD

principles of object oriented class design

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to principles of object oriented class design

Similar to principles of object oriented class design (20)

Recently uploaded

Recently uploaded (20)

principles of object oriented class design