Re: what's the future of Object Oriented Programming


Patrick May wrote:
"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
Patrick May wrote:
"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
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.

Nobody ever agrees on when to use which paradigm.

I was responding to your statement that people who find benefits
in OO techniques don't understand procedural and relational
techniques. That's not at all the case.

It is what I encounter.


Plus, mixing gajillion paradigms can create quite a mess and
confusion and translation effort between them.

The nice thing about software development is that it gives us so
many ways to cause ourselves problems. Your objection is just as
valid within a "single paradigm" as a "multi paradigm" environment.

I am not sure what you mean. Additional tools that add only marginal
improvements are often not worth it. Only add additional tools/layers
if it adds *significant* improvement. It makes staffing more difficult
for managers also. Perhaps as developers we don't care because staffing
is not our concern, but affects the bottom line.


I used the scare quotes because the term "paradigm" is overused
and emphasizes the differences between two somewhat arbitrary sets of
techniques at the expense of the similarities. OO is a superset of
procedural. It may be difficult to use an OO style interface from
some procedural languages, but the reverse is not often the case.

The solution to some problems is expressed better declaratively
than procedurally, others better in an OO style than declaratively,
still others better functionally than object orientedly (to coin an
inelegant phrase). Simply knowing these approaches allows one to see
more solutions. Having all of these techniques available is what
distinguishes a master developer from an apprentice.


Or somebody who wants to pad their resume with buzzwords.


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

I cannot remember specific details, but putting OO in the code did
not improve the app any way that I saw.

Your statements contradict my experience and that of many people
I've worked with. I'd like to understand where OO techniques have
failed to add value for other people and why that was the case. Any
specifics you can provide would help.

I have not seen code where it has clearly *added* value, outside of
systems software.


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.

To a point, but paradigm potpourri has its own downsides, as
described above.

Again, I haven't found this to be the case in general. I've been
using service oriented architectures (SOAs) over the past few years.
One of the advantages of SOA is that the implementation of each
service can use the most appropriate technology.

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?

Polymorphism is too course a granulation of variation management.

But where, specifically, have you used OO techniques and found
that it resulted in a greater amount of effort for the same functional
and non-functional capabilities that could have been more easily
delivered using only procedural and relational techniques?

http://www.geocities.com/tablizer/struc.htm


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.

For 90%+ of all biz apps I've worked on, it was, especially if
nimble/local database engines are provided to suppliment big-iron
DB's.

This doesn't correspond with my experience, nor with that of many
people I've worked with. What details can you provide about your last
three or four projects without violating any NDAs?

Not really. It's proprietary.


The most obvious case in which the centralized database
architecture cannot work is when a system must interact with an
external system. A vendor will send flat files and may even provide a
Web Service, but none will share a database.

Well, if they make tools that only use communication protocol X, that
is not the fault of the paradigm/technique itself. But web services and
flat files are merely transfer mechanisms. One could transfer stuff to
and from a database also using those.


Another example comes from telecommunications. Even a small
network operator will have a wide variety of systems including
billing, rating, CRM, MRP/ERP, provisioning, network management, OMS,
and MIS. Some of these systems will have been developed in house
while others are off-the-shelf packages. Numerous business processes
will require solutions that coordinate functionality from multiple
components, none of which share a database.

Yet another example comes from finance. Clearing and settlement
of trades requires matching (within fuzzy ranges), ordering (based on
multiple, sometimes conflicting priorities), provisioning, automatic
and manual loan generation, settlement, and synchronization with other
clearinghouses. There isn't a machine big enough to run a single
database that can support all this activity.

I cannot verify such scaling issues here, but if you need multiple DB's
for hardware reasons then so be it. One may have to divide no matter
what technique is being used in some cases.


Speaking of performance, another reason to discount the
centralized database architecture is that it can't always meet the
NFRs. The database becomes a single point of failure, but there is no
reason for most companies to stop accepting orders, for example, just
because one of the backend systems is down.

High-end Oracle servers have all kinds of fail-safe gizmos such as
mirroring and parellel updates if you have the money. But if you need
to split and decentralize for whatever reason, then so be it. However,
it just may result in lots of smaller failures rather than a few big
ones.

Hardware cost is another
significant issue -- it can be much cheaper to develop, deploy, and
operate a distributed system running on blades than the same
functionality on an F15k.

Are you saying that RDBMS are too expensive? There are a wide variety
of options both commercial and open-source, and RDBMS is a fairly
mature (road tested) technology compared to the alternatives.


The last project I can remember where I used a single centralized
database was to build a system to support clinical trials of new drugs
on humans. The functionality wasn't too complex, but the FDA
requirements were amazingly rigorous (which is to be expected when one
of the "adverse events" being tracked is "death"). At its core, it
was a CRUD system

It is hard to beat the A.C.I.D. features of RDBMS when losing or
curruption info is a no no. What alternative to ACID do you have in
mind?


I'd be interested in hearing about additional systems where this
architecture has proven useful.

"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?

I don't think they outright fail. They are just harder to get right
and are messier than alternatives.

How are they messier? What alternatives? What problem domains?

There are no consistent, tested, and documented rule for converting
biz logic to OO

OO isn't unique in this regard. If there were rules for
converting business logic into code, I'd automate it. Where possible,
I do. The implementation techniques are a separate issue.

I see far more variations or potential variations in OO designs than
procedural/relational ones. Relational normalization rules tend to
narrow the potential "creativity". Navigational (OOP) has no documented
equivalent. There are too many ways to do the same thing, and this
makes it harder to learn and absorb a newly-encountered set of
software.

Decent procedural usually breaks the problem down to a bunch of smaller
tasks or events that feed off the DB. One can even use the DB to track,
study, and report on the tasks/events. The "big picture" is usually
found in the schema's, NOT the program code. Again, it is like a bunch
of small shore villages that live off the Nile (RDBMS). I just see a
tangled web in OO with no easy way to query the web to study it. A
bunch of pasta is dumped on one's desk.


Patrick


-T-

.

Relevant Pages

  • Re: whats the future of Object Oriented Programming
    ... and they also have OO techniques to draw on. ... nimble/local database engines are provided to suppliment big-iron ... will require solutions that coordinate functionality from multiple ... centralized database architecture is that it can't always meet the ...
    (comp.object)
  • Re: whats the future of Object Oriented Programming
    ... and they also have OO techniques to draw on. ... nimble/local database engines are provided to suppliment big-iron ... will require solutions that coordinate functionality from multiple ... centralized database architecture is that it can't always meet the ...
    (comp.object)
  • File Fun
    ... Ok, I'm mulling over different techniques to solve a problem, and ... I'm weighing and experimenting with storing data in a MySQL database ... server somewhere, and just store the path to the file in the DB. ...
    (comp.lang.php)
  • Re: POD speed
    ... > mocking and belittling aimed at the database crowd, ... useful software was created prior to the ... advanced techniques developed since, because we got by without them in the past. ... I'm afraid I don't know what Maple is, but the other applications you listed are ...
    (comp.lang.java.databases)
  • Re: Rendering the page
    ... There are a variety of ways you can accomplish such functionality. ... Most of the techniques are covered here in detail: ... Steve C. Orr, MCSD, MVP ...
    (microsoft.public.dotnet.framework.aspnet)