Re: OOP in Ruby?

On 23.05.2008 00:15, James Britt wrote:
Robert Klemme wrote:
Without wanting to start an indepth discussion about OO, but aren't these just two sides of the same medal? The message metaphor seems to lean a bit more on the client side while the ADT view is a bit more about how messages transform internal state (although ADT is mainly about observable state through sequences of method invocations). In the end, in both cases an instance holds state which is changed via method invocation / method sending and the implementation determines how the state may be manipulated.

Here's the key difference to me: Taking a message-orient POV, you do not assume that messages == methods. You think in terms of how an object does things internally, and then how it will handle messages.

I believe there is usage for both approaches - even within the same project: usually I create classes from the outside, i.e. I decide about their responsibilities, their interface and then I decide how they should be implemented. In other cases, e.g. when implementing a particular algorithm I probably will first think about the internals and then decide which input or interface a class needs.

In both cases though clarifying responsibilities of a class (-> CRC cards) is the first and most important step IMHO.

In Java the assumption is that any message you send has to map to a particular method. It does not encourage the same degree of encapsulation and emphasis on behavior being distinct from implementation.

I am not sure I get your point here. Looking at e.g. interfaces in java.util what else is this than a separation of behavior (e.g. map lookup) from the implementation (HashMap, TreeMap)?

In some ways it is similar to the difference in behavior-driven development and test-driven development.

Point of view matters.

At least as a means for reasoning about how one does software development and which alternative approaches are around.

Thank you for your input!

Kind regards

robert

.

Relevant Pages

  • Re: Does Python really follow its philosophy of "Readability counts"?
    ... interface is what's documented as being the interface. ... We're told Python doesn't have private attributes. ... internals were inaccessible from Python code. ... always believe that their reason is a good reason. ...
    (comp.lang.python)
  • Re: Read-only, as opposed to const member
    ... They never even know the underlying accessor code was changed ... >> should care about. ... If it takes a month to propogate interface changes ... is about, keeping those internals private. ...
    (comp.lang.cpp)
  • Product Internals
    ... In the thread "Wireless in Linux needs HELP", ... > information about the internals of their products. ... companies wish to hide the details of how to interface with their product. ... reasons why. ...
    (comp.os.linux)
  • Product Internals
    ... In the thread "Wireless in Linux needs HELP", ... > information about the internals of their products. ... companies wish to hide the details of how to interface with their product. ... reasons why. ...
    (alt.os.linux.suse)
  • Product Internals
    ... In the thread "Wireless in Linux needs HELP", ... > information about the internals of their products. ... companies wish to hide the details of how to interface with their product. ... reasons why. ...
    (comp.os.linux.setup)