Ever heard of constructor chaining? -Matej
On 11/3/07, Brill Pappin <[EMAIL PROTECTED]> wrote: > Moving to the list as suggested by Gwyn. > > From Jira issue: > https://issues.apache.org/jira/browse/WICKET-1108 > > Maybe I wasn't clear on what my problem with it was. > > 1) doing any extensive amount of work in a constructor is an anti-pattern > AFAIK. > 2) If the API is designed so that I am expected to build a complex component > in it's constructor then I should be able to override any of the > constructors and expect it to be called. > > If you don't want to include a specialized method for initializing a > component (e.g. the way Servlet works) and expect the constructor to be the > "primary" means of building up the component, then the constructors should > follow good practice and all get called. > > This is a common Java pattern. There should be only one place in the code > where properties are set from a constructor, all other constructors should > pass on their parameters, defaults if required, to the one constructor that > actually sets the properties. > > If you don't code well, you have three immediate problems which as an agile > fan, I would cringe at: > 1) You have duplicate code, no way around it. > 2) you can never be certain which constructor is called by the API and any > given point. You may be able to get it to work, but a future change to the > API could break your code, and you might well not catch it with your own > unit test (you have some right?). > 3) in order to support having two overridden constructors, I now am *forced* > to duplicate my own code (granted it could be one line, but its still > duplication). > > Now... fixing the constructor calls is not impossible but may require a bit > of thought (I don't believe thinking is a problem for the developers of > Wicket as they have clearly done a lot of it already) however I personally > would prefer a specific method call for initializing the component... at the > very least so I don't have to do all that work in the constructor, but it > also has the benefit of being *very* easy to implement with the current > codebase. > > Despite my preference for an init override, I think the correct thing to do > with or without it is to fix the constructor calls. > > > > - Brill Pappin > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
