An interface says that an object is 'something'. It's kind of like
inheritance, but less structured. Eric's example was a good one:
> - class Student { }
> - interface PaperGrader { }
> - class Professor implements PaperGrader { }
> - class TeacherAssistant extends Student implements PaperGrader { }
A PaperGrader is someone who can grade papers, but it doesn't create "is a"
relationships, because it can be done by widely different types
(TeacherAssistant and Professor, in this case). You certainly wouldn't want
to have TeacherAssistant and Professor share a common superclass (except
Object, or perhaps Person), because they are very different, but an
interface lets them share certain behaviour.
Interfaces are also good for setting up polymorphism. Lets say you have a
ArrayList class. It's similar to an array, except object encapsulated. You
add elements, and recall them based on an index. We use this class, and
it's wonderful, but we soon realize that we're doing a lot of inserts and
deletes in the middle of the list. That type of use is inefficient with an
array, but is very efficient with a linked list. So we write a LinkedList
class which uses a linked list, rather than an array, but has the same
methods to do the same thing. Now the question is how do we change the code
that uses the ArrayList class. We have to change a lot of things: return
types, parameter types, possibly method names, and createObject/CFOBJECT
calls. Using an interface (or an abstract superclass) we alleviate most of
these problems. We'll still have to change the createObject/CFOBJECT calls,
but everywhere else we don't use ArrayList, we use List (our abstract
superclass), which both ArrayList and LinkedList extend, so we can later
switch concrete types simply by changing the createObject/CFOBJECT calls.
cheers,
barneyb
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Nando
> Sent: Monday, October 27, 2003 11:33 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFCDev] Template Method Pattern question
>
>
> Hmmm, I've never worked with Java so i don't understand anything
> much about
> interfaces - at least not yet ... still not sure if i'm missing something,
> or what i'm missing here.
>
> I assume if you call a child method, the child method executes, and if you
> call a method in the parent, the parent method executes. I still
> don't quite
> understand how the 2 are connected or if they are connect when
> they share a
> common name.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Behalf Of Barney Boisvert
> > Sent: Monday, October 27, 2003 8:22 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [CFCDev] Template Method Pattern question
> >
> >
> > The purpose is to imitate an interface. By making the abstract class's
> > method throw an error, you are forced to override it in your
> child class.
> > If you have the method in the child class, then the fact that the method
> > exists in the parent is irrelevant, unless you explicitly
> invoke it wuth a
> > call to super.
> >
> > I do this all the time in my classes, because not having interfaces is a
> > real burden to development. Certainly not perfect, but it gets
> > most of the
> > functionality you need.
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Behalf Of Nando
> > > Sent: Monday, October 27, 2003 11:00 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: [CFCDev] Template Method Pattern question
> > >
> > >
> > > Seeing Brendan's post just now reminded me ... I've been
> > reading about the
> > > template method pattern in Brendan's CFDJ article (thanks
> much for those
> > > Brendan!) and am in the middle of putting it to good use. One
> > > thing that's a
> > > little baffling is the inclusion of an "Abstract Method" in the parent
> > > object, the one that throws an error if invoked directly: "This
> > method is
> > > abstract and needs to be overridden."
> > >
> > > Does including an "abstract method" or a method of the same
> name in the
> > > parent have any effect on the overall functionality when using
> > > this pattern,
> > > or is it in the example just to demonstrate the point that if
> > you call the
> > > child object that extends its parent, the state and functions of
> > > the parent
> > > are available to the child? Wouldn't it function in exactly the
> > > same way if
> > > the abstract method was not included in the parent? I'm
> wondering if i'm
> > > missing something here.
> > >
> > >
> > > ----------------------------------------------------------
> > > You are subscribed to cfcdev. To unsubscribe, send an email
> > > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
> > > in the message of the email.
> > >
> > > CFCDev is run by CFCZone (www.cfczone.org) and supported
> > > by Mindtool, Corporation (www.mindtool.com).
> > >
> > > An archive of the CFCDev list is available at
> > www.mail-archive.com/[EMAIL PROTECTED]
> >
> > ----------------------------------------------------------
> > You are subscribed to cfcdev. To unsubscribe, send an email
> > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
> > in the message of the email.
> >
> > CFCDev is run by CFCZone (www.cfczone.org) and supported
> > by Mindtool, Corporation (www.mindtool.com).
> >
> > An archive of the CFCDev list is available at
> www.mail-archive.com/[EMAIL PROTECTED]
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
> in the message of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported
> by Mindtool, Corporation (www.mindtool.com).
>
> An archive of the CFCDev list is available at
www.mail-archive.com/[EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
