Re: what's the future of Object Oriented Programming


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.

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. Further, OOP tends to
*create* large projects. 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.

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


Sincerely,

Patrick


-T-

.

Relevant Pages

  • Re: Business objects, subset of collection
    ... Non-CRUD/USER applications are not the sort of thing one tucks into eMails.] ... SQL databases sucks for searching large data sets, ... In CRUD/USER processing that is largely irrelevant because data is accessed once by each solution and seek time dominates the access performance issues in those situations. ... Lets say you want to find all unpaid invoices. ...
    (comp.object)
  • Re: Merging 2 "almost" identical databases.
    ... identical databases used by 2 almost identical applications into one ... client so they can easily merge the two databases. ... Debugging, testing, complex, report/logging not so fancy/clear, ... application only or also to the schemas? ...
    (comp.databases.oracle.server)
  • Re: Merging 2 "almost" identical databases.
    ... identical databases used by 2 almost identical applications into one ... client so they can easily merge the two databases. ... Debugging, testing, complex, report/logging not so fancy/clear, ... application only or also to the schemas? ...
    (comp.databases.oracle.server)
  • Re: Business objects, subset of collection
    ... might get faster applications than you would if you had used a SQL ... That is why databases using caching. ... there mainstream SQL databases wouldn't perform ... Lets say you want to find all unpaid invoices. ...
    (comp.object)
  • Re: Merging 2 "almost" identical databases.
    ... identical databases used by 2 almost identical applications into one ... client so they can easily merge the two databases. ... Debugging, testing, complex, report/logging not so fancy/clear, ... application only or also to the schemas? ...
    (comp.databases.oracle.server)