CSC/ECE 517 Fall 2007/wiki3 4 rl: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(38 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Assignment=
=Assignment=
Take the Interface Segregation principle and catalog the information on it available on the Web. We didn't cover it in class, but you can look it up on the Web or in the ACM DL. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.
Take the Interface Segregation principle and catalog the information on it available on the Web. We didn't cover it in class, but you can look it up on the Web or in the ACM DL. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.
'''Note to Reviewers''': To create this wiki, I did extensive searching on Google, IEEE, and the ACM Digital Library.  There are very few resources that address ISP beyond a sentence or two.  This is why my wiki is fairly short.  Also, there weren't enough resources for it to make sense to split them out into "good descriptions" vs "good examples".  There was too much overlap between the two.  Please note also that all prose on this page is original.


=Introduction=
=Introduction=
TODO: Write up intro, mention that there's not a lot of resources on this and lots of overlap between my description sites and example sites so doesn't make sense to break them out ... maybe put this in note to reviewer, be sure to pick a "best to present to class" from examples.
The Interface Segregation Principle (ISP) is a design principle that calls for small, cohesive [http://en.wikipedia.org/wiki/Interface_%28computer_science%29 interfaces].  All methods contained in an interface should apply to all clients of that interface; that is, there should be no methods in the interface that are only applicable to a subset of the interface's clients.  Otherwise, there is an undesirable coupling between those clients that do require particular methods in the interface and those that do not.  A good rule of thumb is that if you find yourself writing a lot of no-op methods in your implementations of the interface, you've probably violated ISP and should rethink your design.


=Interface Segregation Principle Resources on the Web=
For example, say you have an interface called Creature.  It is implemented by objects of all types of living creatures, such as mammals, reptiles, etc.  By the Interface Segregation Principle, a method named getHairColor does not belong in the Creature interface, since it applies to some creatures (such as mammals) but not to others (such as reptiles).


Following is a catalog of the best Interface Segregegation Principle resources on the Web. Those containing useful examples are marked with a [[Image:Pencil.jpg]] and include a description of the example. (reword)


=Interface Segregation Principle Resources on the Web=
Following is a catalog of the best Interface Segregation Principle resources on the Web. Those containing the most useful examples are marked with a [[Image:Pencil.jpg]] and include a description of the example. The resource that is best for teaching ISP to a class is marked with a [[Image:Star.jpg]].
<hr>
<hr>
http://www.objectmentor.com/resources/articles/isp.pdf<br>
http://www.objectmentor.com/resources/articles/isp.pdf<br>
This article, "The Interface Segregation Principle," is the seminal work on ISP.  The author, Robert Martin, presents the disadvantages of what he calls "fat" or "polluted" interfaces.  Such interfaces contain methods that apply to only a subset of the clients that use the interface.  This results in an undesirable coupling between those clients that do require particular methods in the interface and those that do not.  Martin summarizes the ISP as "Clients should not be forced to depend upon interfaces that they do not use."
This article, "The Interface Segregation Principle," is the seminal work on ISP.  The author, Robert Martin, presents the disadvantages of what he calls "fat" or "polluted" interfaces.  Martin summarizes the ISP as "Clients should not be forced to depend upon interfaces that they do not use."  


[[Image:Pencil.jpg]]Martin provides a detailed example involving the user interface of an ATM machine.  He shows a design that violates the ISP, and then tells the reader how to fix it.  This example, written in C++, is worth reading but also very involved and somewhat difficult to follow.
[[Image:Pencil.jpg]]Martin provides a detailed example involving the user interface of an ATM machine.  He shows a design that violates the ISP, and then tells the reader how to fix it.  This example, written in C++, is worth reading but is also very involved and somewhat difficult to follow.


<hr>
<hr>
http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html<br>
http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html<br>
This page  
Like the original Martin article, this page describes fat interfaces and why they should be avoided.
 
[[Image:Pencil.jpg]]The ISP example on this page concerns an online store that sells both books and CDs.  The example offers a solution that violates the ISP, and then presents a proper design.
 
<hr>
http://www.everything2.com/index.pl?node_id=1259576<br>
This page presents ISP in the context of the "Few Interfaces" and "Small Interfaces" rules of OO design. It discusses the benefits of these two rules, and shows how they relate to ISP.


<hr>
<hr>
http://www.oodesign.com/oo_principles/oo_principles/interface_sergregation_principle.html<br>
http://www.oodesign.com/oo_principles/oo_principles/interface_sergregation_principle.html<br>
Though not particularly well written, this page is unique in that it presents the ISP in the format of a design pattern.  It is organized into Motivation, Intent, Example, and Conclusion.
[[Image:Pencil.jpg]]If you can get past the egregious spelling, grammatical, and coding errors, you'll find the example on this page simple and straightforward.  The author uses the concept of a Worker who both performs work and eats lunch, then shows how a Robot worker doesn't eat and shouldn't have to implement the eat method.
<hr>
http://www.ddj.com/blog/architectblog/archives/2006/06/interface_segre.html<br>
Blogger Arnon Rotem-Gal-Oz refers to ISP as a "poor man's [http://en.wikipedia.org/wiki/Single_responsibility_principle Single Responsibility Principle]," and considers it a special case of [http://en.wikipedia.org/wiki/Separation_of_concerns Separation of Concerns].  He also points his readers to another source that discusses how to determine what client-specific interfaces to create for any given application.
<hr>
http://www.nada.kth.se/~karlm/prutt05/lectures/prutt05_lec11.ppt#31<br>
These lecture notes contain a clear and concise description of ISP, and also present the problem and two solutions as a general formula.
<hr>
http://ifacethoughts.net/2006/03/28/interface-segregation-principle/<br>
This site provides a quick and easy description of ISP, as well as an example involving cell phones that double as MP3 players.  It also recommends the Law of Demeter for help in determining interfaces.
<hr>
http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx<br>
This page offers a handful of descriptions of ISP as well as a brief example involving an inventory control system. <br>
<hr>
http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html<br>
This article states the ISP as "Many specific interfaces are better than a single general interface."  It talks about ISP in the context of the Java programming language and provides some background information on interfaces and inheritance.
[[Image:Pencil.jpg]]The example in this article shows what goes wrong if you have file data access objects and database data access objects attempting to use the same interface.  Because the behaviors of these two objects are so different, they should not share an interface.
[[Image:Star.jpg]]This is the best resource for presenting the Interface Segregation Principle to a class.  The description is clear and well-written and provides the right level of detail for covering the topic in an Object-Oriented Design course.  The example is also the best that I have seen.  It is very clear and easy to follow.


=References=
=References=
#[http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]
#[http://www.objectmentor.com/resources/articles/isp.pdf The Interface Segregation Principle]
#[http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html DoodleProject - Interface Segregation Principle]
#[http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html DoodleProject - Interface Segregation Principle]
#[http://www.everything2.com/index.pl?node_id=1259576 Everything2 - Interface Segregation Principle]
#[http://www.oodesign.com/oo_principles/oo_principles/interface_sergregation_principle.html OOD Principles - Interface Segregation Principle]
#[http://www.oodesign.com/oo_principles/oo_principles/interface_sergregation_principle.html OOD Principles - Interface Segregation Principle]
#[http://www.ddj.com/blog/architectblog/archives/2006/06/interface_segre.html If You Build It... Will They Come? Interface Segregation Principle]
#[http://www.nada.kth.se/~karlm/prutt05/lectures/prutt05_lec11.ppt#31 Lecture Notes - ISP Interface Segregation Principle]
#[http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html Java Boutique - Fine-tuning Abstraction: Interface Segregation Principle]
#[http://ifacethoughts.net/2006/03/28/interface-segregation-principle/ ifacethoughts - Interface Segregation Principle]
#[http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx David Hayden - Interface Segregation Principle]

Latest revision as of 04:23, 26 November 2007

Assignment

Take the Interface Segregation principle and catalog the information on it available on the Web. We didn't cover it in class, but you can look it up on the Web or in the ACM DL. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.

Note to Reviewers: To create this wiki, I did extensive searching on Google, IEEE, and the ACM Digital Library. There are very few resources that address ISP beyond a sentence or two. This is why my wiki is fairly short. Also, there weren't enough resources for it to make sense to split them out into "good descriptions" vs "good examples". There was too much overlap between the two. Please note also that all prose on this page is original.


Introduction

The Interface Segregation Principle (ISP) is a design principle that calls for small, cohesive interfaces. All methods contained in an interface should apply to all clients of that interface; that is, there should be no methods in the interface that are only applicable to a subset of the interface's clients. Otherwise, there is an undesirable coupling between those clients that do require particular methods in the interface and those that do not. A good rule of thumb is that if you find yourself writing a lot of no-op methods in your implementations of the interface, you've probably violated ISP and should rethink your design.

For example, say you have an interface called Creature. It is implemented by objects of all types of living creatures, such as mammals, reptiles, etc. By the Interface Segregation Principle, a method named getHairColor does not belong in the Creature interface, since it applies to some creatures (such as mammals) but not to others (such as reptiles).


Interface Segregation Principle Resources on the Web

Following is a catalog of the best Interface Segregation Principle resources on the Web. Those containing the most useful examples are marked with a and include a description of the example. The resource that is best for teaching ISP to a class is marked with a .


http://www.objectmentor.com/resources/articles/isp.pdf
This article, "The Interface Segregation Principle," is the seminal work on ISP. The author, Robert Martin, presents the disadvantages of what he calls "fat" or "polluted" interfaces. Martin summarizes the ISP as "Clients should not be forced to depend upon interfaces that they do not use."

Martin provides a detailed example involving the user interface of an ATM machine. He shows a design that violates the ISP, and then tells the reader how to fix it. This example, written in C++, is worth reading but is also very involved and somewhat difficult to follow.


http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html
Like the original Martin article, this page describes fat interfaces and why they should be avoided.

The ISP example on this page concerns an online store that sells both books and CDs. The example offers a solution that violates the ISP, and then presents a proper design.


http://www.everything2.com/index.pl?node_id=1259576
This page presents ISP in the context of the "Few Interfaces" and "Small Interfaces" rules of OO design. It discusses the benefits of these two rules, and shows how they relate to ISP.


http://www.oodesign.com/oo_principles/oo_principles/interface_sergregation_principle.html
Though not particularly well written, this page is unique in that it presents the ISP in the format of a design pattern. It is organized into Motivation, Intent, Example, and Conclusion.

If you can get past the egregious spelling, grammatical, and coding errors, you'll find the example on this page simple and straightforward. The author uses the concept of a Worker who both performs work and eats lunch, then shows how a Robot worker doesn't eat and shouldn't have to implement the eat method.


http://www.ddj.com/blog/architectblog/archives/2006/06/interface_segre.html
Blogger Arnon Rotem-Gal-Oz refers to ISP as a "poor man's Single Responsibility Principle," and considers it a special case of Separation of Concerns. He also points his readers to another source that discusses how to determine what client-specific interfaces to create for any given application.


http://www.nada.kth.se/~karlm/prutt05/lectures/prutt05_lec11.ppt#31
These lecture notes contain a clear and concise description of ISP, and also present the problem and two solutions as a general formula.


http://ifacethoughts.net/2006/03/28/interface-segregation-principle/
This site provides a quick and easy description of ISP, as well as an example involving cell phones that double as MP3 players. It also recommends the Law of Demeter for help in determining interfaces.


http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx
This page offers a handful of descriptions of ISP as well as a brief example involving an inventory control system.


http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html
This article states the ISP as "Many specific interfaces are better than a single general interface." It talks about ISP in the context of the Java programming language and provides some background information on interfaces and inheritance.

The example in this article shows what goes wrong if you have file data access objects and database data access objects attempting to use the same interface. Because the behaviors of these two objects are so different, they should not share an interface.

This is the best resource for presenting the Interface Segregation Principle to a class. The description is clear and well-written and provides the right level of detail for covering the topic in an Object-Oriented Design course. The example is also the best that I have seen. It is very clear and easy to follow.


References

  1. The Interface Segregation Principle
  2. DoodleProject - Interface Segregation Principle
  3. Everything2 - Interface Segregation Principle
  4. OOD Principles - Interface Segregation Principle
  5. If You Build It... Will They Come? Interface Segregation Principle
  6. Lecture Notes - ISP Interface Segregation Principle
  7. Java Boutique - Fine-tuning Abstraction: Interface Segregation Principle
  8. ifacethoughts - Interface Segregation Principle
  9. David Hayden - Interface Segregation Principle