Interesting article on the shortcomings of the OO model


#1

http://java.sun.com/developer/technicalArticles/Interviews/livschitz_qa.html

She argues that objects (as now conceived in OO programming ) fall
short as an abstraction for reality. She says we need also to have
’processes’ and ‘conditions’. Though she never really defines these
terms, they do seem familiar from the Hardware Description Language
world. I suspect a process in this context is a block of code that
gets launched when a condition becomes true, but this is not like some
kind of if statement like so:
if condition do something

It’s more like:
process(condition) { something to be done }
process(condition2) { somethingelse to be done }

The two processes constantly monitor the conditions and when their
respective condition becomes true the code for that process is
launched. (this is how it is with HDLs)… of course, I could be
totally misinterpreting what she means by ‘processes’.

she also argues that we need new forms of code reuse other than
inheritance.

Speaking of which… I know this was discussed a year or two ago here,
but I find myself using inheritance less and less with Ruby. I’m much
more likely to use aggregation, mixins or to add methods to existing
classes. I actually can’t recall the last time I used inheritance.

I wonder if some of the ideas posited in the article might already be
taking shape among the dynamic languages like Ruby. Especially in
regard to her comment on refactoring being a very painful process.

Phil


(Robert) #2

“Phil Tomson” intc_ctor@yahoo.com schrieb im Newsbeitrag
news:c68ca8f2.0402131630.72097e11@posting.google.com

http://java.sun.com/developer/technicalArticles/Interviews/livschitz_qa.html

She argues that objects (as now conceived in OO programming ) fall
short as an abstraction for reality. She says we need also to have
’processes’ and ‘conditions’. Though she never really defines these
terms, they do seem familiar from the Hardware Description Language
world. I suspect a process in this context is a block of code that
gets launched when a condition becomes true, but this is not like some
kind of if statement like so:
if condition do something

It’s more like:
process(condition) { something to be done }
process(condition2) { somethingelse to be done }

The two processes constantly monitor the conditions and when their
respective condition becomes true the code for that process is
launched. (this is how it is with HDLs)… of course, I could be
totally misinterpreting what she means by ‘processes’.

That sounds quite technical to me. When regarding the abstraction "process"
and “condition” I prefer to think of them as "when a condition is met, the
process is started. If I do understand her correctly, it’s this level that
she’s talking about. Kind of hiding all that event sending of todays GUI
systems. Instead you just define somewhere “button x pressed AND NOT text
field y.empty => load file text field y.contents”.

she also argues that we need new forms of code reuse other than
inheritance.

Speaking of which… I know this was discussed a year or two ago here,
but I find myself using inheritance less and less with Ruby. I’m much
more likely to use aggregation, mixins or to add methods to existing
classes. I actually can’t recall the last time I used inheritance.

Yeah, when I’m doing Java I use inheritance sparsely, too. Most of the time
it’s some abstract base class or interface that is filled with
functionality.

Another interesting point that she raises are relationships. I don’t no
other language than ODMG (which is pretty much dead) that provides for
explicit definition of class relationships from within the language. There
is no corresponding concept to the lines we draw in UML diagrams between
classes. There are tools that are able to do code generation for various
types of relationships, but there is no such thing as a language level
definition of a relationship and its manipulations.

The thing that always strikes me about this is that those relationships
don’t belong to a single class but to two or even more classes. That makes
them difficult to express in OO languages which usually only know classes
and their features. (C++ is not an example against this since it’s by far
not pure OO.)

It would be nice to be able to do something like

relation OrdersOfCustomer: Customer(1) => Order(n)

and then

customerFoo relate:OrdersOfCustomer Order.new
customerFoo related?OrdersOfCustomer someOrder

or something similar…

I wonder if some of the ideas posited in the article might already be
taking shape among the dynamic languages like Ruby. Especially in
regard to her comment on refactoring being a very painful process.

Hm, currently I don’t see it there. You have Threads in Ruby, but not
processes that you just define and the system takes care of all the nifty
details (starting, stopping, waiting until all processes have terminated
etc.) Although it seems that this would not be too hard to do.

We have conditions and boolean logic in Ruby, but there no mechanism that
does automatic triggering of actions (yet). I imagine that it must be
difficult to devise a most general mechanism that is able to react on
arbitrary state changes and which is performant as well.

Interesting thoughts nevertheless!

Kind regards

robert