You raise a good point, but I think there is something to be said for keeping class count down and keeping those UML diagrams less cluttered.
It's a balancing act, that would be my contention. I never like saying one approach is "bad" or "improper", because inevitably someone can come up with an example of a time it was the perfect answer. Best practices become best practices because they are recognized as being an optimal solution in *most* cases. That doesn't make a solution that isn't considered best practice wrong, it simply makes it not a best practice :) But if you are confronted with an application with 10 classes vs. one with 50, which will be more difficult to get your head around? It's not a straight-forward answer... those 10 classes might be monsters while the 50 may be 10 lines a piece, but on the other hand, grasping the relationship between 50 classes can be more difficult than 10, even if the 10 are much more complex. And which is easier to maintain? Balancing act. :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, May 12, 2005 11:59 am, Leon Rosenberg said: > > On Thu, 2005-05-12 at 17:07 +0200, Pedro Salgado wrote: >> So you mean, on your actionform you use: >> >> The html form attributes + (this is what I understand for input) >> The collections needed to present combo/list boxes (and other options) >> (this >> is what I understand for output) >> >> I don't think #2 is this one. This is #4. > > Maybe we should define exactly what input and output is. > > Example: you have objects Book and Author. Each Book has a field author, > which links to an Author object (Id, Name, FirstName, etc). > Let us give the Book two properties, so its not that empty: Title and > ISBN. > > Now you have a Book editing dialog, in this dialog you will have > > title and isbn rendered as input fields. > and author rendered as select, with appropriate authorsCollection, > filled with all available authors. > > So the Class BookForm has 4 attributes: > String title, isbn, author; > Collection authorsCollection; > > All 4 attributes are solely needed for input (as for now at least) and > therefore the form is used as #2 scenario. > > On another page, which has nothing to do with the edit dialog you > present a book previously searched by some criteria. > > If you are using scenario #4 you will reuse the BookForm here. The > problem with this approach is, that you don't need the half of BookForm > properties, what you need instead is: > BookPresentationBean > with String name, title, authorDescription: > authorDescription is a field describing the Author object like: > author.getLastName()+", "+author.getFirstName() (or whatever your html > demands) and is typically filled by the Action. > > As you see, you don't need the BookForm to present a Book, since you > need other properties for presentation, as for editing. > So if you are working with scenario #4 and reusing BookForm here, you > are actually _misusing_ the BookForm. Further, it's a bad design > approach, because, if you need to change the search result page and add > or remove some properties (a book rating by other users etc), you are > changing the edit dialog too, without actually knowing it (or exlicitely > search, aehm, where do i use this form?). > > That's why I think, that scenario #4 is actually a bad choice, because > it creates dependencies, which are very hard to manage (especially after > some months). > > regards > Leon > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
