From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA20458 for caml-redistribution; Wed, 3 Feb 1999 16:41:35 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA02199 for ; Tue, 2 Feb 1999 15:42:44 +0100 (MET) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id PAA01233 for ; Tue, 2 Feb 1999 15:42:39 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id PAA19153; Tue, 2 Feb 1999 15:42:25 +0100 (MET) From: Markus Mottl Message-Id: <199902021442.PAA19153@miss.wu-wien.ac.at> Subject: Re: Classes: when and where? (long) (was: looking for a nail) To: dsyme@microsoft.com (Don Syme) Date: Tue, 2 Feb 1999 15:42:25 +0100 (MET) Cc: caml-list@inria.fr (OCAML) In-Reply-To: <39ADCF833E74D111A2D700805F1951EF0F00B94F@RED-MSG-06> from "Don Syme" at Feb 1, 99 04:48:15 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: weis [snip] > but until then I feel the jury is out. (IMHO, given the contorted nature of > many OO-based attempts at abstraction, one might feel the jury could have > given a preliminary verdict some time ago ;-) ) > On the question of project failures: I would certainly blame the failure > and/or slow-progress of several projects I've seen on the mis-application of > OO design techniques, in particular on the over use of inheritance and > subtyping as an abstraction technique, and the over use of abstraction in [snip] If things do not work so fine with OO, it would be a bit too early to blame this paradigm for failure. I think the problem is a totally different one: the design approach. Thinking back about courses in software engineering (with OO), the design approach taught was mostly "from top down". In my first projects I almost often failed completely to implement the design I developed without fundamentally changing it. A severe example: it took me quite some weeks to develope a class system for a specific project. When it was implemented as designed, I noticed that I had overlooked many necessary properties to make it work as it should. So I started to change it. It became worse and worse until I finally decided: let's kill this beast. I tore out all algorithms / functions, etc., which I would need anyway, put them together into small components that, again, would be needed anyway. Then I did the same with these components and when I was ready, it more or less worked "out of the box" - within less than two days. This "lesson" showed me that the top-down approach is not such a good method - at least for my style of programming. All that counts in the long run is: when does the program/prototype work. Instead of investing a lot of effort into designing "class hierarchies" or "interfaces", I now begin immediately with implementing small components, of which I know that they will have to be in the final system anyway - no matter, how "important" they seem from a "higher-order" point of view. When I have all these small components, I try to build with them the next "layer of abstraction" that will bring me closer to the final result - and so forth. This doesn't seem to be so problematic with modules: I think that modules enforce a coding style that focuses on "the component" - not so much on the "system view". If the module works, which is much easier to achieve because of the smaller size/complexity, it is truly reusable. But if I fail in the design phase of an OO-system to correctly see all dependencies between the classes/objects, I will be in deep trouble, because then I have to manage the whole system complexity at once. So if you say, that there was an overuse of abstraction techiques, it might well be due to the wrong "direction" of development: they tried to begin with the abstractions instead of with the components. It is probably not a matter of "how abstract" something is, but how this abstraction came into existence... Best regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl