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".
