Re: Message Builder vs. a Build Method?
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Tue, 14 Mar 2006 15:26:52 GMT
Responding to Kk_oop...
Hi. I have a class called TestRequest. This is a message that I am
sending to another component. Some of the data that goes into this
message are created by applying complex algorithms. So I'm wondering
whether I should make a separate TestRequestBuilder class that takes
calculates data then sticks this data into the TestRequest class. The
Builder class would encapsulate all the complex algorithms for making
the data that needs to go into the TestRequest class. The other
alternative we are considering is to just give the TestRequest a
"build" method. This method would contain the code we were going to
put in the TestRequestBuilder class.
You could go either way, depending on the specific context. Your Builder notion is just another way of describing some sort of factory object akin to the GoF construction patterns.
I would be inclined to go with the builder approach on general principles because initializing the object's data is part of instantiation and the rules and policies of instantiation are usually quite distinct from the rules and policies that govern collaborations during the problem solution. So it is <usually> a good idea to encapsulate them separately from the collaborating objects. IOW, it is basic separation of concerns.
Another, more aesthetic, argument is that instantiation of objects just requires ensuring that their attributes have the correct values. Those values simply define a state that is recorded in attribute state variables. That is, the process of determining what those values should be is usually a matter of context outside the object itself; instantiating the object itself normally should not be concerned with that external context.
OTOH, as Daniel T. suggests, sometimes the initialization requires unique processing for initialization that is clearly intrinsic to the object itself. In that case, using the object constructor has merit. For example, a SoftwareDeveloper object might have baseSalary and burdenedRate as attributes. However, for performance reasons one might also provide a private totalSalary attribute that is dependent on the other two. That dependence is a business rule that is not only intrinsic to SoftwareDeveloper, it is intrinsic to the /implementation/ of SoftwareDeveloper so it is tough to justify delegating it to some other factory object.
However, an initialization method in the object itself may practical value in such cases. Constructors tend to be fragile and it is difficult to manage errors when they occur in a constructor scope, so it is usually a good idea to keep the processing in constructors as simple as possible. When the initialization of attribute data requires complex processing AND it seems like is intrinsic ot the object, that justifies having a separate initialization method that is invoked immediately after the constructor. It is then the responsibility of the factory object invoking the constructor to know that the initialization method also needs to be invoked as part of the initialization.
Bottom line: use the builder when the values are dependent on external context (the usual situation); use the constructor when they are clearly intrinsic to the object semantics (pretty rare IME); use a method when they are intrinsic and the processing to determine them is complex.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
.
- References:
- Message Builder vs. a Build Method?
- From: kk_oop
- Message Builder vs. a Build Method?
- Prev by Date: Re: Design by contract and unit tests
- Next by Date: Re: optimization
- Previous by thread: Re: Message Builder vs. a Build Method?
- Next by thread: Re: Design by contract and unit tests
- Index(es):
Relevant Pages
|