I've been reading the "Headfirst" series book on Design Patterns. Excellent book. The series is devoted to Java. But this book applies to .Net as well.

One of the first patterns they discuss is the Decorator pattern. The name is self explanatory based on the example they give. A coffee shop system. You have the main abstract class that the basic coffee types inherit from. These would be Espresso, Decaf, etc. Then you would "decorate" your basic type with the options, such as Whip, Mocha, etc. The classes that would decorate, implement your interface in this case.

By implementing the interface you are guaranteed that all you decorators will have the necessary methods and properties to allow for polymorphism. So when it comes time to put all the necessary objects together, you can loop thru all the objects you have linked and call their "Cost" method for example.

So in this case, interfaces are used to aid in OO design. No matter who works on the system needs to know that all decorators implement your interface. This ensures that the main code can not ever break. The "cost" method and whatever else will always be present, 100% of the time.


>>Hugo, could you elaborate on this? I'm curious as to why you have this viewpoint. Specifically, what kind of workarounds are you talking about, what is "the most commonly used way" of using Interfaces (in your opinion) and what is it that you think detracts from a good OO design?
>>
>>TIA,
>>~~Bonnie
>
>
>Bonny, did I say that it detracts from a good OO design/develpment? I do not think it helps, that does not mean it detracts. Let me try to explain, I am not good at this.
>
>I said they are mostly used (and this is just a personal opinion by reading questions and answers in different places, I must appologize if it appeared as if I performed some statistics, which I obviously did not, and reading Java newsgroups might have been a negative factor), sorry, I was saying, they are mostly used as a work around to solve the problems that arise using types in an OO language. You will notice that this use of interfaces do not exist in a pure OO language, like Smalltalk (Although they can be added, in particular as a Multiple Inheritance "solution"). Of course this is not the only use interfaces have, Kevin Goff gave a lecture on the topic, but I disgress. The question is why did I say that they do not help OO D/D in this conditions? Simple, they are there as the solution to a problem that would not exist in a OO D/D
>
>Kevin mentioned that in the .NET Framework they are used extensively. Now, I do not know even 1% of what Kevin knows about the .NET framework, but some of those interfaces are, IMO, just the work around I was talking about (plus something else I did not want to discuss with Martín, that is the "predicates", but I disgress again), just take a look at IEnumerator and IEnumerable interfaces as a clear example of what I am trying to say, you would not need this interfaces at all in OO language, the "contract" is needed just for languages purposes, like the use of foreach, among other uses I am sure.
>
>Not sure if I am clear, I said before I am not good at all at making others understand me, in particular for I barely understand myself the little I lie myself I know.
>
>By the way, of what I said to Kevin, the interfaces bit was just that, a small comment, I did not expect to get any answers for it, I thought my other comments to Kevin were deserving of some answers, but, once again, Hugo was wrong, will I ever get used to it?
>
>Oh, my, I can't believe I missed the basketball game to write this, never again! :(