Comments on: How to Think About Object Oriented Design

By: Lars

Lars — Mon, 16 Oct 2006 23:24:14 +0000

From a low level and simple perspective, pbject orientation in Delphi is mainly procedural

programming with SELF being passed as a hidden parameter and a few other /syntactic sugars/

going on under the hood.

When people design OO code, they still eventually do some sort of procedural programming when

implementing the methods. Objects just allow us to reuse the procedures and keep the code a

lot neater than procedural code. That doesn’t mean you can’t reuse procedural code!

Oh, you can - look at all the reusable DLL’s people have written. The entire windows API.

Reusable procedural code can be inherited and modified just like objects can - it is just

messier doing it that way! It’s that simple - OO hides code and reduces the verbosity

of procedural code. It hides some brackets and incoming parameters.

OO can be emulated in Delphi without using any of the OO features - just use records and

pass SELF in to each procedure, using GET and SET calls instead of properties. The problem

with emulating OO using procedural code is that it ends up looking ugly - it’s all

about syntax sugar. OO let’s us be less verbose than procedural code (and cleaner).

By: mike montagne

mike montagne — Mon, 26 Sep 2005 14:29:40 +0000

Yes, I realize that. The real gist of OOP is indeed a difficult issue to put a readership’s hands around. Yet we are certainly within an evolutionary phase where almost all modern application development is OO. A reason we evidently use the same development tools, is evidently a mutual appreciation for the quality of the original abstractions indigenous to those tools. My apologies, if the tone is interpreted as merely critical. The intention was to encourage focus on what makes OO most excellent — which at the same time is to encourage what is vital to the continued health both of our favorite tools, and the entire public surviving by the excellence of underlying concepts. Yes, then: the general public *needs* to grasp the underlying issues, so that we all are empowered to prosper by OO Design. Thus as no article on OO Design will be finished until we altogether ratify a perfected formula for OO Design, in effect, the best that any of us can do to then is categorize the areas of effort, and how all together can be perfected.

By: Craig Stuntz

Craig Stuntz — Mon, 26 Sep 2005 13:58:47 +0000

Mike:

> …this article barely touches the surface

> of the concept and issues of OO Design…

That’s because I’ve only just started it. Read the highlighted section at the top of the article. There’s a lot fo work yet to do.

By: mike montagne

mike montagne — Mon, 26 Sep 2005 13:54:49 +0000

While perhaps a departure point for OO design discussion, this article barely touches the surface of the concept and issues of OO Design. If its readership were not intended to be developers or prospective developers, I can understand the desire to avoid the traditional topical categories. But I think instead, it would be more useful to preface those topics with more tangible definitions of OO programming and OO Design issues. One undoubtable virtue of OOP (expressed in terms for the broadest potential audience) is it is a pattern, without which, almost all application software would far more expensive, and difficult to deliver. OOP, in effect, is a pattern by which software development specializations are delegated, and by which, in the end, application development is reduced to the more manageable responsibilities, of authoring what makes the given application unique. I believe these are the real, driving forces behind the broad adoption of OOP. Perhaps that makes the respective aspects of encapsulation the most important virtue of OOP; and perhaps that further means that these aspects of encapsulation deserve the initial intentions of such a basic article on OOP Design. David, by way of the indicated site, expresses many reservations which, imho, only point out the many human failings to achieve the ideals of OOP. I believe, because of personal work, that on the contrary, we are on the cusp of formalizing a specirication for *how* to design OOP. It is easy to ding OOP for excessive resource footprints for instance. But to contribute to a perception of OOP, it is more useful to suggest the pathway to the perfection of OOP. Obviously, object-oriented techniques are as readily perfected as any other possible programming approach. I would say, on the contrary, that because of the potentials of encapsulation, that OO Design is even *more* readily perfected. There is no *inherent* disadvantage to OOP whatsoever. What I advocate, is the perfection of specifications for trees of descendants, exceptionless programming, and optimized resource deployment — all of which are readily perfected in OO design. The very encapsulation of OOP, and revision of the OO architecture of descendant trees readily possible by OOP, make OOP by far the most preferrable medium for achieving these objectives.

By: David Melchior

David Melchior — Fri, 01 Jul 2005 05:54:34 +0000

I think that http://www.geocities.com/tablizer/oopbad.htm makes an interesting starting point for an OOP discussion. (Not that I agree with the claims made on the page)