Anonymous
Unregistered
|
|
Wouldn't it have been easier if you'd have just said that getters and setters should be Strings? Aren't "Importers" and "Exporters" just a way of exposing accessors and mutators that are all of type String?
|
Mohamoud
Unregistered
|
|
Quote:
Wouldn't it have been easier if you'd have just said that getters and setters should be Strings?
Perhaps, the answer is Yes that it would be easier, however, we can also, imagine a situation were we started with an Employee Object with String getters and setters and then with a little bit of refactoring we properly, eliminated the accessors and mutators.
Of course, the question then, becomes why do we need to refractor and eliminate the getters and setters? And why apply the Builder pattern, as Allen shows in the article?
I think, if for no any other reason, it is becouse of Allen's Critical fact that ".... The pattern does NOT... expose business-object implementation details to anyone EXCEPT the Builders."
And that will make the code a whole lot more maintainable and extensible.
Hope this helps ...
|
Anonymous
Unregistered
|
|
Quote:
I think, if for no any other reason, it is becouse of Allen's Critical fact that ".... The pattern does NOT... expose business-object implementation details to anyone EXCEPT the Builders."
But you are not exposing any implementation details. You are exposing Strings, which may or may not reflect the type used in the implementation.
|
Anonymous
Unregistered
|
|
Quote:
But you are not exposing any implementation details. You are exposing Strings, which may or may not reflect the type used in the implementation.
Of course you expose implementation details. You say to a caller that you have an attribute with this name. This *is* an implementation detail. A normal caller should not have any direct relationship to your attributes. A business object should be some abstract (hidden) heap with a few methods on the surface that are clearly defined. It should not look like a C struct.
Naturally, you need some sort of dependency between attributes and view elements, because you have to query for the attributes in order to display them. However this relationship is kept only between the business object and the builders, so in case of a modification you don't have to change code all over your subsystem.
|
ounos
Unregistered
|
|
Quote:
Of course you expose implementation details. You say to a caller that you have an attribute with this name. This *is* an implementation detail. A normal caller should not have any direct relationship to your attributes.
This, and the whole article, does not make sense. The implementation of some methods (or attributes) are in no way exposed, so they can change. The only difference is, instead of making the calls:
obj.getAttr1();
obj.getAttr2();
...
, to implement an interface so that the calls will be made from a certain point. What is the point? This is plain wrong. It creates another dependency, where it is not needed. Look, for example, the way the HTML exporter implementation depends on the order of the method calls. Hooray. Why not give it the object and let it call whatever method it needs, in whatever order it needs, as many times it needs it. If you want to hide methods, provide an interface of the object that exposes only the methods you want.
Quote:
Naturally, you need some sort of dependency between attributes and view elements, because you have to query for the attributes in order to display them. However this relationship is kept only between the business object and the builders, so in case of a modification you don't have to change code all over your subsystem.
Say for some reason a method "SomeReturnType fooBar()" is required to change the return type, or the arguments. Why this very reason doesn't require the builder to change as well? This is equivalent, apart from a useless indirection between the object and the caller. And if someone really needs to change a method "without" requiring all depended code to change (impossible!), she can always just add the required method. (This is also the case if the method was defined in the builder too, as I said they are equivalent).
Lets see the initial example of the author:
Quote:
The problem with this approach is that the foregoing code makes a big assumption about how the Money class is implemented (that the "value" is stored in a double).
Firstly, the "stored in a double" assumption is totally wrong. The only assumtion is that the method getValue returns an amount in dollar.
Quote:
If, for example, you need to internationalize your application to support currencies other than dollars, then getValue() returns nothing meaningful. You could add a getCurrency(), but that would make all the code surrounding the getValue() call much more complicated
If you want to add i18n without breaking existing code, you just add the methods you need and keep the getValue method unaltered. It should keep returning amounts in dollars. What is the problem? You can't just change a public method without breaking compatibility. Big news. But the implementation can change any time. Before the generalization say the amount was indeed stored in a double field. After the changes it can still be stored in such a field, -or- the method would execute the conversion code behind the scenes.
As a conclusion, I find this article totally irrational. Can anyone articulate what this whole thing buys us?
|
ounos
Unregistered
|
|
An additional comment. One can't add an attribute to the business object without one of the following:
- creating two new "builder" interface which exposes/imports it
- modifying the existing builders, and break all the depended code
The 2nd wouldn't happen of course in the plain getters approach.
(By the way, disregard my comment on the HTML exporter, I didn't notice the final method was not part of the interface)
|
Annonymous
Unregistered
|
|
Quote:
Of course you expose implementation details. You say to a caller that you have an attribute with this name. This *is* an implementation detail.
Exposing an attribute reveals implementation details as much as an interface's collection of methods and method's args reveals the implementation details of the implementing class. You do realize that the purpose of using interfaces is to allow the modification of the implementation without effecting the caller, correct? (For a real world examples of this, look no further than the JDK's documentation of the LayoutManager interface).
|
Anonymous
Unregistered
|
|
Quote:
Exposing an attribute reveals implementation details as much as an interface's collection of methods and method's args reveals the implementation details of the implementing class. You do realize that the purpose of using interfaces is to allow the modification of the implementation without effecting the caller, correct? (For a real world examples of this, look no further than the JDK's documentation of the LayoutManager interface).
Of course the fact that you have a getFoo function of type Double does not have to mean that you have a foo attribute, but it does so in about 90% of the code that has been written by inexperienced "OO" (former procedural) programmers. They even think it's a good practice to add a get/set method for every attribute that exists. And this practice exposes implementation details, because the interface of a class looks like a collection of its attributes. The attribute "foo" might not make sense in another implementation of the class.
There might be some valid uses for get/setFoo methods, but in most cases it is not justified. Do we at least agree on this point?
|
Anonymous
Unregistered
|
|
I don't think you're addressing my statement at all.
Can I agree that it is possible to write inappropriate accessors and mutators? Yep! Wow, what a epiphany, you can write bad code!
It's too bad that so much emphasis is being put on accessors and mutators when it seems the point is to use proper data abstraction....don't refer to the value as a double, refer to it as Money, etc etc. However, even the other comments about the Money class are flawed: They talk about a constructor having 2 parameters, double and String (value and currency). What happens when double is deemed 'unsafe' (for those of you familiar with floating point arithmitic operations) and instead it SHOULD have been a BigDecmial...do you not still need to return to every instance Money is created and change the value passed in the constructor?
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
