CSC/ECE 517 Fall 2007/wiki3 4 sa: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(10 intermediate revisions by 2 users not shown)
Line 2: Line 2:


= Introduction =
= Introduction =
All the basic design principles converge on the use of abstraction for incorporating flexibility using loose coupling behaviour. Interface Segregation Principle (ISP) is a guideline for designing different interfaces.The Interface-Segregation Principle focuses on the cohesiveness of interfaces with respect to the clients that use them.
All the basic design principles converge on the use of abstraction for incorporating flexibility using loose coupling behavior. The Interface Segregation Principle (ISP) provides guidelines for designing interfaces to classes that must provide different services to different clients. The Interface Segregation Principle focuses on the cohesiveness of interfaces with respect to the clients that use them.


= Definition =
= Definition =
ISP was originally presented in a paper by Robert C. Martin in his ''Engineering Notebook'' column for the ''C++ Report''. The paper is still available at the Object Mentor website [http://www.objectmentor.com/resources/articles/isp.pdf (ISP)].


The essence of Integration Segregation Principle is that  
The essence of Integration Segregation Principle is that  
<b>"Clients should not be forced to depend upon interfaces that they don’t use."</b>
<b>"Clients should not be forced to depend upon interfaces that they don’t use."</b>


Some other definitions of ISP are<br>
Some other definitions of ISP are:
"Many client specific interfaces are better than one general purpose interface"<br>
:"Many client specific interfaces are better than one general purpose interface"
"The dependency of one class to another one should depend on the smallest possible interface"<br>
:"The dependency of one class to another one should depend on the smallest possible interface"
"Make fine grained interfaces that are client specific."<br>
:"Make fine grained interfaces that are client specific."
 
While it can be argued that having a class that has many interfaces violates the Single Responsibility Principle [http://www.objectmentor.com/resources/articles/srp.pdf SRP], there are many instances where having a class implementing different interfaces makes sense, e.g., a graphics class might need to be rendered to screen or serialized to a file.
 
= Examples =
 
The following two examples are taken from Martin's paper, but have been ported to Java.
 
== Security system ==
 
Suppose you have a security system that has Door objects:
 
<pre>
interface Door {
  public void Lock();
  public void Unlock();
  public boolean IsDoorOpen();
};
</pre>
 
Now suppose you have a TimedDoor which needs to sound an Alarm when the door has been left open for too long. To implement this functionality the TimerDoor object communicates with a Timer object:
 
<pre>
public class Timer
{
  ...
  public void Register(int timeout, TimerClient* client) {
  ...
  }
  ...
};
 
interface TimerClient
{
  public void TimeOut();
};
</pre>
 
We might be tempted to do the following:
 
<pre>
interface Door extends TimerClient {
  public void Lock();
  public void Unlock();
  public boolean IsDoorOpen();
};
 
class TimedDoor implements Door {
...
}
</pre>
 
The Door interface has been polluted with the Timer interface in order to provide the Timer interface to TimedDoor and all Door clients now also depend on TimerClient. To void this we can do the following instead:
 
<pre>
// Unchanged from first listing
interface Door {
  public void Lock();
  public void Unlock();
  public boolean IsDoorOpen();
};
 
class TimedDoor implements Door, TimerClient {
...
}
</pre>
 
This conforms to ISP by providing the required separate interfaces.
 
== ATM System ==
 
Consider an ATM that needs to be very flexible and support screen, braille tablet and speech synthesizer user interfaces. We can abstract the main operations and use an interface which would be implemented by specific UI classes:
 
<pre>
interface ATM_UI {
  void deposit(double amt, double account);
  void withdraw(double amt, double account);
  void transfer(double amt, double fromAccount, double toAccount);
}
 
public class BrailleUI implements ATM_UI {
  ...
}
 
public class ScreenUI implements ATM_UI {
  ...
}
 
public class SpeechUI implements ATM_UI {
  ...
}
</pre>
 
Now consider also that each different transaction the ATM can perform are encapsulated in a Transaction object:
 
<pre>
interface Transaction {
  void execute();
}
 
class DepositTransaction implements Transaction {
  void execute() {
    atm.deposit(amt, acct);
  }
}
 
class WithdrawalTransaction implements Transaction {
  void execute() {
    atm.withdraw(amt, acct);
  }
}
 
class TransferTransaction implements Transaction {
  void execute() {
    atm.withdraw(amt, fromAcct, toAcct);
  }
}
</pre>
 
Notice that this is precisely the situation that the ISP tells us to avoid. Each of the transactions is using a portion of the UI that no other object uses. This creates the possibility that changes to one of the derivatives of Transaction will force corresponding change to the UI, thereby affecting all the other derivatives of Transaction, and every other class that depends upon the UI interface. To fix the problem we can do the following instead:
 
<pre>
interface DepositUI {
  void deposit(double amt, double account);
}
 
interface WithdrawalUI {
  void withdraw(double amt, double account);
}
 
interface TransferUI {
  void transfer(double amt, double fromAccount, double toAccount);
}
 
interface ATM_UI extends DepositUI, WithdrawalUI, TransferUI {
  ...
}
</pre>


And have the individual Transaction objects only reference the needed interfaces.


=Examples=
= Web Resources =
 
The best specific examples in our opinion are the ones found on the original paper by Martin. This, we consider as the best one because it provides a comprehensive treatment with easy to understand examples. Also, this being the original paper, presents the topic with  good understandable examples in detail. Thus we consider it ideal to present this in the class
The original paper [http://www.objectmentor.com/resources/articles/isp.pdf (ISP)], has two examples in C++ and an early version of UML. These examples use C++'s multiple inheritance due to the lack of real interfaces in the language. Each interface is defined using an abstract class with pure virtual methods. Even when these examples are very good, the use of C++ and the old version of UML might make it harder for people used to languages with support for real interfaces like Java or C# to understand them. We have tried to address these concerns by reimplementing Martin's examples in Java above. While doing so we could also see how Java encourages ISP with its support of interfaces.
 
The ISP page at Doodle Project [http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html] has an example in modern UML. The example illustrates how adding new functionality to an existing system might force us to apply ISP to accommodate future changes.
 
A Java Boutique page [http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html] is available with a very concise and clear example in UML. The example shows how a violation of ISP might manifests itself as one having to provide null implementations for methods from the "fat" interface.
[http://ifacethoughts.net/2006/03/28/interface-segregation-principle/] contains an interesting example because it relates to real-world objects, in this case a cell phone. Modern phones support lots of other functions besides handling phone calls like having mp3 player, video player, camera and each of these functions is handled through different interfaces.ISP advises to keep these interfaces completely independent of each other.
 
The Object Mentor website also provides a paper with a number of design principles summarized, including ISP [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF]. The advantage of said paper is that the other principles are easily accessible and a designer can compare for advantages and trade-off where multiple principles may be applied.
 
The extensive use of interfaces in the Java API libraries is an excellent example of ISP because it provides flexibility and extensibility.
 
A brief easy to understand article is provided in [http://www.everything2.com/index.pl?node_id=1259576].
 
Another interesting and easy to understand example (about Robots who are workers) is provided in [http://www.oodesign.com/oo_principles/oo_principles/interface_sergregation_principle.html].


Interfaces are useful in designing real world systems, where every object can have multiple aspects. This aspect can be a facet, a behaviour, a role - any entity that qualifies the object with that aspect. Lets take a real world example - a modern cell phone (mobile) acts more than just a phone, it is a phone, a MP3 player and a video player. When I am using it as a MP3 player, I will like to specify the song I want to play and listen to it, nothing more nothing else. When I am using it as a mobile phone, I will like to provide the number and speak, nothing more nothing else. I will get extremely irritated if I am asked for a phone number when I want to listen to a song. It is better if only the relevant questions are asked.
The cell phone had interfaces of a phone and a MP3 player. ISP advises to keep these two interfaces completely independent of each other. This way the phone can be treated purely as a phone or as a MP3 player. Programmatically, I can use only the interface of a MP3 player in my method called playSong. In future even if the interface for the phone is modified, playSong would remain the same.
=Conclusion=
=Conclusion=


Interface Segregation Principle's idea is to see that if there are two non-cohesive functionalities, keep them separate, so that they can be used independent of other. This avoids design of fat interfaces, and provides a clear design to the user (client). Break the functionalities into atomic interfaces that can be then individually accessed by the user.
Interface Segregation Principle's idea is to see that if there are two non-cohesive functionalities, keep them separate, so that they can be used independent of other. This avoids design of fat interfaces, and provides a clear design to the user (client). Break the functionalities into atomic interfaces that can be then individually accessed by the user.


= Resources =
= Further reading =


1) http://www.objectmentor.com/resources/articles/isp.pdf
[http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445/ref=pd_bbs_1?ie=UTF8&s=books&qid=1195404857&sr=8-1 Agile Software Development, Principles, Patterns, and Practices]
2) http://ifacethoughts.net/2006/03/28/interface-segregation-principle/
 
[http://www.amazon.com/Principles-Patterns-Practices-Robert-Martin/dp/0131857258/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1195404857&sr=8-2 Agile Principles, Patterns, and Practices in C#]
 
[http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign Principles Of Object Oriented Design]


[http://c2.com/cgi/wiki?MaskingInterfaces Masking Interfaces]


= Further reading =
[http://c2.com/cgi/wiki?RolePattern Role Pattern]


''Note: Santosh Gurijala (skgurija) and Agustin Vega-Frias (jvegafr) are the authors of this page.''
''Note: Santosh Gurijala (skgurija) and Agustin Vega-Frias (jvegafr) are the authors of this page.''

Latest revision as of 23:28, 28 November 2007

Take the Interface Segregation principle and catalog the information on it available on the Web. We didn't cover it in class, but you can look it up on the Web or in the ACM DL. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.

Introduction

All the basic design principles converge on the use of abstraction for incorporating flexibility using loose coupling behavior. The Interface Segregation Principle (ISP) provides guidelines for designing interfaces to classes that must provide different services to different clients. The Interface Segregation Principle focuses on the cohesiveness of interfaces with respect to the clients that use them.

Definition

ISP was originally presented in a paper by Robert C. Martin in his Engineering Notebook column for the C++ Report. The paper is still available at the Object Mentor website (ISP).

The essence of Integration Segregation Principle is that "Clients should not be forced to depend upon interfaces that they don’t use."

Some other definitions of ISP are:

"Many client specific interfaces are better than one general purpose interface"
"The dependency of one class to another one should depend on the smallest possible interface"
"Make fine grained interfaces that are client specific."

While it can be argued that having a class that has many interfaces violates the Single Responsibility Principle SRP, there are many instances where having a class implementing different interfaces makes sense, e.g., a graphics class might need to be rendered to screen or serialized to a file.

Examples

The following two examples are taken from Martin's paper, but have been ported to Java.

Security system

Suppose you have a security system that has Door objects:

interface Door {
  public void Lock();
  public void Unlock();
  public boolean IsDoorOpen();
};

Now suppose you have a TimedDoor which needs to sound an Alarm when the door has been left open for too long. To implement this functionality the TimerDoor object communicates with a Timer object:

public class Timer
{
  ...
  public void Register(int timeout, TimerClient* client) {
  ...
  }
  ...
};

interface TimerClient
{
  public void TimeOut();
};

We might be tempted to do the following:

interface Door extends TimerClient {
  public void Lock();
  public void Unlock();
  public boolean IsDoorOpen();
};

class TimedDoor implements Door {
...
}

The Door interface has been polluted with the Timer interface in order to provide the Timer interface to TimedDoor and all Door clients now also depend on TimerClient. To void this we can do the following instead:

// Unchanged from first listing
interface Door {
  public void Lock();
  public void Unlock();
  public boolean IsDoorOpen();
};

class TimedDoor implements Door, TimerClient {
...
}

This conforms to ISP by providing the required separate interfaces.

ATM System

Consider an ATM that needs to be very flexible and support screen, braille tablet and speech synthesizer user interfaces. We can abstract the main operations and use an interface which would be implemented by specific UI classes:

interface ATM_UI {
  void deposit(double amt, double account);
  void withdraw(double amt, double account);
  void transfer(double amt, double fromAccount, double toAccount);
}

public class BrailleUI implements ATM_UI {
  ...
}

public class ScreenUI implements ATM_UI {
  ...
}

public class SpeechUI implements ATM_UI {
  ...
}

Now consider also that each different transaction the ATM can perform are encapsulated in a Transaction object:

interface Transaction {
  void execute();
}

class DepositTransaction implements Transaction {
  void execute() {
    atm.deposit(amt, acct);
  }
}

class WithdrawalTransaction implements Transaction {
  void execute() {
    atm.withdraw(amt, acct);
  }
}

class TransferTransaction implements Transaction {
  void execute() {
    atm.withdraw(amt, fromAcct, toAcct);
  }
}

Notice that this is precisely the situation that the ISP tells us to avoid. Each of the transactions is using a portion of the UI that no other object uses. This creates the possibility that changes to one of the derivatives of Transaction will force corresponding change to the UI, thereby affecting all the other derivatives of Transaction, and every other class that depends upon the UI interface. To fix the problem we can do the following instead:

interface DepositUI {
  void deposit(double amt, double account);
}

interface WithdrawalUI {
  void withdraw(double amt, double account);
}

interface TransferUI {
  void transfer(double amt, double fromAccount, double toAccount);
}

interface ATM_UI extends DepositUI, WithdrawalUI, TransferUI {
  ...
}

And have the individual Transaction objects only reference the needed interfaces.

Web Resources

The best specific examples in our opinion are the ones found on the original paper by Martin. This, we consider as the best one because it provides a comprehensive treatment with easy to understand examples. Also, this being the original paper, presents the topic with good understandable examples in detail. Thus we consider it ideal to present this in the class The original paper (ISP), has two examples in C++ and an early version of UML. These examples use C++'s multiple inheritance due to the lack of real interfaces in the language. Each interface is defined using an abstract class with pure virtual methods. Even when these examples are very good, the use of C++ and the old version of UML might make it harder for people used to languages with support for real interfaces like Java or C# to understand them. We have tried to address these concerns by reimplementing Martin's examples in Java above. While doing so we could also see how Java encourages ISP with its support of interfaces.

The ISP page at Doodle Project [1] has an example in modern UML. The example illustrates how adding new functionality to an existing system might force us to apply ISP to accommodate future changes.

A Java Boutique page [2] is available with a very concise and clear example in UML. The example shows how a violation of ISP might manifests itself as one having to provide null implementations for methods from the "fat" interface.

[3] contains an interesting example because it relates to real-world objects, in this case a cell phone. Modern phones support lots of other functions besides handling phone calls like having mp3 player, video player, camera and each of these functions is handled through different interfaces.ISP advises to keep these interfaces completely independent of each other.

The Object Mentor website also provides a paper with a number of design principles summarized, including ISP [4]. The advantage of said paper is that the other principles are easily accessible and a designer can compare for advantages and trade-off where multiple principles may be applied.

The extensive use of interfaces in the Java API libraries is an excellent example of ISP because it provides flexibility and extensibility.

A brief easy to understand article is provided in [5].

Another interesting and easy to understand example (about Robots who are workers) is provided in [6].

Conclusion

Interface Segregation Principle's idea is to see that if there are two non-cohesive functionalities, keep them separate, so that they can be used independent of other. This avoids design of fat interfaces, and provides a clear design to the user (client). Break the functionalities into atomic interfaces that can be then individually accessed by the user.

Further reading

Agile Software Development, Principles, Patterns, and Practices

Agile Principles, Patterns, and Practices in C#

Principles Of Object Oriented Design

Masking Interfaces

Role Pattern

Note: Santosh Gurijala (skgurija) and Agustin Vega-Frias (jvegafr) are the authors of this page.