From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10d15b,97482af7429a6a62 X-Google-Attributes: gid10d15b,public X-Google-Thread: 109fba,97482af7429a6a62 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,97482af7429a6a62 X-Google-Attributes: gid103376,public From: rmartin@rcmcon.com (Robert Martin) Subject: Re: C++ not OOP? (Was: Language Efficiency Date: 1995/04/21 Message-ID: <1995Apr21.184038.7182@rcmcon.com> X-Deja-AN: 101369038 references: <3mbmd5$s06@icebox.mfltd.co.uk> <3mcfbf$psl@acmez.gatech.edu> <3mgnkc$e3j@atlantis <3muaif$46u@atlantis.utmb.edu> <3n0lsu$nio@druid.borland.com> <3n0uvi$8jt@atlantis.utmb.edu> organization: R. C. M. Consulting Inc. 708-918-1004 newsgroups: comp.lang.c++,comp.lang.ada,comp.lang.cobol Date: 1995-04-21T00:00:00+00:00 List-Id: >pete@borland.com (Pete Becker) wrote: >> Suppose you are evaluating a new language, say, C+#, and you >> hear from a reliable source that it is a "pure OOPL". What conclusions >> can you draw about this language that would tell you whether it is >> better suited to your purposes than, say, C+$, which is not a "pure >> OOPL"? Curtis Bass writes: >The conclusions that I would draw are: > #1. All code must be attached to objects. > i. I will not be able to write a procedure that > is independent -- it must be attached to an object This does not guarantee that the stucture of your procedures or your objects will be in any way superior to those written in C+$. So of what use it it? > ii. It would behoove me to have an Object-Oriented > Design (as opposed to a Structured Design) of > the system before I start coding in C+#, because > writing structured code will not be an option. > (Yes, I can kludge it by having just one object, > and attaching all of the code to that object, but > the result technically would still not be an > example of "structured programming," but would > rather be an example of BAD OO programming). Saying that it is BAD doesn't eliminate it as an option. In any case, you could make the identical argument about C+$. It would behoove you to have an object oriented design! > iii. My programming team had better be fluent in OO > concepts before using C+#, because there is no > mechanism for writing structured C+# today, and > gradually growing into Object-Oriented C+# > tomorrow. This is the same argument as number ii, just rephrased. In any case it is just as true for C+$. Your programming team had better be fluent in OO if they are going to implement an OOD. > iv. Since it is a pure OOPL, there is a great > likelihood that the language itself is of > a fairly simple and elegant design. OTOH, > C+$ will probably be a very complex language, > since it supports two different programming > paradigms (structured and OO). I am sure that you cannot substantiate this claim. > Also, with > C+#, I can rest assured that the syntax is > uniform (all procedures will have an object > ID prefix). What do you mean? A prefix? Do you mean that all procedures will belong to an object? Isn't this your point i above? > C+$ would allow me to have SOME > procedures WITH an object ID prefix, and some > WITHOUT one. This could lead to confusion for > the maintenance programmers. How? > Also, such code > would represent a rather messy, inelegant > design, which would be less of an option in C+#. Why? Are designs with nothing but objects always cleaner than designs that sometimes have global functions? I'd like to see the proof of that. > #2. All data must be encapsulated within objects. > i. There will not be any variables that are global > to the application, unless they reside in a > "root" object. Even in this case, we can have > more control over their scope and accessability > than would be avalable in C+$. In C+$, any global > variable we have would be accessable by ANY > procedure we write. In C+#, this would not be > the case. Unless all procedures and data were in the same object. Then there is no control at all. > ii. I can create new data types more easiliy, by > deriving them from existing data types, then > changing only that which needs to be changed, > and inhereting the rest of the functionality > from the parent data type. Since C+$ is not > a pure OOPL, then variables are not objects, > and therefore I would not have this capability. In C+$ you would have this ability with any kind of variable you desired to have it with. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++