Interface segregation principle
(adding examples and fleshing it out) |
|||
| Line 1: | Line 1: | ||
| − | Interface Segregation Principle says that clients should not be forced to depend upon interfaces that they do not use. This is to avoid [[Fat interfaces]] surfacing in the design. | + | Interface Segregation Principle, by [[Bob Martin | Robert Martin]] says that clients should not be forced to depend upon interfaces that they do not use. Or to put it more simply, many client specific interfaces are better than one general purpose interface. This is to avoid [[Fat interfaces]] surfacing in the design. |
| − | + | A good example of this principle is a modern cellphone where it can be a phone but can also be a camera or a music player. However some cellphones, especially the older generation ones, do not have camera or music players. Given these facts, now if we have an interface that provides phone, camera and music functionality (and thus, fat), the older cameras are forced to implement the camera and music functionality which are not used. | |
| − | A good example of this principle is a modern cellphone where it can be also a camera, or music players. | + | |
| + | A better way to solve this is we have smaller and distinct interfaces; one for defining phone functionality, another for defining camera functionality, and the last one will define the music player functionality. Now the modern cell phones can interface with all of them, while the older cell phone only needs to interface with the phone functionality interface, resulting in a cleaner implementation and design. | ||
== See Also == | == See Also == | ||
* [[Fat interfaces]] | * [[Fat interfaces]] | ||
| + | * [[Avoid no-op overrides]] | ||
| + | * [[Separation of concerns]] | ||
== References == | == References == | ||
| − | [[http://www.objectmentor.com/resources/articles/isp.pdf]] | + | [[http://www.objectmentor.com/resources/articles/isp.pdf ISP]] |
Revision as of 07:22, 6 October 2008
Interface Segregation Principle, by Robert Martin says that clients should not be forced to depend upon interfaces that they do not use. Or to put it more simply, many client specific interfaces are better than one general purpose interface. This is to avoid Fat interfaces surfacing in the design.
A good example of this principle is a modern cellphone where it can be a phone but can also be a camera or a music player. However some cellphones, especially the older generation ones, do not have camera or music players. Given these facts, now if we have an interface that provides phone, camera and music functionality (and thus, fat), the older cameras are forced to implement the camera and music functionality which are not used.
A better way to solve this is we have smaller and distinct interfaces; one for defining phone functionality, another for defining camera functionality, and the last one will define the music player functionality. Now the modern cell phones can interface with all of them, while the older cell phone only needs to interface with the phone functionality interface, resulting in a cleaner implementation and design.
See Also
References
[ISP]
