Week 13-DIP & ISP

The Dependency-Inversion Principle
&
Interface Segregation Principle
The DIP principle states that:
High-level modules should not depend on low- level modules.

Both should depend on abstractions.
Abstractions should not depend on details. Details should
depend on abstractions.
In Java applications, we tend to model abstractions using interfaces and

abstract classes.
Let’s get started with some code that violates that principle.
Say you are working as part of a software team. We need to
implement a project. For now, the software team consists of:
A BackEnd Developer A FrontEnd Developer

And our project uses both throughout
the development process:
So as we can see, the Project class is a high-level module, and it depends on low-level
modules such as BackEndDeveloper and FrontEndDeveloper. We are actually violating
the first part of the dependency inversion principle.
Also, by inspecting the implement function of Project class, we realize
that the methods writeJava and writeJavascript are methods bound to
the corresponding classes. Regarding the project scope, those are details
since, in both cases, they are forms of development. Thus, the second
part of the dependency inversion principle is violated.
In order to tackle this problem, we shall implement an
interface called the Developer interface:
Therefore, we introduce an
abstraction.
The BackEndDeveloper shall be refactored to:
And the FrontEndDeveloper shall be refactored to:
The next step, in order to tackle the violation of the first part, would be to refactor the Project
class so that it will not depend on the FrontEndDeveloper and the BackendDeveloper classes.
Conclusion:
The outcome is that the Project class does not depend on
lower-level modules (FrontEndDeveloper and the
BackendDeveloper classes), but rather abstractions (interface
Developer).
Also, low-level modules and their details depend on
abstractions.
Example
You all must have played one of the popular games, Subway Surfers. There are different tour themes to choose from like
World Tours (New York City, Paris etc.), Film Tours (Madagascar, Despicable Me etc.). Now consider the following code:
Public class WorldTours {

Public void showWorldToursDescription() { }
}
Public class FilmTours {

Public void showFilmToursDescription() { }
}
And our Game class uses both in order to display all the available tour themes.
public class Game

{
private WorldTours wt = new WorldTours(); So as we can see, the Game class is a high-level module, and it
private FilmTours ft = new FilmTours(); depends on low-level modules such as WorldTours and
FilmTours classes. We are actually violating the dependency
public void display() { inversion principle. How will you tackle this problem? Correct
wt. showWorldToursDescription(); and re-write the code so that it does not violate this principle.
ft. showFilmToursDescription(); }
}
Interface Segregation Principle (ISP)
• The Interface Segregation Principle advocates for creating specific interfaces for
clients instead of general-purpose ones, preventing unnecessary dependencies and
ensuring that clients only depend on the methods they need.
• The Interface Segregation Principle states that clients should not be forced to
depend on methods they do not use.
• Interface should belong to clients, not to libraries or hierarchies.
• Following this principle makes you split large interfaces into specific ones that will
only show methods that are required for the clients.
Example:
Consider a large interface that is not cohesive and clients are forced to implement all
methods:
Refactoring with ISP:
interface Worker {
void work(); interface Workable {
void eat(); void work();
void takeBreak(); }
}
interface Eatable {
class Engineer implements Worker { void eat();
public void work() { }
// Code for working
} class Engineer implements Workable, Eatable {
public void work() {
public void eat() { // Code for working
// Code for eating }
}
public void eat() {
public void takeBreak() { // Code for eating
// Code for taking a break }
} // No longer forced to implement unnecessary methods
} }
The ISP helps in creating smaller and more focused interfaces, allowing clients to implement only the methods
they need, thus reducing unnecessary dependencies.
ISP CONTD…
Without ISP:
• In absence of ISP, you have one Generic large interface and many
classes implementing it.
• Assume that you had 1 interface and 50 classes. If there is a change in
interface, all 50 classes have to change their implementation
WITH ISP:
• You will divide generic interface into small interfaces.
• If there is a change in small interface, only the classes implementing
that interface will be affected.
• To make the code more readable and manageable.
EXAMPLE- VIOLATING ISP
SOLUTION

Week 13-DIP & ISP

Uploaded by

Copyright:

Available Formats

Week 13-DIP & ISP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Week 13-DIP & ISP

Uploaded by

Copyright:

Available Formats

The Dependency-Inversion Principle

High-level modules should not depend on low- level modules.

In Java applications, we tend to model abstractions using interfaces and

A BackEnd Developer A FrontEnd Developer

Public class WorldTours {

Public class FilmTours {

public class Game

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.