jec@rama.UUCP (Judy Chapman) (05/15/91)
Here is a co-workers opinion on OOT. I am trying to promote
the use of OOT - how do I respond to this??
--- co-worker's negative opinion starts here ---
Subj: Object Oriented Programming Evaluation Ideas.
List of evaluation criteria for Object Oriented Programming or Design.
1) Speed.
a) Does the Dynamic linking of data structures to their member
functions cause poor speed performance for large magnitudes
of objects.
Possibly compare the access for a simple object about 500,000
times using a language that dynamically links functions to
objects (such as C++), versus an Object Oriented access system
written using no dynamic function pointing and simple data
hiding techniques.
b) Check speed of member function invocation/execution to
that of conventional data abstraction mechanisms to establish
cost of dynamic Object-->Function invocations.
2) Use of Dynamic Memory.
a) How much memory is wasted on function pointers to functions.
Is it allocated once per object, or once per object type. Is
this compiler dependent ?
3) What design methods can be used to prevent architects from
creating an architecture that compromises the long term success of
a product.
4) What are the benefits of Object Oriented Programming. Are there
current methods or techniques that can provide the same benefits
at lower costs.
5) During implementation of large systems that depend heavily on modal
operation, are Object Oriented Programming techniques a large
hinderance ?
There may be more for, but these come to mind for now.
--- end of other person's opinion ---
Thanks in advance for your help.
Judy Chapman
jec@sc.harris.combarmar@think.com (Barry Margolin) (05/15/91)
In article <10954@rama.UUCP> 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?? > 1) Speed. With many current OO language implementations, there is some amount of performance traded off for the software engineering benefits of OO programming. Is this list in priority order? If so, you may have a hard time convincing this guy that OO programming is a good thing. > b) Check speed of member function invocation/execution to > that of conventional data abstraction mechanisms to establish > cost of dynamic Object-->Function invocations. Be careful with this comparison, as it's easy to compare apples with oranges. It's not fair to compare generic function invocation with ordinary fuction invocation, because generic functions are doing much more. It's more appropriate to compare generic function invocation with a case statement where each case invokes a function, since that is the most similar conventional programming construct. > 2) Use of Dynamic Memory. > > a) How much memory is wasted on function pointers to functions. > Is it allocated once per object, or once per object type. Is > this compiler dependent ? Many languages only need at most a single per-object pointer to a per-type function table. C++ only needs this if virtual functions are used. Of course, a compiler can do it anyway it wants to, so it's compiler dependent whether a particular implementation actually uses only this much (but I think most of them do). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jls@netcom.COM (Jim Showalter) (05/16/91)
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. *
johnson@cs.uiuc.EDU (Ralph Johnson) (05/16/91)
In article <10954@rama.UUCP>, jec@rama.UUCP (Judy Chapman) writes: |> |> 3) What design methods can be used to prevent architects from |> creating an architecture that compromises the long term success of |> a product. It is good to realize that this is a problem. Architectures must be tested. The way to test an architecture is to build something with it. If it is designed to be reusable then you will have to build several "somethings" with it. You will probably find something wrong with your architecture. It is imperative to fix it, even though this means that you have to revise all the systems that you have built with your architecture. There are some design methods that can be used to reduce the chances of having problems, but there is no design method (for anything) that guarentees success the first time. To engineer is human. It is funny that people know this about programs but don't seem to realize that it is just as true of architectures. Ralph Johnson
jls@netcom.COM (Jim Showalter) (05/16/91)
>There are some design methods that can be used to reduce the chances >of having problems, but there is no design method (for anything) that >guarentees success the first time. To engineer is human. It is >funny that people know this about programs but don't seem to realize >that it is just as true of architectures. An architecture needs to be prototyped, just like anything else. The initial design of the architecture is theory; the initial prototype is experiment. For large projects with complex architectures, it is reasonable to make a number of successively better passes at the architecture, each with a refined prototype. This is NOT a waste of money or an unecessary delay--it is the only way I'm aware of to stand any reasonable chance of success. It is quite acceptable to build a prototype that represents 5-10% of the total final size of the project in SLOC--for a million line project, this is 50-100K, all of which may well be thrown away except for the overall subsystem decomposition and set of exported interfaces. The cost of prototyping an architecture can be more easily justified if it spans more than one specific project: indeed, it makes excellent business sense. Suppose, for example, some company has a division that specializes in building air defense systems and air traffic control systems. Using the typical approach, each new such system would be built using a blank sheet of paper approach. How much more sensible it is to acknowledge the area(s) of specialization, and commit division-wide resources to devising an architecture sufficiently general to be used for all such systems. This "line-of-business" focus when designing an architecture is rare, but I have seen it used on a series of four ship designs with a resulting reuse of 70% and a savings to the customer of $117 million. -- **************** 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. *
davidc@vlsisj.uucp (David Chapman) (05/17/91)
In article <1991May16.001902.19888@netcom.COM>, jls@netcom.COM (Jim Showalter) writes: |> An architecture needs to be prototyped, just like anything else. The |> initial design of the architecture is theory; the initial prototype |> is experiment. For large projects with complex architectures, it is |> reasonable to make a number of successively better passes at the |> architecture, each with a refined prototype. This is NOT a waste of |> money or an unecessary delay--it is the only way I'm aware of to |> stand any reasonable chance of success. Here's another, perhaps more pithy, way of saying what Jim just said: If you don't build a prototype you end up shipping one. David Chapman {known world}!decwrl!vlsisj!davidc vlsisj!davidc@decwrl.dec.com
bd@hpopd.pwd.hp.com (Bob Desinger) (05/21/91)
Judy Chapman (jec@rama.UUCP) quotes a co-worker's worries about a lack of speed in an OO program. The dvi program (posted a week or so ago to comp.sources.misc) used to be C. When the author migrated it to C++, it got faster. I don't have any timing figures, but the point is that OO techniques don't necessarily imply a slow program. bob desinger