If you read further, and go on to the follow-up articles, you'll find that all is not as it might appear to such a shallow glance.
Really?
4. The Teller object asks the Bank_records object for an empty Withdrawal_slip. (This object will be an instance of some class that implements the Withdrawal_slip interface, and will be passed from the Bank_records object to the Teller object by value (using RMI). That's important. All the Teller knows about the object is the interface it implements -- the implementation (the class file) comes across the wire along with the object itself, so the Teller has no way of determining how the object will actually process the messages sent to it. This abstraction is a good thing because it lets us change the way the Withdrawal_slip object works without having to change the Teller definition.)
5. The Teller object tells the Withdrawal_slip object to display a user interface. (The object complies by rendering a UI on the ATM screen using AWT.)
Looks like not seperating display and implementation to me. The Withdrawl_slip object is working directly with the UI. I don't see any way to interpret the above differently.
How about trying not to have too much of a knee jerk reaction to something you admittedly know so little about.
Then please, enlighten me: What is OO? Don't use metaphors--I've read way too many of them, all of them unsatisfying.
Saying traditional OO concepts (like accessors/mutators) aren't OO doesn't strike me as a useful definition.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l]
[select] |
Looks like not seperating display and implementation to me.
What I meant was, this separation of UI and object isn't necessarily all
its cracked up to be and just winds up relocating the coupling issues to
exist across different levels of abstraction. Acknowledging this and putting
the coupling where (the author believes) it belongs is the point of the
articles.
Then please, enlighten me: What is OO? Don't use metaphors--I've read way too many of them, all of them unsatisfying.
Saying traditional OO concepts (like accessors/mutators) aren't OO doesn't strike me as a useful definition.
So much OO code out there really amounts to procedural code with objects as
(sometimes intelligent) datastructures. It is hard to find exemplars of
OO code that can actually be described as implementing systems of
interacting objects. Most really good OO systems are simply too large
and complex to serve as teaching tools. However, if you are serious about
exploring OO, see Booch's "Object Oriented Design with Applications" for an
exception to this general rule.
| [reply] |
What I meant was, this separation of UI and object isn't necessarily all its cracked up to be and just winds up relocating the coupling issues to exist across different levels of abstraction. Acknowledging this and putting the coupling where (the author believes) it belongs is the point of the articles.
Very well. I happen to disagree. I'm in a project right now that requires different data to be viewed in different forms. One part of this application deals with generating reports for users. They might output an Excel spreadsheet or a pipe-delimited file or some HTML or a PDF. I cringe at the thought of attempting this by following the author's advice. By having the data stored in one object (which you can call a fancy data structure if you want) and given to a subclass of a ReportGenerator object solved this problem quite elegantly for me.
Many of his examples (like "what if we want to change the method to return a float instead of an int?") could be avoided by using a dynamically-typed language. What particularly bugs me is this statement:
Moreover, an attribute doesn't necessarily map to a field in the class. The salary might be stored in an external database, for example, with the Employee storing only the information needed to retrieve the attribute from the database . . . What, then, could a get_salary() function return?
Easy: the get_salary() does the database access for you and returns the result instead of some private variable. That's why you have accessors/mutators in the first place instead of declaring your internal variable public--because you might not want it to be an internal variable. get/set methods are just another part of the interface, and like any OO interface, it doesn't matter what happens inside as long as the input and output are consistant.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l]
[select] |
