Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-16T13:52:26Z

Snateka: /* Example 4 */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

The full article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
'''Without ISP'''

Suppose that in your application you are required to write some Data Access Objects (DAO),which should support a variety of data sources. Let the two main data sources be file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements [[#References|10]].

[[Image:figure-3.gif]]

What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, it needs to be changed, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

'''With ISP'''

In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. Interfaces are the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle [[#References|10]].

[[Image:Figure-4.gif]]

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]
#[http://en.wikipedia.org/wiki/Interface_segregation_principle ISP Wiki]
#[http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html Database ISP Example]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-16T13:51:52Z

Snateka: /* Example 4 */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

The full article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
'''Without ISP'''

Suppose that in your application you are required to write some Data Access Objects (DAO),which should support a variety of data sources. Let the two main data sources be file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements [[#References|10]].

[[Image:figure-3.gif]]

What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, it needs to be changed, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

'''With ISP'''

In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. Interfaces are the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle.

[[Image:Figure-4.gif]]

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]
#[http://en.wikipedia.org/wiki/Interface_segregation_principle ISP Wiki]
#[http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html Database ISP Example]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-16T13:49:08Z

Snateka: /* References */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

The full article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
'''Without ISP'''

Suppose that in your application you are required to write some Data Access Objects (DAO),which should support a variety of data sources. Let the two main data sources be file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements.

[[Image:figure-3.gif]]

What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, it needs to be changed, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

'''With ISP'''

In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. Interfaces are the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle.

[[Image:Figure-4.gif]]

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]
#[http://en.wikipedia.org/wiki/Interface_segregation_principle ISP Wiki]
#[http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html Database ISP Example]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-16T01:39:14Z

Snateka: /* Origin */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

The full article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
'''Without ISP'''

Suppose that in your application you are required to write some Data Access Objects (DAO),which should support a variety of data sources. Let the two main data sources be file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements.

[[Image:figure-3.gif]]

What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, it needs to be changed, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

'''With ISP'''

In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. Interfaces are the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle.

[[Image:Figure-4.gif]]

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-16T01:38:21Z

Snateka: /* Example 4 */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
'''Without ISP'''

Suppose that in your application you are required to write some Data Access Objects (DAO),which should support a variety of data sources. Let the two main data sources be file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements.

[[Image:figure-3.gif]]

What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, it needs to be changed, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

'''With ISP'''

In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. Interfaces are the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle.

[[Image:Figure-4.gif]]

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-16T01:37:35Z

Snateka: /* Example 4 */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
'''Without ISP'''

Suppose that in your application you are required to write some Data Access Objects (DAO),which should support a variety of data sources. Let the two main data sources be file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements.

[[Image:figure-3.gif]]

What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, it needs to be changed, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

'''With ISP'''

In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. Interfaces are the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle.

[[Image:Figure-4.gif]]

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-16T01:31:20Z

Snateka: /* Examples */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
'''Without ISP'''

Suppose that in your application you are required to write some Data Access Objects (DAO),which should support a variety of data sources. Let the two main data sources be file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements.

[[Image:figure-3.gif]]

There's another aspect that needs be to considered. What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, we'll need to change it, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

'''With ISP'''

In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. The behaviors for both the data access operation, and the database access operation together in a single interface. This caused problems at a later stage in the development. Interfaces are the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle.

[[Image:Figure-4.gif]]

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-16T01:19:35Z

Snateka: /* Examples */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
'''Without ISP'''
Imagine that in your application you are required to write some Data Access Objects (DAO). These data objects should support a variety of data sources. Let's consider that the two main data sources are file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements.

[[Image:figure-3.gif]]

There's another aspect that needs be to considered. What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, we'll need to change it, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

'''With ISP'''

So, what went wrong? In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. We defined the behaviors for both the data access operation, and the database access operation together in a single interface. This caused problems at a later stage in the development. It is not necessary to be a guru in Object Oriented System Design, to solve this problem nor is vast experience in designing software applications needed. What is necessary is to think of interfaces as the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

When a single interface is designed to support different groups of behaviors, they are, by virtue, inherently poorly designed, and are called Fat interfaces. They are called Fat because they grow enormously with each additional function required by clients using that interface.

Thus, for the problem with the Data Access Objects, follow the Interface Segregation Principle, and separate the interfaces based on the behaviors. The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle (Figure 4).

[[Image:Figure-4.gif]]

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-15T20:18:33Z

Snateka: /* Example 4 */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
Imagine that in your application you are required to write some Data Access Objects (DAO). These data objects should support a variety of data sources. Let's consider that the two main data sources are file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements.

[[Image:figure-3.gif]]

There's another aspect that needs be to considered. What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, we'll need to change it, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

So, what went wrong? In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. We defined the behaviors for both the data access operation, and the database access operation together in a single interface. This caused problems at a later stage in the development. It is not necessary to be a guru in Object Oriented System Design, to solve this problem nor is vast experience in designing software applications needed. What is necessary is to think of interfaces as the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

When a single interface is designed to support different groups of behaviors, they are, by virtue, inherently poorly designed, and are called Fat interfaces. They are called Fat because they grow enormously with each additional function required by clients using that interface.

Thus, for the problem with the Data Access Objects, follow the Interface Segregation Principle, and separate the interfaces based on the behaviors. The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle (Figure 4).

[[Image:Figure-4.gif]]

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

File:Figure-4.gif

2010-11-15T20:18:02Z

Snateka:

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-15T20:17:07Z

Snateka: /* Example 4 */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
Imagine that in your application you are required to write some Data Access Objects (DAO). These data objects should support a variety of data sources. Let's consider that the two main data sources are file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements.

[[Image:figure-3.gif]]

There's another aspect that needs be to considered. What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, we'll need to change it, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

So, what went wrong? In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. We defined the behaviors for both the data access operation, and the database access operation together in a single interface. This caused problems at a later stage in the development. It is not necessary to be a guru in Object Oriented System Design, to solve this problem nor is vast experience in designing software applications needed. What is necessary is to think of interfaces as the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

When a single interface is designed to support different groups of behaviors, they are, by virtue, inherently poorly designed, and are called Fat interfaces. They are called Fat because they grow enormously with each additional function required by clients using that interface.

Thus, for the problem with the Data Access Objects, follow the Interface Segregation Principle, and separate the interfaces based on the behaviors. The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle (Figure 4).

[[Image:Figure-4.jpg]]

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-15T20:15:07Z

Snateka: /* Example 2 */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 4==
Imagine that in your application you are required to write some Data Access Objects (DAO). These data objects should support a variety of data sources. Let's consider that the two main data sources are file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements.

[[Image:figure-3.gif]]

There's another aspect that needs be to considered. What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, we'll need to change it, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

So, what went wrong? In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. We defined the behaviors for both the data access operation, and the database access operation together in a single interface. This caused problems at a later stage in the development. It is not necessary to be a guru in Object Oriented System Design, to solve this problem nor is vast experience in designing software applications needed. What is necessary is to think of interfaces as the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

When a single interface is designed to support different groups of behaviors, they are, by virtue, inherently poorly designed, and are called Fat interfaces. They are called Fat because they grow enormously with each additional function required by clients using that interface.

Thus, for the problem with the Data Access Objects, follow the Interface Segregation Principle, and separate the interfaces based on the behaviors. The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle (Figure 4).

Figure 4: The final DAO class hierarchy

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

File:Figure-3.gif

2010-11-15T20:13:34Z

Snateka:

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-15T20:12:53Z

Snateka: /* Examples */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

==Example 2==
Imagine that in your application you are required to write some Data Access Objects (DAO). These data objects should support a variety of data sources. Let's consider that the two main data sources are file and database. You must be careful enough to come up with an interface-based design, where the implementation of data access can be varied without affecting the client code using your DAO object. The following design is a good example of the above requirements

[[Image:figure-3.gif]]

There's another aspect that needs be to considered. What happens if the data source is read-only? The methods for inserting and updating data are not needed. On the other hand, if the DAO object should implement the DAO interface, it will have to provide a null implementation for those methods defined in the interface. This is still acceptable, but the design is gradually going wrong. What if there is a need to rotate the file data source to a different file once a certain amount of data has been written to the file? That will require a separate method to add to the DAO interface. This is just to add the flexibility to the clients using this FileDAO object to enable them to choose either the normal append feature to the file data source or to make use of the improved file rotation feature.

With the DatabaseDAO implementation now broken, we'll need to change it, to provide a null implementation of the new method added to the interface. This is against the Open-Closed Principle.

So, what went wrong? In the basic design, the fact that the file data access operation and database access operation can differ fundamentally must be considered. We defined the behaviors for both the data access operation, and the database access operation together in a single interface. This caused problems at a later stage in the development. It is not necessary to be a guru in Object Oriented System Design, to solve this problem nor is vast experience in designing software applications needed. What is necessary is to think of interfaces as the behaviors to be provided through particular objects. If two or more objects implementing the interface depict different sets of behaviors, then they probably cannot subscribe to a single interface.

When a single interface is designed to support different groups of behaviors, they are, by virtue, inherently poorly designed, and are called Fat interfaces. They are called Fat because they grow enormously with each additional function required by clients using that interface.

Thus, for the problem with the Data Access Objects, follow the Interface Segregation Principle, and separate the interfaces based on the behaviors. The database access classes and file access classes should subscribe to two separate interfaces. The following design is obtained by applying the Interface Segregation Principle (Figure 4).

Figure 4: The final DAO class hierarchy

With this design, the Fat interface symptom is avoided and the interfaces clearly delineate their intended purpose. If any imaginary data access object requires a combination of operations defined in both of these interfaces, they will be able to do so by implementing both the interfaces.

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-15T19:28:38Z

Snateka: /* Definition */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP helps a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-15T18:23:40Z

Snateka: /* Origin */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP will help a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. The clients, for example, staple job, were being forced to depend on methods specific to other clients, like print job, that they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested the addition of a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-15T18:04:11Z

Snateka: /* Introduction */

=Definition=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP will help a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. This meant that a staple job would know about all the methods of the print job, even though the staple class had no use for them. The clients were being forced to depend on methods they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested that they add a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-15T18:01:36Z

Snateka: /* Origin */

=Introduction=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP will help a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. This meant that a staple job would know about all the methods of the print job, even though the staple class had no use for them. The clients were being forced to depend on methods they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested that they add a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found [http://en.wikipedia.org/wiki/Interface_segregation_principle here.]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch6 6f AZ

2010-11-15T17:59:14Z

Snateka: /* Origin */

=Introduction=
'''Interface Segregation Principle(ISP)''' states that "'''''Clients should not be forced to depend upon interfaces that they do not use'''''". Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.

If followed, the ISP will help a system stay decoupled and thus easier to refactor, change, and redeploy. It is one of the 5 principles of Object-Oriented Programming called [http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID]. This helps in low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling] and high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion].

=Origin=
The ISP was first used and formulated by Robert C. Martin when he was doing some consulting for Xerox. Xerox had created a new printer system which could perform a variety of tasks such as stapling a set of printed papers, faxing, and so forth. The software for this system was created from the ground up and performed its tasks successfully, but as the software grew it became harder and harder to change. Each time a change, even the smallest of changes, was made it could take nearly an hour to recompile and redeploy. This was a major hindrance to further development.

The issue with their code was that there was one main Job class that was used by almost all of the tasks. This meant that the Job class was getting huge or 'fat', with of tons of different methods which were specific to a variety of different clients. This meant that a staple job would know about all the methods of the print job, even though the staple class had no use for them. The clients were being forced to depend on methods they did not use.

The solution suggested by Robert has now become the Interface Segregation Principle. He suggested that they add a layer of interfaces to sit between the Job class and all of its clients. Instead of having just one 'fat' Job class that all the tasks used, there would be a Staple Job interface or a Print Job interface that would be used by the Staple class or Print class, respectively, and would call methods of the Job class. This segregation of interfaces vastly decoupled the software allowing the clients like the Staple class to only depend on the methods it cared about.

This article can be found here.[http://en.wikipedia.org/wiki/Interface_segregation_principle]

=Motivation=
When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application by adding another module that contains only some of the submodules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named as a ‘fat’ interface or ‘polluted’ interface. Having a polluted interface is not a good solution and might induce inappropriate behavior in the system [[#References|6]].
==Need for ISP==
Listed below are the problems caused when not using ISP, and how ISP helps solves these problem[[#References|4]]:
{| border="1" cellspacing="0" cellpadding="5" align="center"
! Without ISP
! With ISP
|-
| Some interfaces are created with huge amount of functionalities. But when those interfaces are implemented by client implementor classes, not required functionalities are forced to be implemented, and so the code will have many dummy or empty implementations.
| This situation can be prevented by segregating (i.e seperating) big interfaces into smaller ones. Only strictly related method definitions must be in the same interface. Different types of functionalities must be placed in different interfaces. This is ISP.
|-
| The larger a component gets, the larger will be its interface. This can not only make it harder to understand the purpose of a component, but it can also cause increased coupling, where by components that make use of such a component are exposed to more of that component’s capabilities that are appropriate.
| ISP aims to tackle this problem by breaking a component’s interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component.
That way calling components will not be overwhelmed by irrelevant operations that have been separated out into other interfaces.
|}

=Examples=
Listed below are a few examples.
==Example1==
'''Without ISP'''

For example, a User Interface class that has a number of operations for each different screen that it can handle[[#References|4]].
[[Image:Without ISP.jpg]]

In this example each screen may have a number of display operations, but in such a class the sheer number of operations that the class offers could become unmanageable when it is not easy to see which operations belong to which screens.

As a result of this, problems may arise, should a developer working on the UI class unwittingly attempt to call a UI operation that belongs to a different screen to the one currently being displayed by the UI object.

This would be a breach of the [http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle (LSP)] and could lead to unexpected and unpredictable behaviour.

'''With ISP'''

In the example of a UI class, each operation will belong to a particular screen. Each screen that the UI class is to handle could have an individual UI screen interface defined for it, containing only those operations that are required for that screen.

[[Image:With ISP.jpg]]

When this is done it becomes clear to the developer using a UI object which operations are related to the screen currently being displayed, because the UI interface used in the variable declaration will only expose those operations that relate to that screen.

==Example2==

'''Without ISP'''

We have a Manager class which represent the person which manages the workers. And we have 2 types of workers some average and some very efficient workers. Both types of workers works and they need a daily lunch break to eat. But now some robots were used by the company to work as well , but they don't eat so, they don't need a lunch break. On one side the new Robot class need to implement the IWorker interface because robots work. On the other side, they don't have to implement it because they don't eat.

This is why in this case the IWorker is considered a polluted interface.

If we keep the present design, the new Robot class is forced to implement the eat method. We can write a dummy class which does nothing(let's say a lunch break of 1 second daily), and can have undesired effects in the application(For example, the reports seen by managers will report more lunches taken than the number of people)[[#References|6]].

<pre>
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();
}
}
</pre>

'''With ISP'''

According to the Interface Segregation Principle, a flexible design will not have polluted interfaces. In our case the IWorker interface should be split in 2 different interfaces.

By splitting the IWorker interface in 2 different interfaces the new Robot class is no longer forced to implement the eat method. Also if we need another functionality for the robot like recharging we create another interface IRechargeble with a method recharge [[#References|6]].

<pre>
interface IWorker extends Feedable, Workable {
}

interface IWorkable {
public void work();
}

interface IFeedable{
public void eat();
}

class Worker implements IWorkable, IFeedable{
public void work() {
// ....working
}

public void eat() {
//.... eating in lunch break
}
}

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

class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}

public void eat() {
//.... eating in lunch break
}
}

class Manager {
Workable worker;

public void setWorker(Workable w) {
worker=w;
}

public void manage() {
worker.work();
}
}
</pre>

==Example3==

'''Without ISP'''

In the below example you see one class CarConfigurator interface implementing interface ICarConfigurator that is being used by three different classes; DrawExterior, DrawInterior and DrawEngine. All these different classes are using different functionality of the ICarConfigurator interface.This means that all of these classes are connected to each other and if there is a change for one class in the interface then this will affect all of them [[#References|5]].

<pre>
Interface: ICarConfigurator

namespace ISP
{
public interface ICarConfigurator
{
string ExteriorColor { get; set; }
string InteriorColor { get; set; }
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarConfigurator

namespace ISP
{
public class CarConfigurator : ICarConfigurator
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarConfigurator _Car;

public DrawExterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarConfigurator _Car;

public DrawInterior(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarConfigurator _Car;

public DrawEngine(ICarConfigurator car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

'''With ISP'''

Below is same example but now according to the Interface Segregation Principle [[#References|5]]:

<pre>
Interface: ICarExterior

namespace ISP
{
public interface ICarExterior
{
string ExteriorColor { get; set; }
}
}

Interface: ICarInterior

namespace ISP
{
public interface ICarInterior
{
string InteriorColor { get; set; }
}
}

Interface: ICarEngine

namespace ISP
{
public interface ICarEngine
{
string EngineType { get; set; }
}
}

Class: CarConfigurator : ICarExterior, ICarInterior, ICarEngine

namespace ISP
{
public class CarConfigurator : ICarExterior, ICarInterior, ICarEngine
{
private string _ExteriorColor;
private string _InteriorColor;
private string _EngineType;

public string ExteriorColor
{
get { return _ExteriorColor; }
set { _ExteriorColor = value; }
}
public string InteriorColor
{
get { return _InteriorColor; }
set { _InteriorColor = value; }
}
public string EngineType
{
get { return _EngineType; }
set { _EngineType = value; }
}
}
}

Class: DrawExterior

namespace ISP
{
public class DrawExterior
{
private readonly ICarExterior _Car;

public DrawExterior(ICarExterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this exterior color: "+ _Car.ExteriorColor);
}
}
}

Class: DrawInterior

namespace ISP
{
public class DrawInterior
{
private readonly ICarInterior _Car;

public DrawInterior(ICarInterior car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this interior color: "+ _Car.InteriorColor);
}
}
}

Class: DrawEngine

namespace ISP
{
public class DrawEngine
{
private readonly ICarEngine _Car;

public DrawEngine(ICarEngine car)
{
_Car = car;
}

public void Draw()
{
Console.WriteLine("The car will have this engine: "+ _Car.EngineType);
}
}
}
</pre>

=Conclusion=

If the design is already done, fat interfaces can be segregated using the Adapter pattern.

Like every principle Interface Segregation Principle is one principle which require additional time and effort spent to apply it during the design time and increase the complexity of code. But it produces a flexible design. If we are going to apply it more than is necessary it will result a code containing a lot of interfaces with single methods, so applying should be done based on experience and common sense in identifying the areas where code extensions are more likely to happen in the future [[#References|6]].

=References=
#[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID in OO Design]
#[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling in OO Design]
#[http://codebalance.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html Code Balance - ISP Example]
#[http://www.john-thompson.org/IT/Default.aspx?Path=IT/0200~Architecture/0350~Principles/Interface%20Segregation ISP from an IT architecture perspective]
#[http://fohjin.blogspot.com/2008/04/isp-interface-segregation-principle.html ISP Example]
#[http://www.oodesign.com/interface-segregation-principle.html Good explanation of ISP]
#[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion in OO Design]
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-21T17:53:50Z

Snateka:

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSLs==

History of DSL dates back than modeling approaches used now to develop them. First DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

Properties of any OODSL:

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

==Techniques/Tools used==

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

==Steps to create an OODSL==

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1]Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2]Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3]Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4]Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5]Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6]Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7]Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8]ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9]MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10]Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11]LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12]Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

CSC/ECE 517 Fall 2010/ch2 S23 SS

2010-09-21T16:02:46Z

Snateka:

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSL's==

History of DSL dates back than modeling approaches used now to develop them. First DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

Properties of any OODSL:

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

==Techniques/Tools used==

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

==Steps to create an OODSL==

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1]Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2]Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3]Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4]Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5]Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6]Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7]Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8]ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9]MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10]Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11]LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12]Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf

User:Snateka

2010-09-21T15:53:42Z

Snateka:

==Introduction==

Domain Specific Language (DSL) is any programming language which is designed to solve some specific problems and tasks in a specific domain. These languages are very focused and restricted to particular problem domain. This is in contrast to general programming languages (GPL) like java or C++ which can be used for software development in many application domains. Examples for DSL include:
* SQL for relational database
* Verilog for statistics
* Latex for typesetting

Object Oriented DSL's (OODSL) are DSL's based on object oriented programming paradigm. They employ the idea of classes and objects with concepts like encapsulation, polymorphism, abstraction etc. OODSL's like any other DSL's are much more expressive in their domain and much less comprehensive than general purpose object oriented programming languages like Java, C# etc. They are high-level languages, in the sense that they abstract from low-level implementation details. Some OODSL examples are Rails based on ruby programming language and JSP tags, Hibernate and Spring based on Java.

===Pros and Cons of OODSL===

Like any other DSL, employing OODSL in any application domain comes with its own set of advantages and disadvantages. Some of them are discussed below.

Pros of using OODSL for application development are:
* OODSL's are developed for a particular domain and hence can handle the problems related to that domain. They help express solution in the idiom and abstraction of problem domain and can be easily understood by experts in that domain.
* OODSL's are much simpler to use than general purpose language in their domain.
* They are concise, self documented and easy to understand and hence aid in easy development, maintainability and productivity

On the other side, cons of using OODSL are:
* Developing an OODSL require effort and cost.
* OODSL has limited scope within their domain.
* Using a newly developed OODSL requires users to understand its syntax.
* Using OODSL together with GPL constructs can be a difficult task.

===Types of OODSL===

OODSL can be of two types, internal and external :

'''Internal OODSL''' are the ones which use a host language and give them the feel of a particular language. Developing internal OODSL's is comparatively simple as they use grammar, parsers and tools of underlying language. But they are constrained by the underlying language. The challenge is to design these languages so as to have syntax within the confines of host language, yet these languages are simple, concise and fluent. An example of internal OODSL would be Rake (make equivalent) based on host, Ruby.Internal OODSL's are also referred as embedded languages or fluent interfaces.

'''External OODSL''', on the other hand is designed to be independent of any other language. Syntax, grammar, parsing of these languages is pretty much based on its author choice and gives both pain and pleasure of developing all from scratch. Example of external DSL would be Ant based on java.

==History of OODSL's==

History of DSL dates back than modeling approaches used now to develop them. First DSL's were developed many decades before. Worth mentioning is FORTRAN developed in late 1950s, an abbreviation of 'formula translation'. FORTRAN borrowed notation from mathematics so that programmers could write mathematical formulas directly. OODSL's started coming up after object oriented paradigm became prominent in 1970's and 1980's. OODSL's appeared mostly in late 1980's and 1990's. Now, OODSL's are used in web applications (e.g. Rails), computer games and environments (e.g. MOO programming) and as programming languages for music (e.g. Formes).

==OODSL Examples==

Some examples of OODSL prevalent today are:

* '''Kiddo''' - Kiddo is an internal OODSL based on ruby and used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding and has 5 core methods to get started with drawing.
* '''ColdFusion Markup Language''' - Commonly known as CFML, it is a scripting language used by Adobe's ColdFusion and other scripting engines. The CFML includes a set of tags that can be used in ColdFusion pages to interact with data sources and display output.
* '''MOO Programming Language''' - Moo programming language is used to support Mud Object Oriented or MOO server which is online virtual reality system to which multiple players can connect at the same time. Its domain is computer gaming environment.
* '''LPC''' - It is an object-oriented programming language derived from C and developed originally to facilitate MUD building. It was designed for game development.
* '''Formes''' - It is an object-oriented DSL used for music composition and synthesis. It is written in VLISP.
* '''R - R''' is a programming language for statistical computing and graphics. R has stronger object-oriented programming facilities than most statistical computing languages available.
* '''Kermeta''' - Kermeta is a meta-modeling language used to describe structure and the behavior of models. Kermeta can be used as the core language for a model oriented platform.

==Creating an OODSL==

OODSL can be created using many techniques and tools available in the market.

Properties of any OODSL:

Any OODSL should be fluent and in context.

* '''Fluency''': A fluent OODSL should have interfaces which are properly designed for human use and has high readability and natural flows within the language. An example explaining fluency is given below:

Looping through any collection in java was done traditionally as:

for(int i = 0; i < products.size(); i++)
{
String name = (String) products.get(i);
//...
//.....

}

However it can be done more fluently starting Java 5 as:

for(String product : products)
{
// ...
// ...
}

This flow comes naturally to any user and is easier to interpret.

* '''Context:''' OODSL should have a proper context on which they are built upon, after all, they are domain specific. Shared context makes OODSL easier to understand and work with and highly expressive. For example:

In java declaring and adding into the cart is done as:

java.util.ArrayList<String> cart = new java.util.ArrayList<String>();
cart.add("Milk");
cart.add("Juice");
cart.add("Apple");
System.out.print("My cart has %d items.", cart.size())

Same thing can be done in groovy as:
cart = []
cart.with {
add "Milk"
add "Juice"
add "Apple"
println "My cart has $size items."
}

Languages like Groovy and javascript are easier than java to build context such that convention is followed.

Examples taken from: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-dsls-in-java-2.html?page=3

==Techniques/Tools used==

There are many OO languages like Smalltalk, ruby, groovy which easily lend themselves for creating internal OODSL. Ruby provides expressive, flexible syntax and has a dynamic nature which makes implementing a new OODSL easy without using any additional parser or compiler. Also, groovy easily supports creating fluent and in context OODSL's. On the other hand, C++ or Java syntax is not easy to attain the level of fluency required for a DSL, and so creating internal OODSLs using these languages is challenging. However, these languages offer good parsing libraries or capabilities and their support for creating external DSL’s is pretty strong.

Tools like visual studio and ANTLR aid in creating OODSL. Visual studio contains Domain-Specific Language Designer Wizard which provides many solution templates which can be used to create an OODSL. ANTLR, ANother Tool for Language Recognition, is another language tool that provides a framework for constructing recognizers, interpreters, compilers, and translators from grammatical descriptions. It supports many runtime libraries of ruby, C#, java etc which helps to create internal OODSL.

There are four basic approaches used for creating OODSL. These are:

* '''Instantiation:''' This approach is used mostly in Ruby projects, and not even recognized as a DSL. Using this approach, DSL is defined by defining methods of an object. Interaction is like any other OODSL, done by instantiating the object and calling the methods. The HTML creation DSL of Ruby’s CGI class uses this approach.
* '''Class macros:''' DSL is defined as methods on some ancestor class, and those methods are tweaked to modify the behavior of super-class and for subclasses of the particular class in question. These kinds of macros often create new methods. “has_many” in ActiveRecord is a good example of this type of approach.
* '''Top-level methods:''' There exists a configuration file, which is just like a Ruby script augmented with some DSL syntax. Any application using this type of DSL will load this configuration and uses DSL top level methods defined. When those methods are called in the configuration file, they modify some central (typically global) data, which then application uses to determine how it should execute. Rake is an example of this kind of DSL.
* '''Sandboxing:''' This approach is a special case of the more general instantiation technique. Using this technique, DSL is defined as methods of some object which is really just a “sandbox”. Interaction with the object’s methods modifies state of the sandbox which is queried by the application. This technique is similar to the top-level methods technique, with an exception that the DSL is restricted to the sandbox and there are no global methods involved. Needle uses this approach.

==Steps to create an OODSL==

Some of the steps which can be used to create an OODSL are:
* Identifying the goals to be accomplished.
* Reasoning why creating a new OODSL would be better than existing well crafted OODSL or an API.
* Defining ideal syntax before even coding.
* Referring to other examples of OODSL's, learning from their code and looking at the similarities.
* Refining syntax to get the best Return on Investment. If creating an internal OODSL, it is best to take advantage of host language’s compiler and adapting syntax slightly without creating a new full fledged parser or compiler.

==Example==

Below is an example of how an OODSL for creating SQL statements and querying database systems can be created. It is compared with how the same task is done in general purpose language.

Dynamic construction of an SQL statement in Java :

String sql = "select id, name " +
"from customers c, order o " +
"where " +
"c.since >= sysdate - 30 and " +
"sum(o.total) > " + significantTotal + " and " +
"c.id = o.customer_id and " +
"nvl(c.status, 'DROPPED') != 'DROPPED'";

The same can be written using OODSL as follows :

Table c = CUSTOMER.alias();
Table o = ORDER.alias();
Clause recent = c.SINCE.laterThan(daysEarlier(30));
Clause hasSignificantOrders = o.TOTAL.sum().isAbove(significantTotal);
Clause ordersMatch = c.ID.matches(o.CUSTOMER_ID);
Clause activeCustomer = c.STATUS.isNotNullOr("DROPPED");
String sql = CUSTOMERS.where(recent.and(hasSignificantOrders)
.and(ordersMatch)
.and(activeCustomer)
.select(c.ID, c.NAME)
.sql();

The SQL statement written in Java requires developer to be familiar with Oracle-SQL. This may not be the case for every application development in every domain. An OODSL like above can help in these cases. Creating basic classes representing different constructs of SQL query makes creating query easy. E.g. Class “Table” represents a basic API available through DSL and is used for representing tables which are to be queried. Creating different clauses using class “Clause” help filter data from the database.

The DSL code is less procedural, more declarative and object-oriented. It also has several advantages, major one being creating SQL statements without having familiarity of how to write SQL statements in database packages like Oracle, MySQL etc. The commonly used phrase, “nvl(c.status, 'DROPPED') != 'DROPPED'" in Oracle SQL cannot be easily understood by a non-SQL programmer. By replacing this phrase with the more easily understandable and language-like "isNotNullOr(“DROPPED”)," readability has been enhanced, and the system is protected from a later need to change the implementation to take advantage of facilities offered by another database vendor.

Note: The above example was explained in an easier manner. Further reading can be done from original source, http://www.infoq.com/articles/internal-dsls-java

==Summary==

This article gives some basic overview of OODSL features. OODSLs are mainly used in the domain of software engineering. The challenge using software engineering is to create flexible, reliable, scalable and maintainable systems. To achieve this, the software engineer must apply a wide variety of tools and techniques. One of these is to take advantage of the knowledge from underlying application domain, by means of a domain-specific language (DSL), which provides a notation that can be used to compose applications from a set of concepts tailored towards a specific application domain. Creating OODSL is a good option because OODSL provides benefits from both the worlds, DSL and OO concepts. An OODSL can be easily extended later, if required, which may not be the case with any other DSL. Hence it can be said that, OODSLs provide a certain level of abstraction of a domain, which can result in a greater control over or understanding of that domain. At the same time, they provide some good features of object oriented programming.

==References==
[1]Eelco Visser. WebDSL: A Case Study in Domain-Specific Language Engineering. Lecture Notes in Computer Science, 2008, Volume 5235/2008, 291-373.

[2]Martin Fowler. MF Bliki: DomainSpecificLanguage. Retrieved September 15, 2010, from, http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

[3]Domain-specific Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/Domain-specific_language.

[4]Jeff Barczewski. Creating DSL’s in Ruby. Retrieved September 16, 2010 from http://inspiredhorizons.com/presentations/CreatingDSLsInRuby-060926.pdf

[5]Venkat Subramaniam, Creating DSL’s in java. Retrieved September 16, 2010 from http://www.java2s.com/Article/Java/Development/DSL.htm

[6]Jamis Buck. Writing Domain Specific Languages. Retrieved September 16, 2010 from http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

[7]Alex Ruiz, Jeff Bay. An Approach to Internal Domain-Specific Languages in Java Retreved September 16, 2010 from http://www.infoq.com/articles/internal-dsls-java

[8]ColdFusion Markup Language. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[9]MOO. Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/MOO

[10]Freedom Dumlao. Introducing Kiddo: A Ruby DSL for building simple WPF and Silverlight applications. Retrieved September 15, 2010 from http://weblogs.asp.net/freedomdumlao/archive/2010/05/27/introducing-kiddo-a-ruby-dsl-for-building-simple-wpf-and-silverlight-applications.aspx

[11]LPC (programming language). Wikipedia, the Free Encyclopedia. Retrieved September 15, 2010 from http://en.wikipedia.org/wiki/LPC_(programming_language)

[12]Kermeta Language Overview. Retrieved September 15, 2010 from https://www.kermeta.org/docs/KerMeta-MetaModel.pdf