Interface Segregation Principle - SOLID principles

https://miafish.wordpress.com/2015/01/09/the-interface-segregation-principle/
The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.

While if there is another worker comes in, such as Robot, he does not need eat. so if we still design like this, we violate the Interface Segregation Principle.  we can change the interface like this way:

// interface segregation principle - good example
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 launch 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 launch break
 }
}

http://prasadhonrao.com/solid-principles-interface-segregation-principle-isp/
This pattern states that once an interface becomes too fat, it needs to be split into smaller interfaces so that client of the interface will only know about the methods that pertain to them. In other words, client should not be forced to depend upon interfaces that they do not use.

Solution to this problem is to define new interface ITimerFunction and addTimerFunction function in it. So now we have clear separation, to construct simple doors we can use IDoor interface and SimpleDoor concrete class. To construct AdvancedDoor, we can use both IDoor, ITimerFunction interfaces and AdvancedDoor class.

1. public interface ITimerFunction
2. {
3.         void TimerFunction();
4. }
5. 
   
6. class AdvancedDoor : IDoor, ITimerFunction

http://ricardodsanchez.com/2014/10/23/an-introduction-to-interface-segregation-principle-isp/
where the methods are implementing an interface and all its methods and just throwing NotImplementedException errors on some of them, the code is breaking the interface segregation principle.

http://javatechig.com/design-patterns/interface-segregation-principle

public class ReservationLog : IPersist, ILog

Interface segregation is a design principle that deals with the disadvantages of “fat” interfaces. Interfaces containing methods that are not specific to it are called polluted or fat interfaces.

“Clients should not be forced to depend upon interfaces that they don’t use.”

IPrinter, IScanner, IStapler
http://www.codeproject.com/Tips/766045/Interface-Segregation-Principle-ISP-of-SOLID-in-Cs
1. Recompiling the entire code even when a minor change has to be made L
Even if you make a small modification, the entire code needs to be re-compiled wasting precious development time.

2. What happens when you supply this to a client who is interested only in printing job?
You are passing a DLL or a library which contains a bunch of unnecessary functions which are not all required to your client. He or she may get confused over these functions. Passing a printer function to a printer client makes sense. But, what good does it make passing a bunch of irrelevant functions?

3. Problem with “fat” Interfaces
Even though only the Print functionality is the only needed function for the printer-client, he/she might end up implementing some bunch of unwanted functions. Why are you forcing your printer client to implement scanning functionality even when they don't want it?

“The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.”

1. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.
2. Such shrunken interfaces are also called role interfaces.
3. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy

Example/Practice
https://medium.com/@orhanobut/consider-interface-segregation-c120c5ddacc5
No methods should be forced to implement.

	public interface LoginListener { void onLogin();
	void onRegister();
	}
	public interface TextListener {
	void onUsernameTextChanged();
	}

http://blog.csdn.net/zhengzhb/article/details/7296921
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

        接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。本文例子中，将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

         说到这里，很多人会觉的接口隔离原则跟之前的单一职责原则很相似，其实不然。其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建。

         采用接口隔离原则对接口进行约束时，要注意以下几点：

• 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
• 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则。