I am using ColdSpring, have been for a year or so now. The way I intend to use inheritance is pretty mild. What I did was start off with a base component with some basic parameter and property getters and setters. They are very generic but similar to the base component of mach-ii with collection getting and setting, destroy and dump support. While I might not use getters and setter of properties on every object, I think thought this was useful enough to be in there.
This allowed me to greatly simplify things like my applications properties component and ones like it. I also modeled my sessionFacade after this, but didn't reuse the code. Then, what I am doing is setting up base component for object types I use a lot. I have a service base component, which doesn't really do anything now, and then I extend that with a what I'm calling a serviceDatabase component which has prototypes for my basic get and set functions which appear in every single database capable service. This is about as far as I've taken it so far, and looking at the 15 or so applications I'm supporting I'm not sure that inheritance is going to provide a lot more reduction in code at this point. This doesn't seem like much, but taking 60 lines our of every service really has reduced a good deal of code, and it has been pretty painless. I'm not setting up huge chains of inheritance, and the applications these are in are pretty mature. The architecture is mature. So I don't *think* I'm falling into any of the traps. I'm just looking to keep it simple, and help reduce some of the code we're forced to look at all the time. Thanks, James -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Tuesday, September 05, 2006 11:36 AM To: [email protected] Subject: Re: [CFCDEV] Extending CFC and Argument Types An example comes to mind. If you look at the way the Reactor framework uses inheritance in it's generated files, it makes a lot of sense. The inheritance tree(s) pass the IS-A test, and it's specifically designed that way so you can overwrite or add methods. Also, the inheritance trees in those generated files are pretty much "closed to modification" if i can use that term. Sure, the application could be re-architected, and that would throw everything up into the air, but MySQL-specific-SubscriberDAO will always be a SubscriberDAO. If your inheritance tree is based on the idea of code reuse, there are 2 problems that i see. First is that the way this tree is structured locks you in. Let's say it has 3 tiers, root, middle, and top. If down the line you see you need to reuse code from one middle tier component to another, what are you going to do? (Answer: rewrite and debug a lot of code). When you're using inheritance for code reuse, that aspect of your application is not at all "closed to modification". No, i see 3 problems now ... :) So the tendency is going to be to put all the code you need to reuse in your application in a single, perhaps very large, root CFC. That violates a central tenet of OO, an object should do one thing and do it well. No, now i see 4 problems ... LOL! And since CF doesn't allow for multiple inheritance, once you've used inheritance for the purpose of code reuse, you can't use in another situation, where it might be really helpful or even necessary in your architecture. No, now i see 5 problems!!! : - )) They are running ahead of me! Which means effectively that whoever is doing this won't give themselves the opportunity to learn how to use inheritance "properly". Of course, what is proper could be a contentious claim, but it's pretty well documented throughout the OO world that us newbies tend to try and use inheritance improperly. Not that you can't do it as you want and come up with a workable solution. In a small app that doesn't change or grow much, it could work out ok. It's in a larger application that would be developed iteratively where you'll tend to run into trouble. Here's the 5th problem. The fifth problem, in a nutshell, is maintenance. Service stuff will need to change. Once you build everything around the structure of your inheritance tree, you're stuck with it. Inheritance is very useful in certain situations, but the longer your inheritance chain, the more difficult and confusing it is to work with. Either that or you wind up with 1 huge do-it-all CFC as your base component. I think you'd be much better off using composition. Using composition for your service stuff allows you to encapsulate specific aspects of your application in one CFC and use it anywhere. An EmailService for instance. You can always inject a component into another without affecting anything else in your application, but you can't rearrange your inheritance tree without disrupting your whole application. If i haven't convinced you, feel free to try it with inheritance. If it starts to get painful .... look for how you could have used composition. You might also give ColdSpring a try if you decide to go with composition, if you haven't already. The documentation is much better now than it was before. http://coldspringframework.org/docs/ Don't be put off by the complicated feel of it at first. Just try it. I'm just getting used to it myself. It gives you a one-stop place in your application to manage all your dependencies. As i see it, inheritance is going to be your most inflexible approach, and ColdSpring is going to be your most flexible approach. Now i'd better get back to work here. I'm somewhat unemployed these days, so i'm digging deeper into MG:Unity (MG, Reactor, ColdSpring) and enjoying it very much. ciao, Nando Glaser, James B Mr TACOM-RI wrote: > Thank you Sam and Nando, > > I think you both have good ideas and you are correct it doesn't sound > like using "any" is as bad as it might have initially seemed. > > "#1 is that inheritance for code reuse can get you in trouble. If you > have little experience in OO architecture, i'd shy away from that." > > Can you give me an idea of what you mean by this. I am setting up > multiple inheritance trees, and they are all really pretty simple. I'm > only extending things that it really seems to make sense to do so. I > have some room in my projects for experimentation like this. > > Again, > > Thanks for the feedback, I really appreciate it. > James > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected] You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
