Thanks for that explanation Barney. I know i should have learned all this in university, but when i went, i packed a manual typewriter that made my fingers ache after the first paragraph. The only thing i had to organize data was the post-it notes i stuck up on the wall. If i remember correctly, i think 3M had just invented them - they were all the rage. And i don't even think i'm that old.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Barney Boisvert > Sent: Monday, October 27, 2003 8:58 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Template Method Pattern question > > > 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] ---------------------------------------------------------- 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]
