Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!netcomsv!jls
From: jls@netcom.COM (Jim Showalter)
Newsgroups: comp.object
Subject: Re: Negative Reaction to OOT
Message-ID: <1991May15.172102.4969@netcom.COM>
Date: 15 May 91 17:21:02 GMT
References: <10954@rama.UUCP>
Sender: netnews@netcom.COM (USENET Administration)
Distribution: na
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 43
Originator: jls@netcom.netcom.com

jec@rama.UUCP (Judy Chapman) writes:

>Here is a co-workers opinion on OOT. I am trying to promote  
>the use of OOT - how do I respond to this??
>	3) What design methods can be used to prevent architects from 
>       creating an architecture that compromises the long term success of
>       a product.

If the coworker is truly serious about the LONG TERM success of a product,
then he/she should be concerned about issues of readability, maintainability,
extensibility, reuse, and protection from design degradation. Object-oriented
techniques tend to produce code that is far better at addressing these sorts
of concerns than code written the Old Country Way, which tends to suffer from
namespace pollution, global visibility to things that should be encapsulated,
inflexibility to change, etc. Focusing on the short term at the expense of
the long term is not beneficial to the bottom line, as any number of project
managers can attest. Cutting corners always comes back to haunt a project.

>	4) What are the benefits of Object Oriented Programming.  Are there
>       current methods or techniques that can provide the same benefits 
>       at lower costs.

Abstraction, information hiding, data encapsulation, enforcement of design.
Natural mapping between problem space and solution space, understandability,
maintainability. Reuse, extensibility, flexibility. Portability through
isolation of base hardware.

As for all the questions about performance, try to remind your coworker
that, on average, 10% of the code uses 90% of the CPU. Thus, it is not
necessary to focus on performance throughout the closure of the code:
only on those parts of the code that constitute a bottleneck. The REST
of the code can be written with more of an OO focus. It is not necessary
to break a bottle to eliminate a bottleneck: just widen the neck of the
bottle (or add a second neck). Judicious use of performance monitors
and code tuning can achieve the required speed while retaining the bulk
of the OO approach, particularly if the architects plan ahead and confine
the time-critical portions of the code to a limited number of subsystems
(with narrow interfaces to the rest of the system).
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 *****************
* Proven solutions to software problems. Consulting and training in all aspects*
* of software development. Management/process/methodology. Architecture/design/*
* reuse. Quality/productivity. Risk reduction. EFFECTIVE OO techniques. Ada.   *