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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: jtc@dimensional.com (Jim Cochrane) Subject: Emtpy procedures (was Re: Module size (was Re: Software landmines)) Date: 1998/09/04 Message-ID: <6spqe2$q4l@flatland.dimensional.com>#1/1 X-Deja-AN: 387993540 References: <6snlos$bh6$1@hirame.wwa.com> <904912650snz@nezumi.demon.co.uk> <35EFFB78.21BBBED6@ksc.nasa.gov> Organization: Dimensional Communications NNTP-Posting-Date: Fri, 04 Sep 1998 16:43:25 MDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-04T00:00:00+00:00 List-Id: In article <35EFFB78.21BBBED6@ksc.nasa.gov>, Christopher P. Gariepy wrote: >Martin Tom Brown wrote: > >> > >He used to program for a living, but he's never done real work in an OO >> > >language. When I tell him the project has 510 classes, with 2871 methods, >> > >... >> > > >> > >I can't think of a short answer. >> > >> > They exist for the same reason that we put zeroes in numbers -- they are >> > place holders. >> >> Beautifully succinct. >> > >I'm fairly new to the OO methodology, and I can see a reason to, perhaps,have >methods with 1 line of code - especially if the method is used in >numerous places. > >But...I see no reason to have methods that contain no code at all, even if >they're meant for place-holders. I believe this could potentially create >a maintenance nightmare if the original designers of the system are not >involved in the maintenance of the system. > [I'll use C++ terminology below, since it is the language most people using or learning OO are familiar with.] The responses so far to this point have talked about pure virtual functions. However, there are also very good reasons to implement functions (that are not pure virtual) that have empty bodies. A need for this technique often occurs when the template method pattern is implemented (from the Gamma, et. al. patterns books - if you don't have a copy of this I would recommend borrowing or buying it). The template method pattern allows an algorithm to be implemented that can be specialized in different ways by means of polymorphism and dynamic binding. A simple example: class A { void process () { initialize (); do_process (); cleanup (); } virtual void initialize () {} void do_process () = 0; void cleanup () {} ...}; It is obvious from the function names that do_process will do the main work of the algorithm. In order to allow specialization of the algorithm, classes that inherit from A will provide an implementation for do_process that does work appropriate for the abstraction of that particular class. Classes that inherit from A can also redefine initialize (to do any needed initialization) and/or cleanup (to do any needed post-processing). The reason for providing empty implementations for these functions in class A is to allow a class that inherits from A to simply use the default implementation that does nothing. If, for example, most classes do not need to perform any cleanup, they could simply inherit the empty cleanup implementation. If cleanup was made pure virtual, each (non-abstract) class that inherited from A would have to provide its own implementation of cleanup, and most of these implementations would be empty. The template method pattern is a very powerful mechanism that is used in many good OO designs, including many re-usable framework libraries. Without empty function implementations, the power of the template method pattern would be much diminished. -- Jim Cochrane jtc@dimensional.com