Re: Interfaces Question - I am missing something

On Tue, 06 May 2008 14:25:21 -0700, jmDesktop <needin4mation@xxxxxxxxx> wrote:

[...]
Now, what I don't get is why this is so great. I understand it looks
better than the else if construct and the JVM calls the individual
classes that implement the behavior that are of the Washable "type"
interface, with there methods in a cleaner way, but...You still have
to create a wash() method for each class that wo.wash() calls, so how
did I make out better?

Well, one of the most obvious advantages you seem to be missing is that in the non-polymorphic example you provided, you would need to update the method any time you added a new class that was "washable". With an interface, _any_ class can implement the interface, and code that relies on the interface will "just work". It will work with any implementation of the interface, including implementations made long after the code using the interface was written.

As a classic example, see all the "listener" type interfaces in Java. These are very common in AWT and Swing, as a way of allowing arbitrary classes to hook into events that might occur within the GUI framework. Using interfaces, developers like you and me can write classes that respond to these events without having to call up Sun and say "hey, I've got this class I want added to your run-time implementation that's going to listen to events in your JFrame class".

From a more general point of view, this idea is a central focus of OOP programming overall. It's not just interfaces. Abstract and virtual methods create similar situations where the caller of the method doesn't need to know anything about what class actually implemented the method. All they need to know is the base class that the implementation inherited. Again, the actual implementation can be done long after the code that uses the implementation was written, because it complies with the contract defined in the base class that the using code _does_ know about.

In Java, all methods are virtual by default, making this sort of thing that much more common and important (admittedly, that's not always a good thing :) ).

Interfaces provide the same sort of functionality, but without the restriction that you can only inherit/implement one of them (which is a restriction of classes). In some sense they are also more "pure", since an interface _never_ defines any part of the implementation. They are _only_ a contract.

For what it's worth, since you're asking the question I assume that you're relatively new to OOP. Once you've done more OOP and taken advantage of abstract and virtual base methods/classes, and perhaps even worked with interfaces themselves, I think it will become more clear why they are useful. It's sometimes hard to explain the practical advantages to someone who's never had a chance to really work with code that takes advantage of them (or with code that doesn't :) ).

Pete
.

Relevant Pages

  • Re: Unification of Methods and Functions
    ... I am suggesting that we write factory methods using classmethod to give ... my classes all implement an interface which I'll call 'shape ... Rectangle and Ellipse have a common base class, ...
    (comp.lang.python)
  • Re: Do all OOM objects support the IMessage interface?
    ... OutlookSpy - Outlook, CDO ... > works of a generic interface to Outlook items. ... > specializations of some base functionality, I look for a base class ... the closest I have come to this with the OOM objects is the common ...
    (microsoft.public.win32.programmer.messaging)
  • Re: Bussines objects
    ... The reality is that OOP systems are just short hand for a lightweight ... those little references must be replaced by a more suitably ... > you look at the concept of Responsibility Driven Design; ... interface coding gave way to the declarative ease of use of HTML. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: OOP with FORTRAN
    ... > I am trying to understand the concept of Object Oriented Programming ... > (OOP) with fortran. ... Akins book tries to fill a void in the Fortran bookshelf. ... interface getval ...
    (comp.lang.fortran)
  • Re: inheritance like Animal : List
    ... The fact is, to implement an interface should also mean the type "is a", not "has a". ... In the general guidelines of OOP design, there's not a third option, "has an aspect which is a". ... Finally, there is the school of thought in OOP that inheritance of implementation should be _strictly_ a private affair, with non-implementation interfaces being the only visible "inheritance" for a type. ... As far as the specific example of XmlNode goes, it seems to me that having XmlNode inherit and implement IEnumerableis a potentially practical departure from a rigid OOP design. ...
    (microsoft.public.dotnet.languages.csharp)