Comments on: Refactoring Day 23 : Introduce Parameter Object http://lostechies.com/seanchambers/2009/08/23/refactoring-day-23-introduce-parameter-object/ Just another LosTechies site Thu, 13 Sep 2012 07:11:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: ryzam http://lostechies.com/seanchambers/2009/08/23/refactoring-day-23-introduce-parameter-object/#comment-421 ryzam Mon, 24 Aug 2009 04:17:33 +0000 /blogs/sean_chambers/archive/2009/08/23/refactoring-day-23-introduce-parameter-object.aspx#comment-421 I think its time to thing parameter object as a message.Using message it would give you Ubiquitous Language which minimize the gap between domain expert and developer I think its time to thing parameter object as a message.Using message it would give you Ubiquitous Language which minimize the gap between domain expert and developer

]]> By: schambers http://lostechies.com/seanchambers/2009/08/23/refactoring-day-23-introduce-parameter-object/#comment-420 schambers Sun, 23 Aug 2009 12:10:38 +0000 /blogs/sean_chambers/archive/2009/08/23/refactoring-day-23-introduce-parameter-object.aspx#comment-420 Excellent point Michel. This leads into Day 25 where I talk about Design By Contract checks that would be an excellent example of input validation in a scenario like this. Excellent point Michel. This leads into Day 25 where I talk about Design By Contract checks that would be an excellent example of input validation in a scenario like this.

]]> By: Michael Kjörling http://lostechies.com/seanchambers/2009/08/23/refactoring-day-23-introduce-parameter-object/#comment-419 Michael Kjörling Sun, 23 Aug 2009 11:58:16 +0000 /blogs/sean_chambers/archive/2009/08/23/refactoring-day-23-introduce-parameter-object.aspx#comment-419 You also need to be very careful with input validation since (especially when adding fields to the parameter object class that is already used in multiple places throughout your codebase) it is very easy to forget one field/parameter out of the bunch. Much more so than if you need to go through the parameter list when calling the method; in that case, if you miss a spot, the compiler will alert you. In some cases it might even be worth creating a method on the RegistrationContext class such as Create() that takes a Registration object and calls Create() on that after verifying that all fields are properly filled in. This is a slight deviation from the separation of responsibility principle but since the RegistrationContext class cannot exist on its own anyway, it seems like it could be an acceptable trade-off. Something like this: public class RegistrationContext { // ... parameter fields go here ... public void Create(Registration registration) { // ... validate all context class fields and fail if appropriate ... registration.Create(this); } } You also need to be very careful with input validation since (especially when adding fields to the parameter object class that is already used in multiple places throughout your codebase) it is very easy to forget one field/parameter out of the bunch. Much more so than if you need to go through the parameter list when calling the method; in that case, if you miss a spot, the compiler will alert you. In some cases it might even be worth creating a method on the RegistrationContext class such as Create() that takes a Registration object and calls Create() on that after verifying that all fields are properly filled in. This is a slight deviation from the separation of responsibility principle but since the RegistrationContext class cannot exist on its own anyway, it seems like it could be an acceptable trade-off. Something like this:

public class RegistrationContext
{
// … parameter fields go here …

public void Create(Registration registration)
{
// … validate all context class fields and fail if appropriate …

registration.Create(this);
}
}

]]>