That's a very insignificant advantage compared to the amount of work you will go through to use a factory. Sounds like premature (non-)optimization. Especially when every IDE out there can easily accomplish that refactor for you by telling you every place that new Foo() is called.
-- Jeremy Thomerson http://www.wickettraining.com On Fri, Apr 24, 2009 at 9:00 AM, cretzel <[email protected]> wrote: > > My primary reason is to be able to substitute another (improved) version for > this component. > > For example, if we have a simple custom DropDown and we instantiate it by > calling new DropDown() all over in the code it might be difficult, to > replace that by a new version, e.g. DropDownWithCrazyAjaxEffects. If we have > a factory, we'd have just one place where the component is created. > > > Andreas Petersson wrote: >> >> >> >> On Fri, 24 Apr 2009 13:39:35 +0200, Martijn Dashorst >> <[email protected]> wrote: >>> In what way is MyConvolutedComponentFactory.createNewMyComponent() >>> better than "new MyComponent()"? >>> >> >> ideas that come to my mind why to use this: >> 0) you might be able to reduce generics cluttering by using >> TextField<String> = MyConvolutedComponentFactory.createTextField(model); >> with public static <T> TextField<T> createTextField(IModel<T> model); >> 1) be able to use AOP on components (guice). for example use >> @Transactional >> on onClick method to tightly specify transaction boundaries. >> 2) you might be able to reuse (immutable,stateless) components >> 3) you might be able to chose any subtype of component depending on the >> provided parameters >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Factory-for-Components-tp23212875p23217029.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
