I happen to like that style (though I use getInstance), even though it goes against one of the common tenets of OO: "never pass in behaviour-dicating method arguments, make separate methods instead." Like Scratch/Baz suggested, getInstance will delegate to class-specific factory methods where appropriate, but some classes of object (gateways come to mind) are frequently initialized in the same way (pass in the DSN to use).
With a single getInstance, I can have a 'default' initialization routine, and specialize it where needed, saving some code. It's also a structure that'll work no matter whether you can make that code reduction or not, and consistency, consistency, consistency. So I completely agree with you, Nando, even though it goes against best practices. A good example of one of those places where it's a good choice to blatantly go against conventional wisdom. And sorry for the three-in-a-row posts. I was without internet all day, and while I don't like the "jump in after the topic dwindles", I wanted to specifically address these three points, cheers, barneyb On 11/2/05, Nando <[EMAIL PROTECTED]> wrote: > What's with the load() method? > > Well, load() gives you one public interface to code to. The implementation > details within Factory can change without affecting the rest of your app. > > Do you see a drawback to that? Maybe there is one ... my working hypothesis > at the moment is that it would be better in the long run to stay with a > single interface and work out any drawbacks in another way. > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
