Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: (OT) OOUI: multiple views in an object.

by hardburn (Abbot)
on Oct 31, 2003 at 16:29 UTC ( #303594=note: print w/replies, xml ) Need Help??


in reply to (OT) OOUI: multiple views in an object.

Never ask an object for the information you need to do something; rather, ask the object that has the information to do the work for you.

So Class::DBI isn't OO? Darn.

All objects must provide their own UI.

Dear Lord. Whatever happend to seperating the display from the implementation?

I've always gotten the feeling that, for having such a huge impression on modern programming, OO is really poorly defined (thus all the flame wars about "Language X is OO vs. No it isn't"). If you ask a CS major or look it up in a book, you'll usually get some metaphor about animals, and how you can do certain things to all animals, and you can do more things to specific kinds of animals, etc. However, I've been completely unsatisifed with this metaphor (and other common metaphors in various reference materials) as it doesn't really say what OO means for programming.

This is the first article I've read that has, finally, given a decent definition of OO. And if this is what OO is, I don't want any part of it.

----
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

Replies are listed 'Best First'.
Re: Re: (OT) OOUI: multiple views in an object.
by Anonymous Monk on Oct 31, 2003 at 17:17 UTC
    Dear Lord. Whatever happend to seperating the display from the implementation?
    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.
    This is the first article I've read that has, finally, given a decent definition of OO. And if this is what OO is, I don't want any part of it.
    How about trying not to have too much of a knee jerk reaction to something you admittedly know so little about.

      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

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://303594]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2021-01-23 09:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?