Joe, I'm not in total agreement with your comment that items that inherit must have a defined version of the supers methods.
For instance, lets say I have a gateway class fooGateway that has a method getALLFoos which calls a pretty ANSI standard sql query that works across all of the databases my application supports. I also have a few other similar queries that work across my databases (say oracle, mysql, and ms sql). But there are a few methods that can't work this way due to syntactic differences (such as outer joins) between the different databases. I might then have a fooMSGateway and fooOracleGateway and a fooMySQLGateway that inheirit from fooGateway. Then my gateway factory would instantiate the correct database gateway depending on the apps current configuration information. All three of my specific gateways have and are inheiriting from the generic one - but they don't all have unique versions of all methods of the Super. Maybe you weren't saying that at all and I just misunderstood - I dunno - if so sorry :O) On Thu, 20 Jan 2005 06:32:10 -0800, Joe Rinehart <[EMAIL PROTECTED]> wrote: > >> ExampleC has two dependencies - it relies on com.use.ThingyHolder > >> having a getThingy() method, and on the result of getThingy() have a > >> doSomething() method. > > > >But C is more loosely coupled to Thingy. C is dependent on > >ThingyHolder but not on the Thingy itself. Whatever > >ThingyHolder.getThing() returns must have a doSomething() method but > >it could be absolutely any type of object. > > This is what I was trying to get at - C depends on ThingyHolder have a > getThingy(), but it doesn't depend on the result of getThingy() being > a specific type, just that it's "contract bound" to have a > doSomething() method. > > >C is an example of a factory - C depends on the factory to provide the > >actual object to operate on. > > I get it, light bulb, it's letting another class decide what actually > gets instantiated, and because that class doesn't need to be a > concrete Thingy, just something that implements what a Thingy is, we > just became more flexible by not relying on a concrete but an > abstract..right? > > > > >> One thing to take into consideration is coding to interfaces, not > >> implementations - instead of requiring a com.useful.Thingy, require a > >> com.useful.BaseType that Thingy implements/extends, where all types > >> extending BaseType have a doSomething() method. > > > >Well, CF doesn't have interfaces so you need to be a little careful > >with that analogy. > > > >Inheritance is just about the tightest possible coupling you can have > >between two classes, which is a good reason to avoid inheritance in > >favor of composition > > I try to avoid inheritance because it seems like an easy route to do > things that can come back to bite me later, and the alternate > solutions using coupling I've tried end up being much more elegant. > > I'm a little confused, though, as to handle polymorphic concerns in CF > without it. If we did have some sort of abstract functionality, it'd > be great. Right now, I flip-flop between 1) using inheritance to > mimic the typing 2) having the actualy abstraction be an unenforced, > completely virtual concept with methods taking and returning type > "Any". > > In other words, the first method could have a CFC called > "doSomethingable" that is subclassed by "FooThingy" and "BarThingy," > and have the returnType of ThingyHolder.GetThingy() be > "doSomethingable". > > However, I really don't like using inheritance, and this method > doesn't have any real compile-time enforcement of making sure all > subclasses of doSomethingable actualy have a method called > "doSomething()". It's why I've been moving more towards having > "FooThingy" and "BarThingy" agree, on paper, in some other document, > or simply in my head that they will both implement a doSomething() > method, and having GetThingy() return Any. > > Any advice? > > -Joe > > -- > For Tabs, Trees, and more, use the jComponents: > http://clearsoftware.net/client/jComponents.cfm > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words '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] > -- [EMAIL PROTECTED] http://blog.rawlinson.us I have 9 gmail invites,want one? ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words '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]
