Passing a lot of parameters in constructor?
in [OOP]
|
From: howa on 11 Feb 2007 12:55 for example, a Person class, I need to create a person using, e.g. Person peter = new Person('Peter', '....) the object creation might involved over 30 parameters, the advantage is this call is atomic, rather than something like, e.g. Person peter = new Person(); peter.setName('Peter'); peter.setBirthPlace('.... .... Are there any platterns, suggestion or anti-plattern related to this problem? thanks.
From: Johan Stuyts on 11 Feb 2007 14:05 > Person peter = new Person(); > peter.setName('Peter'); > peter.setBirthPlace('.... > ... > > Are there any platterns, suggestion or anti-plattern related to this > problem? You can use a separate object to hold the parameters for the constructor: PersonCreationParameters params = new PersonCreationParameters(); params.setName('Peter'); params.setBirthPlace('...'); // Set required and/or override optional fields here Person peter = new Person(params); The advantages of this solution are: - the parameters object can set optional values to their default values when it is created. Class 'Person' can simply copy these values without having to check whether they are 'null' or a special 'use the default' value. - If you need another field, and it is optional, you do not break existing client code. Just add the field to the parameters object. No changes have to be made to existing client code. Johan
From: topmind on 11 Feb 2007 17:25 Johan Stuyts wrote: > > Person peter = new Person(); > > peter.setName('Peter'); > > peter.setBirthPlace('.... > > ... > > > > Are there any platterns, suggestion or anti-plattern related to this > > problem? > > You can use a separate object to hold the parameters for the constructor: > PersonCreationParameters params = new PersonCreationParameters(); > params.setName('Peter'); > params.setBirthPlace('...'); > // Set required and/or override optional fields here > Person peter = new Person(params); > > The advantages of this solution are: > - the parameters object can set optional values to their default values > when it is created. Class 'Person' can simply copy these values without > having to check whether they are 'null' or a special 'use the default' > value. > - If you need another field, and it is optional, you do not break existing > client code. Just add the field to the parameters object. No changes have > to be made to existing client code. > > Johan Rather than create a whole new class just for parameters, perhaps attributes can be set and then have a "validate" or "submit" method: Person peter = new Person(); peter.setName('Peter'); peter.setBirthPlace('....'); peter.setMoreAttributesEtc(...); peter.save(); -T- oop.ismad.com
From: andrewmcdonagh on 11 Feb 2007 18:39 On Feb 11, 5:55 pm, "howa" <howac...(a)gmail.com> wrote: > for example, a Person class, I need to create a person using, e.g. > > Person peter = new Person('Peter', '....) > > the object creation might involved over 30 parameters, the advantage > is this call is atomic, rather than something like, e.g. > > Person peter = new Person(); > peter.setName('Peter'); > peter.setBirthPlace('.... > ... > > Are there any platterns, suggestion or anti-plattern related to this > problem? > > thanks. I find, that when I need to pass more than 6 parameters, the code base is shouting to me 'Your design sucks'. It sucks because I've negated to see that there are relationships between two or more of the parameters, that should be described using a dedicated class, and therefore a single instance of that class as a parameter. As for an anti-pattern, I'd say 'primitive obsession' is probably one of the biggest culprits. So using your example.... peter = new Person("Peter", 35, 123, "Sycamore Road", "Sometown", "Some county", "a postcode/zip code", "0044123 991199", ..............) Here, because we have 'primitive obsession' (i.e. using primitive types: String & ints) we are forced to send everything through as individual objects. Now, if we look for relationships between those parameters, the obvious one we see is the parameters that make up Peter's address. Oh hang on, that even gives us the missing classes name 'Address'. So by moving those 5 address related parameters into their own class, we can insubstantially reduce the parameter passing needed AND we have increased the quality and safety of our design. Address petersAddress = new Address(123, "Sycamore Road", "Sometown", "Some county", "a postcode/zip code"); peter = new Person("Peter", 35, petersAddress, "0044123 991199", ..............); So why did I say 'safety' of design? Looking at the original constructor: Person(String name, int age, int housenumber, String firstLine, String secondLine, String thirdline, .....) Its unsafe from a compile time checking point of view, as there is nothing to catch errors.... We could safety do.. peter = new Person("a postcode/zip code", 123, 35, "Sycamore Road", "Sometown", "Some county", "Peter", "0044123 991199", ..............); This would compile, but then the values would be wrong as 'Peter' would actaully be called 'a postcode/zip code' and he would be 123 years old instead of 35 and his post/zip code would be 'peter'. Now we don't need to go overboard with turning every thing into its own class, like the Address one, but the technique is useful and worth using when you see large parameter lists. hth Andrew
From: Jerry Coffin on 12 Feb 2007 00:51
In article <1171216519.131931.144410(a)v33g2000cwv.googlegroups.com>, howachen(a)gmail.com says... > for example, a Person class, I need to create a person using, e.g. > > Person peter = new Person('Peter', '....) > > the object creation might involved over 30 parameters, the advantage > is this call is atomic, rather than something like, e.g. > > Person peter = new Person(); > peter.setName('Peter'); > peter.setBirthPlace('.... > ... > > Are there any platterns, suggestion or anti-plattern related to this > problem? 30 parameters is almost certainly excessive -- I'd suggest some sub- objects to encapsulate some of the coherent pieces. An obvious one would be "address" or something on that order. From the looks of things, you have one address for the person's birthplace. It's probably fair to guess you have another for their current residence, and quite possibly a third for their work. Those probably shouldn't be contained within the object either -- it should contain a pointer/reference/whatever to an object that specifies a location. This is pretty basic database normalization, which the database guys have studied (in considerable detail) for decades. -- Later, Jerry. The universe is a figment of its own imagination. |