CSC/ECE 506 Fall 2007/wiki3 4 sm

Interface Segregation principle

The Interface Segregation principle states that

"Clients should not be forced to depend upon interfaces that they do not use."^[1]

The interface segregation principle comes from a desire to avoid "fat" interfaces; interfaces whose methods can be divided into more than one group. This is very similar to the principle that a class should only do one thing and do it well.

An excellent example of why "fat" interfaces should be avoided is provided by DoodleProject:

Recall the on-line bookseller system introduced in the Open-Closed Principle and referred to in the Dependency Inversion Principle. Now the company wants to start offering music CDs for sale through its website. To accommodate this, the search engine portion of the website will need to be modified. Trying to reuse as much code as possible, the SearchEngine and Query types are amended to accept CD searching queries. The resulting class diagram is:

To satisfy the requirements of CD searching, the Query interface was forced to handle both BookServletQuery and CDServletQuery functionality. In the future, if there is any change to the searching functionality of CDServletQuery, then that change will be forced onto the Query interface. Furthermore, any change to Query forces a change to all of its implementers, including BookServletQuery. This scenario, a change in the CD query portion of the website forces a change (and possible bugs) in the book query portion of the website, makes the software very fragile. To fix this BookServletQuery and CDServletQuery must be implemented from separate interfaces. This can easily be accomplished by adding some additional abstract types to the design that are more specific in their tasks. The new class diagram is:

With this design, the two functional concerns have been separated. Now, if CDServletQuery needs new searching functionality, the change is forced upon CDQuery but can not propagate to the book query portion of the design.

The basic idea is that it is good practice to make sure that a single objuect (in this case, an interface) does not do too much. The more functionality that is put into an object, the harder it becomes to update that object when requirements change.

References

[1] http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html

[2] http://www.objectmentor.com/resources/articles/isp.pdf

[3] http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html