smd@rehder.larc.nasa.gov (Steve Dahmen) (03/23/91)
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. Our project seems to invite an OO approach because of the data organization. I considered using C++, but none of the developers here are trained in it, we don't have decent manuals for it, we'd rather not take out time to get a compiled compiler on our machines, and chances are we won't want to pay for developers with C++ knowledge just to maintain the code. And ADA, well, that's a whole nother ball of wax; yet I don't think Silicon Graphics has an ADA compiler anyways. In addition, we don't need to implement some of the more object language-oriented features such as the real-time messages, etc. And lastly, we intend to share this code with other aerospace engineers, who undoubtedly will not speak C++ or Ada. 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? Does anyone have any idea if such an implementation will cause the application to run any slower than a functionally decomposed implementation?? Lastly, might there be any SE papers out there connected with this topic? Thanks in advance for your insights, Steve Dahmen Vigyan Research Corp. -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Steve Dahmen, Systems Analyst (804) 864-4519 (W) M/S 365, NASA Langley Research Center Hampton, Virginia 23665 smd@rehder.larc.nasa.gov
metzger@convex.com (Robert Metzger) (03/23/91)
In article <1991Mar22.212448.21375@news.larc.nasa.gov> smd@rehder.larc.nasa.gov (Steve Dahmen) writes: >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. Our project seems to invite an OO >approach because of the data organization. > >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? When CONVEX began development of the Application Compiler (new product that performs interprocedural optimization on applications written in FORTRAN and or C) we decided that we wanted to use an object oriented approach. At that time, all that was available to us was AT&T C++ V1.2, which had numerous bugs and missing features. So we designed the whole system using objects, and then implemented in C mimicking C++ as we could. We certainly benefitted from designing the system in terms of objects, and the data abstractions we implemented by hand were helpful. We completely re-implemented the internals of some objects with minimal pain, and we added new sub-classes without much problem either. If we were starting the project today, we would use C++ as an implementation language. Other development projects which started after ours have used it successfully to build large system software products. AT&T C++ V2.1 is a much better piece of software than 1.2 was, and there are limits to what you can do without assistance from the language. So, yes, you will get some benefit from OOD and a C implementation, but I think you should reconsider using C++. -- Robert Metzger CONVEX Computer Corp. Richardson, Texas Generic Disclaimer: I write software, not CONVEX Corporate Policies. "The only legitimate function of government is to protect its citizens from harm or property loss by violence, stealth, or fraud. All else is tyranny."
jls@rutabaga.Rational.COM (Jim Showalter) (03/24/91)
>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."
smith@glinda.ctron.com (Larry Smith) (03/25/91)
Tried to email this, but it bounced: In article <1991Mar22.212448.21375@news.larc.nasa.gov> smd@rehder.larc.nasa.gov (Steve Dahmen) writes: >Would anyone here mind commenting on the use of object oriented >analysis and design principles with the "C" language? > In my experience, mostly with the Motif widgets, any attempt to use C for o-o programming will lead to a large morass of Obfuscated C Contest material. >From my own limited, but growing, understanding of OOD, it seems the >concepts itself natually promote good programming practices resulting >in lower maintenance costs. Our project seems to invite an OO >approach because of the data organization. >I considered using C++, but none of >the developers here are trained in it, we don't have decent manuals >for it, we'd rather not take out time to get a compiled compiler on >our machines, and chances are we won't want to pay for developers with C++ That is true. Object-oriented design is the only new coding technology to have proven benefits to modern software construction. But, sadly, I must state that C just does not support it well, and you will spend more time enforcing the discipline needed to do o-o programming in C than if you had gotten a copy of AT&T cfront and used that. For all that C++ is basically a superset of C, it's best use makes it a whole new langauge. The advantage for you is that it makes your learning curve less steep. >knowledge just to maintain the code. And ADA, well, that's a whole >nother ball of wax; yet I don't think Silicon Graphics has an ADA >compiler anyways. In addition, we don't need to >implement some of the more object language-oriented features such as >the real-time messages, etc. And lastly, we intend to share this code This statement is meaningless. Exactly what *is* a "real-time message" and how come I have never run into the term in ten years of o-o programming? If you are referring to message-passing, the concept does not exist in C++, it's a "method call" and works just like a function call. If you're talking IPC, it's IPC, and the language is irrelevent. If you are confusing IPC with Smalltalk-like "message passing" go and get a book on the subject, you don't know enough about object programming. >with other aerospace engineers, who undoubtedly will not speak C++ or >Ada. If they can't can't learn enough C++ to read your code they are not smart enough to deal with the weird code and funny organization you will need to do object-oriented programming in C. > >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? >Does anyone have any idea if such an implementation will cause the >application to run any slower than a functionally decomposed >implementation?? Object-oriented code runs as fast as any other kind unless you use special features provided by most object-oriented languages as tools. Such things as late binding and multiple inheritance *do* cost time. Straightforward use of object-orientation with compile-time binding costs nothing. Note that these features are usually provided, but are not truly needed, for o-o design. They are a convenience. A very great convenience, to be sure, but a convenience, not a necessity. Object-oriented systems will *always* be easier to build and maintain than traditionally-structured programs and FAR easier than the usual hacked messes that pass for "modern software". But it requires foresight and a clear design to get maximum code re-use and flexibility. You can't start coding o-o software without clear goals in mind, you will *never* finish and you will *never* have bug-free software. > >Lastly, might there be any SE papers out there connected with this >topic? Lot's of them. SP&E has a lot them, SIGPLAN often has discussions, but it sounds like you really need a basic course in the subject. There are a number of good books on the subject, but it's been years since I read any, so I will leave it up to others to give you more concrete suggestions. > >Thanks in advance for your insights, One insight that you might find useful: memory management is a total nightmare in a large o-o application. C++, with its constructors and destructors, and other such tools is only *barely* adequate to do the job. Finding the massive memory leaks that any significant application will have is a long and terribly terribly painful exercise. The very worst package for this sort of thing - lost memory and bashed memory structures due to dangling pointers - that I have ever seen is the Motif widgets package from OSF. It is unquestionably the worst, it leaks huge amounts of memory, it is delicate to fix bugs in, it's organization is a nightmare and it is all object-oriented and in C. Save yourself, get C++. Larry Smith smith@ctron.com
UH2@psuvm.psu.edu (Lee Sailer) (03/29/91)
In article <1353@glinda.ctron.com>, smith@glinda.ctron.com (Larry Smith) says: >In my experience, mostly with the Motif widgets, any attempt to use C for o-o >programming will lead to a large morass of Obfuscated C Contest material. It certainly might. One good idea is to look carefully at how OBJ-C, C++, that that other C+Objects language (CO2?) are *imlemented*. Pick one as a model, and sort of do things that way. Appoint one member of the team to be a sort of OO lawyer, who examines other people's code to be sure that code is using the OO paradigm where it could and should. Probably the biggest obstacle to building an OO-like system in vanilla C using traditionally trained C programmers is that they will naturally tend to turn out traditional, vanilla C programs, no matter what the design looks like.
pat@megatest.UUCP (Patrick Powers) (03/30/91)
I've been maintaining a C program for which the implementor chose to implement inheritance himself. It is very to extremely verbose, and the pointers to functions are very difficult to trace, much worse than gotos. It is possible, even a good idea, to write C code in an object oriented style, but inheritance requires compiler support for all practical purposes. I'm sure there is some ingenious way to do it with macros, but if you are going to go that far why not use C++? -- --
sakkinen@jyu.fi (Markku Sakkinen) (04/08/91)
In article <1353@glinda.ctron.com> smith@glinda.ctron.com (Larry Smith) writes: >Tried to email this, but it bounced: >In article <1991Mar22.212448.21375@news.larc.nasa.gov> smd@rehder.larc.nasa.gov (Steve Dahmen) writes: >>Would anyone here mind commenting on the use of object oriented >>analysis and design principles with the "C" language? [a lot of text deleted] >>Lastly, might there be any SE papers out there connected with this >>topic? > >Lot's of them. SP&E has a lot them, SIGPLAN often has discussions, but it >sounds like you really need a basic course in the subject. There are a number >of good books on the subject, but it's been years since I read any, so I will >leave it up to others to give you more concrete suggestions. At least have a look at Grady Booch's new (1990) book "Object-Oriented Design with Applications"! Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)