Re: Initialization Params for Controlled Types

[Robb.Nebbe@di.epfl.ch (Robb Nebbe)]

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