Anonymous
Unregistered
|
|
While I know this is a very simplified example, it still contains a lot of fundamental flaws.
You have tried to solve the problem about the UI-components knowing about the implementation of the things it is going to display, by letting the (in your example) Employee object depend on the UI representation, which is Strings.
Implmenting values as Strings in the way you have done is not OO, it's a represantation of UI-values at the most.
With a get-method in Employee returning for example Money to the UI, you would leave it up to the UI to figure out how to display Money. There are numerous reasons this would make perfect sense: Sorting, roundings, formatting etc etc.
You let the class Money do the formatting to String. The Money class has no clue about how the UI wants to do the actual presentation.
The statement that getters and setters are bad is not proven by your code. Your code only proves that you will only present things in one way, and if you want it in another way you have to add more code to the Employee/Exporter.
So by that fact I think it's obvious that if you don't want your UI-objects to know about "implementations" then your business logic will have to know about UI-representation.
I tell my UI-objects what they get and how to use it rather than forcing the values unusable by throwing everything around as strings.
If Money.getValue() returns a double, then by contract both Money and the user object must know what they are dealing with.
Your example is about putting another object inbetween two communicating instances (this pattern is ofcourse very useful however), the rest is just a simplification/obfuscation with Strings.
|
Alexander
stranger
Reged: 09/05/03
Posts: 7
|
|
Have you read all of Allen Holub's articles? Are you arguing that exposing an object's implementation (in your example, Money.getValue() return double) is a better approach for GUI building? I feel that Allen has successfully refuted this point in previous articles. Maybe I have misunderstood your point.
|
Anonymous
Unregistered
|
|
I don't think that the representation of all attributes as String is intended by the author:
Quote:
In the current example, I tried to minimize that impact by using String arguments to pass information to (and get information from) the builders, but that's not always possible.
I think this pattern covers two main points:
1) Limitation of access to properties/attributes of objects to a few Builder classes: This minimizes the number of classes (and makes it easy to identify ) that you have to go through when attributes are changed/removed/added.
2) Invertion of caller relationship: Not the UI code calls the BO, the BO calls the UI via the builder indirection. This makes it more difficult for an object to make direct use of the BO's attributes. Thus a caller will think about implementing the new functionality as a capacity of the BO instead of a "static" class that provides an external service (which I see waaaaaaaay too often).
The point of this pattern is not to make it more easy to write the functionality, but to keep the programmer on track with his object-oriented design.
|
Anonymous
Unregistered
|
|
Hey Alexander,
It seems you are the only one defending mr Hollub ideas? Aren't you him? I just wondering he changed his name just to say there's more people that agree with him....
|
Anonymous
Unregistered
|
|
The solution doesn't support the argument. If the provideSalary simply returns a String instead of a double, int , or whatever. If getSalary() returned a String would this assuage the fears, I think not.
|
Alexander
stranger
Reged: 09/05/03
Posts: 7
|
|
No, I am not him. Look, you are of course entitled to your point of you; as is Mr Holub. However, if you don't glean anything from what he has to say, then don't read his columns. No one is forcing you to read them.
Additionally, if you don't have anything constructive to say - critism or otherwise - then please don't bother posting anything. No one gets anything out of it. We're all just trying to learn more, that's all.
cheers,
Alex
|
Anonymous
Unregistered
|
|
I didn't read his other articles before I read this one, no.
To me, returning a "double" isn't equal to 'exposing implementation'. To me representing money as a number is a lot more convenient than forcing it to a string which is pretty useless.
The implementation could actually use a String for the value for all I care. That's why you have the method instead of making the actual value public, isn't it?
So I guess that's where the disagreements are.
In the end I think this article should be more focused on the actual pattern, instead of trying to prove something about getters and setters which I believe isn't the main issue here.
|
Anonymous
Unregistered
|
|
Hehe, So funny, I thought that Alex was Allen too. You are not alone in your suspisions, Anonymous #1!
In any case, I wonder what Allen/Alex would say about WSDL, where all the data elements are completely laid out down to the smallest attribute. Does WSDL reveal the implementation? Here's a little scenerio where I hope shows you how it does not:
Working on a website that needs to communciate to a backend fulfillment system (place the orders, check inventory availability, etc). The new system that they are migrating to is Web Services based, and they have WSDLs for their backend system, they just haven't completed the implemetnation/set up network access for my team yet. To keep development moving, I took the WSDLs that they provided to us, used the JWSDP 1.3 to generate servier side stubs, and I made a 'dumb' implemetation of the webservices that will return a static value for inventory availablity, and always accept an order that is submitted. Later, I added the ability for the service to throw certain types of errors depending on the data that was sent to the service to let them test their error handling code.
When the delivery day arrives from the new fullfillment house, All I will need to do is point to the 'real' URL of the fulfillment web services, (aka: change the implementation) and everything will 'just work'.
This is the essence of 'hiding implementation details' that makes interfaces (and web services) so wonderful.
Quote:
Additionally, if you don't have anything constructive to say - critism or otherwise - then please don't bother posting anything. No one gets anything out of it. We're all just trying to learn more, that's all.
Alex/Allen, you seem to be the one who is failing to learn anything here, for even the critics of the articles point to something that they can agree with, but can you find no fault with the ideas presented in the article? Again, it seems that the only person who would have absolutely no issue with anything in the article is the author himself (assuming that the author wouldn't write anything he would intentionally disagree with), so your perspective on the articles is curious. Are these articles from AH perfection?
-Chris
|
mbmb
Unregistered
|
|
He is far from the only one. There are people who actually understand and base their code on what Holub actually says, and they are very happy with the results. But one does not appreciate what true OO gives him until he actually 'gets' it and starts using it. Then there is no going back.
Consider this: no matter what example _you_ think of to prove a point of your own, I can either claim it is way too complicatd, or I can shoot it down based on some "major problems" with its implementation (because of your simplifications) and claim that it proves none of your points as a result. This is EASIER than actually trying to understand what's going on.
This is what is happening here, I think -- many of the posts attack particular aspects of the solution (designed to make it simpler and understandable), but do not try to get the main point instead, mostly because they seem to be blinded with rage due to the main premise. So far I can see just a single critical post that "grabs the bull by the horns" so to speak; the rest are just hot air. The fact that you engage in character assasinations of random posters who do not share your point of view is another reason to look critically at _your_ motivation, not Alex's.
It is a pity that the JavaWorld forum sinks to this level, but I guess you will respond that Allen is guilty for that too, that I am Allen too, or something else like that. Oh well. At the end of the day this is your loss.
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
