Re: what's the future of Object Oriented Programming

"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
Patrick May wrote:
"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
H. S. Lahman wrote:
Reuse is nice but not a major consideration in using OO
techniques. The real objective of OO development is to create
maintainable applications in the face of volatile requirements
over the product life cycle.

To answer your title question, OO programming is still the only
game in town for producing maintainable software.

I beg to differ. There is no evidence for this, at least outside of
systems software.

Actually, there is considerable evidence that some of the
concepts typically grouped together under the term "object
oriented" provide significant benefits in managing dependencies
between software components, which results in more maintainable
software.

The only examples I've seen are from people who didn't know how to
use procedural and databases well.

You need to get out more. ;-)

I started out after college working for a CASE tool company that
ate its own dog food by using the tool to deliver projects. It was
entirely based on E-R and dataflow modeling (Gane-Sarson,
Yourdon-DeMarco, etc.). We delivered a lot of systems on time and
within budget. Fast forward a few years and I encountered OO for the
first time in the guise of Zortech C++. Some of the techniques were
unlike what I knew, but many were logical extensions of good
procedural practices. OO was more evolutionary than revolutionary and
definitely a valuable addition to my virtual toolbox.

Most of the experienced developers I know who have proven their
ability to deliver quality software have similar backgrounds. They
understand and use the procedural and relational approach very well,
and they also have OO techniques to draw on.

I don't know of anyone who has used OO in a large project and
regretted having those tools available.

I've heard mumblings of things not going so smooth. Satisfaction
surveys by Yourdon showed no improvement.

Creating new things in the real world can be difficult. Complex
projects never go completely smoothly. In my experience and that of
other competent software developers I know, OO techniques provide
mechanisms for managing dependencies and complexity that result in
better quality software delivered more reliably.

Where have you used OO techniques and found this not to be the
case?

Further, OOP tends to *create* large projects.

This is not my experience. Having more techniques available to
manage dependencies and complexity helps to make systems as simple as
possible. Restricting the available tools adds to the effort.

What project have you worked on where the use of OO techniques
resulted in a larger amount of effort for the same level of quality
that could have been attained more simply without them?

Procedural/relational projects tend to break big problems into
smaller applications that feed off of databases. The database is the
Nile and small apps are villages on the shore. Thus, one mostly only
has to know about the schemas and a few sanctioned library routines.

First, OO techniques permit just as much if not more functional
decomposition as procedural. OO subsumes procedural techniques.

Second, the "big central database" architecture is not
universally applicable. Even when it is possible to architect a
system that way, it does not always provide the best structure for the
solution.

"The only game in town" is overstating the case a bit, because
similar techniques can be applied in most non-OO languages and
functional languages, for example, offer still other approaches.

Out of curiosity, what do you mean by "systems software?"

Tool building, such as OS's, RDBMS engines, compilers, device
drivers, network engines, etc. Polymorphism seems to have more use
there.

I have personally seen OO techniques used successfully in domains
ranging from broadcast video to pharmaceuticals to finance to
telecommunications. These are commonly considered "business
applications." Where have you seen OO techniques fail in such
systems?

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@xxxxxxx | (C++, Java, Common Lisp, Jini, middleware, SOA)
.

Relevant Pages

  • Re: whats the future of Object Oriented Programming
    ... applications), parsing (also widely applicable to business ... The techniques used to manage the dependencies between components ... It is sweeping in that it generalizes over every single OO ... everyone is entitled to his or her opinion. ...
    (comp.object)
  • Re: Full life cycle development
    ... techniques -- even poorly applied -- being worse than the code of the '70s and '80s when even Structured Programming was rarely practiced and applications were produced on a pure ad hoc basis. ... Some of the worst code I have ever seen was produced by academics. ...
    (comp.object)
  • Re: whats the future of Object Oriented Programming
    ... Some of the techniques were ... smaller applications that feed off of databases. ... the "big central database" architecture is not ... DB engines in tools in the 90's, setting app development back a decade. ...
    (comp.object)
  • Re: RCU+SMR
    ... techniques in *applications* to justify the complexity cost, and the effort required to learn how to use them correctly. ... techniques directly in applications; not using "infrastructure" libraries that happen to be implemented using lock-free stuff, but that do not expose it to their clients. ...
    (comp.programming.threads)
  • Re: Mixing P/R philosophy with OO (within J2EE).
    ... experience with OO to understand that competent developers are most ... OO, procedural, relational, functional, and other techniques are ... who have actually delivered working enterprise-scale systems. ...
    (comp.object)