Re: Confessions of an "OO Foreigner"

From: Joseph Katnic (usrr_at_post.no.mail)
Date: 01/02/04 

Date: Fri, 02 Jan 2004 19:53:54 +0800

Of course, then nobody will know what "functions" a given component
will do, except the component itself.

You will be able to query the component and get the information, but at
the end, some warm body will have to read all these desriptions, decide
which amongst the many thousands of interfaces to use, code the usage
and continue.

I suspect that one of the failures of "reuse" of code is that it's
quicker for someone to write new code, than to search for an existing
solution and match the existing code to the selected solution.

As I see OO, it's an attempt to design a new language for each problem
domain. After all and Object is just basically extending the definition
of a variable to user definable types. A method is just the definition
of a new operation on a object. So you can say that a CUSTOMER is
something that can be INVOICED, REFUNDED, SHIPPED-TO etc.
So for programmers, there is a HUGE investment in learning the new
domain language. Furthermore, because each domain is different, there
are different language elements so that you cannot leverage what you
previously learnt.

Furthermore, unlike most computer languages, the elements of the
language are not even consistant in the same domain. That is sometimes
the CUSTOMER class will create CUSTOMERS, other times the may be called
CLIENTS etc. At least for a given programming language a STRING is a
STRING. This aids memory, which all humans are limited in function.

Sure you can create a OO system that reduces to:
ORGANIZATION.work()
But this tells you what about the system?

Finally, most programmers/developers are not comfortable in thinking in
the problem domain. Hell, most users can't think in the problem domain.
The job of Design is to map the problem domain onto the computing
facilities. As such, I see OO as a design philosophy that aids
designers and does not much in terms of increasing programmer
productivity.

In article <bfdfc3e8.0401010949.6fe114ef@posting.google.com>, Thane
Hubbell <thaneh@softwaresimple.com> wrote:

> EXACTLY Peter. This is why I think this promise will be fulfilled
> with "Web services" - which provide a published interface and UDDI for
> "discovery" of what's available.
>
>
> Peter Lacey <lacey@mb.sympatico.ca> wrote in message
> news:<3FF38550.E71B9EEB@mb.sympatico.ca>...
> > Thane Hubbell wrote:
> >
> > > "Howard Brazee" <howard@brazee.net> wrote in message
> > > news:<bsuoqu$opk$1@peabody.colorado.edu>...
> > > >
> > > > I have seen lots of promises and believe some but not all of these will
> > > > be
> > > > fulfilled. Some have already been fulfilled. Some will never be
> > > > fulfilled.
> > >
> > > In my mind - the biggest "promise" of oo - is Reusability. This has
> > > failed in the past because of the inability of designers to actually
> > > perform the task of reusing the objects.
> >
> > Seems to me that this is because of two things that aren't generally
> > available (for objects,
> > subroutines, or any "previously written" or "not written here" things):
> > - a precise, detailed, description of what the object does (I've been told
> > that you can include
> > externally-viewable comments but it's not likely that these would be
> > detailed enough)
> > - an index (by function) of what objects are available!
> >
> > In other words, a lack of proper documentation!
> >
> > (Although I have no real idea of what standards these two things should adhere to).
> >
> > PL

Relevant Pages

  • Re: OOP can be simply summed up as passing messages to objects
    ... The most important benefit to system design from SOAs over OO will be forcing programmers to think more about objects and communicating with them strictly with messages than what they're accustomed to with C++ and Java. ... One has to go to a 4GL like UML with abstract action language before one can program pure message-based collaborations as intrinsic language abstractions. ...
    (comp.object)
  • Re: Smart programming languages
    ... common "top down" approach to language design. ... E.g, Suppose you have three language features A, B and C. ... make C a high-level feature implemented in terms of A and B. ... provide programmers with all 3 features. ...
    (comp.programming)
  • Re: Python syntax in Lisp and Scheme
    ... > coding guidelines as the language becomes laxer. ... > other aspect of an engineering design, ... problem domain I have worked on, yet I use it virtually exclusively. ... We simply restrict ourselves to the cases where we *can* analyze ...
    (comp.lang.lisp)
  • Re: Design Patterns and Functional programming
    ... SOFTWARE patterns. ... The language provides software patterns for ... The developer has to design the software to solve ... It depends on the problem domain. ...
    (comp.object)
  • Re: Age thread.
    ... But let's say that this was scientific-- that we actually had some kind of statistically significant view into the ages of the people using Forth, not just the ages of the people who choose to respond to a newsgroup post in comp.lang.forth. ... I could apply *my* agenda and make the conclusion that the reason why the mean age is 49.6 is because younger programmers focus less on language and more on methodology. ... That they honestly don't care about language, and care more about bigger issues like design patterns, frameworks, and the like. ...
    (comp.lang.forth)