Re: OOP can be simply summed up as 'passing messages to objects'


H. S. Lahman wrote:
Responding to Pillai via Daniel T....

This is my 1st year B-tech Seminar topic.Can anyone plaese give me
someone please give me some points for this????


I'm redirecting this from comp.lang.c++. Anybody want to help out?

The short answer is No. B-)

While peer-to-peer collaboration is crucial to OOA/D/P and separation of
message and method is crucial to decoupling implementations in OOA/D,
messages aren't really what the OO paradigm is about. If one wants a
thumbnail phrase I think a better one would be: basing software
structure on intrinsic problem space structure through abstraction.
Problem space abstraction is probably the only truly unique thing that
the OO paradigm brings to the table.


This is more or less the "objects model real world objects" definition
of "object". My observation is that roughly only 30% of OOP proponents
agree with this definition/view. If I remember correctly, Bertrand
Meyer and Robert Martin generally reject this "modelist" view. (OOP was
born purposely to solve physical simulations, such as loading docks, I
would note.)

Further, it is difficult to objectively measure whether something is
modeling the real world (domain) or not. It seems more of a
psychological/perceptual problem than a logical/math one.

For example, I don't see people and copiers and buses with method
interfaces sticking out of them. Their actions are a complex set of
interweaving rules that don't seem to match methods that I see.
Real-world actions often belong to multiple items/objects at the same
time, not one (which OOP generally expects). Thus, I see "methods" as a
"computing space" artifact rather than real-world abstraction.

H. S. Lahman

-T-

.

Relevant Pages

  • Re: Object identity
    ... And it is equally clear a different object of the Employee set exists ... "date" is a well-defined problem space concept so it can be abstracted ... make a distinction between that abstraction and its instantiation at run ... context and how much is unique to the problem in hand. ...
    (comp.object)
  • Re: Havent done anything real with OOP yet.
    ... seriously complicated and developing an OO simulation would be ... responsibilities to objects. ... problem space in an OO fashion. ... simplified to the same level of abstraction as the simulation assumptions. ...
    (comp.object)
  • Re: Object identity
    ... And it is equally clear a different object of the Employee set exists ... space entities. ... The notion of "date" is a well-defined problem space concept so it can be abstracted as an object. ... an established OOA/D author who defines an object as anything other than an abstraction of an identifiable problem space entity and who does not make a distinction between that abstraction and its instantiation at run time as a memory image. ...
    (comp.object)
  • Re: Abstract public member variales?
    ... You are surely correct that the domain allows categorization if I ignore maintenance. ... But when we abstract Person as an object we use abstraction to extract the invariant commonality of individuals _with respect to the problem in hand_. ... All I am suggesting here is that you can apply abstraction to the conceptual world of the game and identify useful classifications that will describe groups of game entities abstractly. ... Whatever you actually know about the problem space is fair game for abstraction, even if it isn't specifically in some SRS. ...
    (comp.object)
  • Re: Deinition of OOP needed for programming language documentation
    ... often devolves into a heap address without problem space semantics. ... > anyone doing programming irregardless of their knowledge of design. ... that is bleeding cohesion all over the map. ... >> was confused about the level of abstraction of your documentation ...
    (comp.object)