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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c83a22003c320b45 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-11-18 05:13:37 PST Path: nntp.gmd.de!xlink.net!news.dfn.de!swiss.ans.net!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!epflnews!dinews.epfl.ch!di.epfl.ch!Robb.Nebbe From: Robb.Nebbe@di.epfl.ch (Robb Nebbe) Newsgroups: comp.lang.ada Subject: Re: Initialization Params for Controlled Types Date: 11 Nov 1994 10:44:24 GMT Organization: Ecole Polytechnique Federale de Lausanne Sender: nebbe@lglsun3.epfl.ch (Robb Nebbe) Distribution: world Message-ID: <1994Nov11.110531@di.epfl.ch> References: <1994Nov4.134412.10010@unix.brighton.ac.uk> <39ebsa$129i@watnews1.watson.ibm.com> <1994Nov10.152352.27015@unix.brighton.ac.uk> NNTP-Posting-Host: lglsun3.epfl.ch Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: 1994-11-11T10:44:24+00:00 List-Id: In article <1994Nov10.152352.27015@unix.brighton.ac.uk>, je@unix.brighton.ac.uk (John English) writes: |> Norman H. Cohen (ncohen@watson.ibm.com) wrote: |> : There is a good reason the example is not convincing: It violates the |> : principle that the inheritance hierarchy should reflect an IS-A |> : relationship. CurrentAccount should be derived from BankAccount only if |> : a "current account" is a special kind of "bank account". If it is, then |> : it should have all the properties of bank accounts--including the ability |> : to open it by specifying just a name. After all, when you add |> : CurrentAccount to the class rooted at BankAccount, you are asserting that |> : all the primitive operations of BankAccount can be applied to |> : BankAccount'Class objects with any tag. |> |> I've had to think about this one for a while -- I didn't find it convincing |> but couldn't figure out why. The idea is that yes, a current account is a |> kind of bank account. BankAccount is an "idealised" bank account -- no |> transaction will be refused, no charges will be made, no interest is payable. |> Classes like CurrentAccount can then extend this into something more |> realistic and so can SavingsAccount etc. All these account types will |> have the common properties inherited from BankAccount (deposit, withdraw, |> check balance, print statement...) If it is an "idealized" bank account, i.e. it describes what all bank accounts have in common then it should be abstract and operations like open should also be abstract. A similar example is mamals. A mamal is an idealization of the commonality between a certain number of animals but there is no one animal that is "just" a mamal; they are always something more. You need the right tool for the job. Just because you can come up with a solution in C++ using constructors does not mean it is a good solution. In fact I would program the solution in C++ much the same way I would in Ada. Pounding a nail in with a screwdriver is not a good solution; just because C++ happens to include a really big screwdriver thus making it feasible to pound a nail in with it doesn't change the fact that it would still be easier to use the hammer (which C++ also provides). |> And of course, there is no way in 9X to force Open to be called and you |> have to take extra care (e.g. an Initialised flag) to prevent it being |> called more than once. C++ constructors are a neat solution to these |> problems -- they are always called exactly once per object, they are |> not inherited, they automatically call the base class constructor, and |> they can have parameters. Ada 9X requires a lot more effort to avoid |> subtle errors IMHO. Actually all Ada 9X requires is a better design. The actual account type probably shouldn't even be visible. What should be visible is a type Account_Number which is not limited private that refers to a real account. This more closely models the real world and resolves any of the problems I have thought of. Maybe you see some that I haven't? - Robb Nebbe