Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!lll-winken!ubvax!igor!rutabaga!jls From: jls@rutabaga.Rational.COM (Jim Showalter) Newsgroups: comp.software-eng Subject: Re: OO Design with "C" - Do we still get benefits Message-ID: Date: 23 Mar 91 23:03:05 GMT References: <1991Mar22.212448.21375@news.larc.nasa.gov> Sender: news@Rational.COM Lines: 50 >Would anyone here mind commenting on the use of object oriented >analysis and design principles with the "C" language? >From my own limited, but growing, understanding of OOD, it seems the >concepts itself natually promote good programming practices resulting >in lower maintenance costs. Your intuition is correct. OO is a way of looking at a problem to ferret out abstractions that have proven to be of value in a variety of projects (structured analysis/functional decomposition is another way to analyze a problem to ferret out abstractions, and much of the OO vs Them argument is an argument about the relative quality of the ferreted-out abstractions: I side solidly with the OO camp in this debate). OO is, therefore, a paradigm and a design technique more than an implementation issue. I have seen people do a superb job of OO with the eventual language of implementation being FORTRAN. Yes, something is lost in the translation, since the language of implementation does not support the design entities directly, but that doesn't detract from the merit of the original design. I strongly encourage your desire to use an OO approach, even if you stick with C as the deliverable language. (I also encourage you to start an in-house project to bring people up to speed on C++, so that in time you can be using a language that better supports OO.) >And lastly, we intend to share this code >with other aerospace engineers, who undoubtedly will not speak >Ada. Don't be too sure--our major market for Ada is aerospace. >SO, is there a tragic flaw in my assumption that the use of OOD in >analysis and design, but implementing the project in "C" will result >in "better" code than using the old functional decomposition methods? No flaw--go for it. >Does anyone have any idea if such an implementation will cause the >application to run any slower than a functionally decomposed >implementation?? It is possible to over-abstract things, resulting in performance degradation. This can be minimized by use of performance analyzers/profilers and code tuning (you collapse the abstractions in the bottlenecks). This is a common concern about OO approaches, but I think performance issues are more than offset by concerns about reliability, maintainability, reusability in functionally-decomposed systems. -- ***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd ever be able to find a company (or, for that matter, very many people) with opinions like mine. -- "When I want your opinion, I'll read it in your entrails."