ISP is not a design pattern - its a design principle. And it helps to avoid implementing interfaces which are not required by clients. E.g. in your case you have client which needs only printing. But you have IJob
interface with bunch of methods which don't needed by this client. Why would I implement DoStaplingJob
, DoJob1
, DoJob2
and DoJob3
if I want only printing? So, solution is creating small interface which satisfies my need:
public interface IPrintingJob
{
bool DoPrintJob();
}
Original interface will look like:
public interface IJob : IPrintingJob
{
bool DoStaplingJob();
bool DoJob1();
bool DoJob2();
bool DoJob3();
}
Now all clients which want only printing, will implement IPrintginJob
interface, without being bothered with other members of IJob
interface. You can continue spliting IJob
interface to smaller interfaces, if you will have clients which don't need whole functionality of IJob
interface.
UPDATE: From client point of view. Depending on big interface is not very convenient. E.g. you have client which wants only printing. You can depend on IJob
interface and pass Job
class instance to this client:
public void Foo(IJob job)
{
job. // intellisense will show confusing bunch of members you don't need here
}
With many small interfaces, you can depend only on IPrintingJob
interface, and still pass big Job
class as implementation of this interface:
public void Foo(IPrintingJob printingJob)
{
printingJob. // intellisense will show single member. easy and handy
}
Another benefit is easy refactoring. Later you can extract printing functionality from Job
class to other small class like PrintingJob
. And you will be able to pass its instance to clients which need only printing.