Anonymous
Unregistered
|
|
So, instead of "name=employee.getName();", we have "employee.export(myBuilder);name=myBuilder.getName();" Same difference - just hiding the getter (and setter) behind a pointless (and maintenence-unfriendly) layer of indirection.
|
Zing
Unregistered
|
|
Not really, because you never need the name.
If it's on the web page, you would use an HTMLBuilder.
If it's on a component, you would use a JComponentBuilder.
If it's supposed to go into a database, you would have an SQLBuilder.
Inventing a useless builder which does nothing but expose the get/set methods and using it as an argument against the original proposition, doesn't help anything, or anyone at all.
|
Anonymous
Unregistered
|
|
Quote:
...
If it's on the web page, you would use an HTMLBuilder.
If it's on a component, you would use a JComponentBuilder.
If it's supposed to go into a database, you would have an SQLBuilder.
...
what if you need just the first name, last name, or first and last name only, etc... i suppose you will make a fine-grained builder. if you have a fine-grained builder, you don't need any of the other builder. in many cases, this approach is using cruise missile to knock out $10 tent (rumsfeld, i think).
|
Anonymous
Unregistered
|
|
Quote:
what if you need just the first name, last name, or first and last name only, etc...
Thats exactly the point! You don't(!) "just need the ..." whatever it is. You want to do something with it. Display it somewhere, Store it somewhere. So you Code a DisplayJustTheNameBuilder or if you like it more flexible a DisplayBuilder("JustTheName").
As with all Design Patterns they are overwight in this small examples, but highly useful in any full sized project.
|
Anonymous
Unregistered
|
|
Actually you might need first name, then some fields of another object and then the last name. In this particular example it doens't make much sense, but it often does.
Typically a user interface made based on the objects proves to be very unuseful. A good user interface is based on the process (or use cases) for the user, which uses parts from various objects.
|
Anonymous
Unregistered
|
|
Quote:
Typically a user interface made based on the objects proves to be very unuseful. A good user interface is based on the process (or use cases) for the user, which uses parts from various objects.
I agree with the above statement. I would argue that there are two things going on here. The first is the 'hiding' of the domain layer. I typically do this kind of hiding through DTOs (Data Transfer Objects), the author calls them Importer and Exporter objects. The second is the movement of data between the domain objects and the Importers/Exporters. I typically do this kind of thing via Assemblers.
In my most recent project we've had great success with using Commands tailored to the user interface. Each command is responsible for providing a set of input and output DTOs, and assembling and disassembling them. The command uses the domain layer to do it's work, but completely hides the domain objects by using the UI specific (NOT domain specific) DTOs.
What I like about the authors idea is in moving the assembly/disassembly into an interface contract promoted by the domain objects. My DTO, which might promote data found in 4 different domain objects, could implement 4 Exporter interfaces. My command could then pass my DTO to the four domain objects I'm interested in getting data from. Note that my DTO might not do anything with 80% of the data passed to it through the Exporter interfaces. If I change a 'property' of one of the domain objects, I only need to promote that property appropriately though my contracted Exporter interface. I avoid having to change all of my command assembler/disassemblers.
I like it. I'll have to do some more thinking about it.
|
Unregistered
|
|
----
I typically do this kind of hiding through DTOs (Data Transfer Objects), the author calls them Importer and Exporter objects. The second is the movement of data between the domain objects and the Importers/Exporters.
----
I think you missed the point. The author is _not_ moving data around. The "domain-specific object" as you put it, is just "the object, the original and only object. It's data is not copied into other objects. A DTO is a xerox copy of the original, which is exactly what Holub is trying to avoid.
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
