This is a problem which always bugs me about VOs, I would love to know if anyone can suggest a solutions to this:
Assuming you want to represent a business object which has a lot of state, you have a few choices: Option 1: You have a VO containing a constructor with a billion parameters. Problem: It looks horrible; it is a bitch to write against and you potentially loose valuable compile-time checking (esp. if a lot of the parameters have the same type) Option 2: You have a parameterless constructor and a billion accessors/mutators (or public fields depending on your religous persuasion). Problem: You immediately have the possibility of superficially correct VOs which are only partially created. i.e. The developer has to remember to call all required setters - it is not compile-time enforced. (If you are of the private field persuasion, you also have the overhead of writing (or getting something to write for you) a billion getters and setters) Option 3: You scratch you head searching for some "business relevent" rule about which fields are compulsory to an object's correct existence and which are optional; you then put the compulsory ones in a constructor and set the remainder through setters. Problem: The grasping for a business-rule is desparate: For a few objects there may be a valid set of rules which lead to a nice short constructor, but for most there will not. Fundamentally you are trying to invent a business rule to match the code you want to write rather than the other way round. Option 4: You scratch your head again, this time trying to compile the fields into smaller meaningful objects, in the hope of getting to the point where your main VO has a small enough constructor. Problem: Often many of the fields in the VO will be fundamentally unrelated and not suitable for grouping. It makes the job of actually setting or getting one of these nested fields a nightmare: having to construct, or take apart unnecessary objects to get at the data you want. Does anyone have the winning Option 5? Rich On Thursday 16 May 2002 13:11 pm, Eric Williams wrote: > Mike, your position strikes me as a little extreme (or, maybe, > tongue-in-cheek). But it is not uncommon to see a Java programmer > occasionally write tuple-based data structures using Hashtables (or Maps). > > The problem with tuples or Hashtables, as I see it, is two-fold. First, the > program becomes less readable and harder to understand, undermining its > maintainability. And second, you lose compile-time checking of access to > the data structure, causing you to deal with problems (such as misspelled > field names) later in the development cycle. > > I am an advocate of simple value object structures. They provide clarity of > code and compile-time checking of field names and types. I'm still waffling > about the accessor methods vs. public fields argument. I tend to think > accessors are busy-work, providing very little benefit in the value object > world. I am, however, considering the "value objects should be immutable" > position. It's not something I have done before, especially since many of > the value objects I have dealt with contain dozens of fields (and I don't > like constructors with more than 3 or 4 parameters). But you can still > create immutable value objects using public (final) fields. > > -eric > Eric Williams > [EMAIL PROTECTED] > ObjectWave > > > Classic OO Approach: > > Place the get/set methods for name, address, etc. AND the > > getCustomersInRegion method in the Customer class. > > > > Service-Based Approach: > > ONLY place the get/set methods for name, address, etc. in a > > CustomerBean class, and place the getCustomersInRegion method - and all > > other non get/set data methods - in a seperate CustomerService class. > > I believe both these approaches are actually at odds with good object > oriented design. I think it is bad design because it results in multiple > classes with the same basic responsibilities: hold data, present data. > Whether it is a Customer class with a bunch of getters and setters or an > Account class with a bunch of getters and setters, the basic > responsibilities are the same and thus the functionality is the same. This > redundancy leads to software bloat: often hundreds of boring classes. As a > band-aid for the management problems associated with this code bloat, > people > have developed all sorts of fancy and complex "tools", e.g. code > generators. > > I believe that good object oriented design applied to this problem begs for > more abstraction. All of the boring getter-setter classes can be replaced > by one data holding-presenting class, e.g. class Tuple or class Row. The > business logic is kept in separate business processing classes. But the > audience crys out, "But your data is not encapsulated! How can this be > good > object oriented design?". I answer this with a question, "How is the data > less encapulated in a Tuple class than in a class where every data member > is > accessable by a getter and setter function?" The crux of the issue is that > the data in a data processing application is NECESSARILY unencapsulated. > For if the data was truely encapsulated, the application would perform no > useful work because noone could see the data! The data is not something > internal to the application, rather it is something public that the > application is performing operations on. > > Mike Bresnahan > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". ============================================================================== This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. All information is the view of the individual and not necessarily the company. If you are not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication and its attachments is strictly prohibited. If you have received this email in error please notify: [EMAIL PROTECTED] ============================================================================== =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
