Yes Greg, you've got this one wrong. ;-) getInstance() is usually a static method that you call on a class to return an instance of that class. This is done when you make the constructor private (which, in Java, is almost always a smart design decision because it allows you to encapsulate the creation of the object and maintain control over what happens during instantiation).
You can call it getMemento(), but I'm somewhat concerned about the increasing popularity of doing this. Under what circumstances do you really want to return the internal state of an object? I think in most cases it would be better to pass the actual instance around, so that other code can call methods on the object and you maintain encapsulation and reap the benefits of any business logic that lives in the bean. On 10/4/07, Greg Stevens <[EMAIL PROTECTED]> wrote: > > > Hey Paul, > > You bring up another problem I just recently encountered - whether to > call a method which returns Variables.instance (a struct that holds > all the instance data) getInstance() or getMemento(). > I have been calling it getInstance(), however lately I have thought > about using getInstance() in my Singletons in order to return them, as > I think it is some sort of Java standard. I could be totally wrong on > this though. I understand that getMemento() comes from the Memento > pattern. > > Any thoughts, getInstance() vs getMemento()? > > - Greg > > On Oct 2, 1:26 pm, "Paul Marcotte" <[EMAIL PROTECTED]> wrote: > > Hi Greg, > > > > I've experimented with composing DAOs inside Beans. I don't know if > there > > is a specific problem with using dao.saveRecord(this), but if you think > > about what "this" is, you're going to be passing the Bean and the > composed > > DAO into the composed DAO, which just seems weird to me. For my > > implementation, I use dao.save(getInstance()), where getInstance() > returns > > the variables.instance struct. You can call getInsance() by another > name > > like getMemento() or something similar. To me, passing a struct off to > the > > DAO is like passing a poor man's value object (which, in my > understanding, > > is an object wrapper around an instance struct with no get/set methods.) > > > > Granted, I'm not a design patterns guru, so I'll defer to Brian and Tom > on > > this point... > > > > Paul > > > > On 10/2/07, Greg Stevens <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > Definitely right, it could be overkill. Wasn't looking at this for a > > > specific application though, just some generic methods / conventions. > > > > > btw, in the quick examples posted, running dao.saveRecord(this) *is* > > > passing the dao a bean, assuming that dao.saveRecord(...) is being > > > called from within the bean itself. > > > > > On Oct 2, 1:38 am, Alan Livie <[EMAIL PROTECTED]> wrote: > > > > Or pass a bean (or an ID for deleting maybe) to your DAO's methods. > > > > > > Not sure if a service layer AND managers would be overkill for your > > > > application. It depends on the size of it and how large you expect > it > > > > to grow. > > > > > > Suppose it's nice to have maximum flexibility though. > > > > > > On Oct 2, 4:11 am, Greg Stevens <[EMAIL PROTECTED]> wrote: > > > > > > > Thanks for the posts Brian and Tom. Definitely cleared up a bit > for me > > > > > and also reinforced some of the ideas I have been having lately. > > > > > > > @Brian - I feel the same way as you about the extends and IS-A > > > > > relatonships. That is what got me thinking about injecting the DAO > > > > > into the bean and running something like dao.saveRecord(this). > > > > > > > @Tom - Thanks for the link, I will have to read it more thoroughly > > > > > later. > > > > > > > Right now I am leaning towards Tom thinking of a Service layer > being > > > > > more in charge of the various managers. Am going to have to read > up > > > > > some more articles on it. Perhaps finally dig into some more > Martin > > > > > Fowler or something. > > > > > > > Again, thanks for the help guys! > > > > > > > - Greg > > > > > > > On Oct 1, 2:58 am, Tom Chiverton <[EMAIL PROTECTED]> > wrote: > > > > > > > > On Sunday 30 Sep 2007, [EMAIL PROTECTED] wrote: > > > > > > > > > Part-1#comments) and it made me remember that I am confused on > > > exactly > > > > > > > what Service CFCs are. I posted this question to the blog, > however > > > > > > > would really like to receive a lot of feedback and different > > > opinions > > > > > > > on this. > > > > > > > >http://rachaelandtom.info/building-coldfusion-services-2 > > > > > > > > > I have been getting more into CFCs and proper OO methodologies > > > lately, > > > > > > > 90% of it is all making sense and every day more and more > becomes > > > > > > > clear, > > > > > > > > Doing it day and day out sure helps :-) > > > > > > > > > In my mind a > > > > > > > Gateway CFC deals with the database when retrieving more then > 1 > > > > > > > record. > > > > > > > > That's how Reactor uses them, sure. > > > > > > > > > My question is - I find I need to have a CFC that co-ordinates > > > actions > > > > > > > between multiple beans, takes some sort of action, performs > > > business > > > > > > > logic on 2 different beans that may represent 1 class or > perhaps 2 > > > > > > > classes (eg/ maybe 2 staff benas or 1 staff bean and 1 company > > > bean). > > > > > > > I am wondering - would this be considered a Service CFC? A > Manager > > > > > > > CFC? Something else? > > > > > > > > Sounds like a Manager to me. > > > > > > A Service would deal with the mechanics of locating the thing to > do > > > the work, > > > > > > getting it invoked and the results passed back to the caller. > > > > > > > > -- > > > > > > Tom Chiverton > > > > > > > > **************************************************** > > > > > > > > This email is sent for and on behalf of Halliwells LLP. > > > > > > > > Halliwells LLP is a limited liability partnership registered in > > > England and Wales under registered number OC307980 whose registered > office > > > address is at St James's Court Brown Street Manchester M2 2JF. A list > of > > > members is available for inspection at the registered office. Any > reference > > > to a partner in relation to Halliwells LLP means a member of > Halliwells > > > LLP. Regulated by The Solicitors Regulation Authority. > > > > > > > > CONFIDENTIALITY > > > > > > > > This email is intended only for the use of the addressee named > above > > > and may be confidential or legally privileged. If you are not the > addressee > > > you must not read it and must not use any information contained in nor > copy > > > it nor inform any person other than Halliwells LLP or the addressee of > its > > > existence or contents. If you have received this email in error > please > > > delete it and notify Halliwells LLP IT Department on 0870 365 8008. > > > > > > > > For more information about Halliwells LLP > visitwww.halliwells.com.-Hidequoted text - > > > > > > - Show quoted text - > > > > -- > > Paul Marcotte > > Fancy Bread - in the heart or in the head?http://www.fancybread.com- > Hide quoted text - > > > > - Show quoted text - > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
