Re: Q's about Obj-C
Re: Q's about Obj-C
- Subject: Re: Q's about Obj-C
- From: "Marco Scheurer" <email@hidden>
- Date: Tue, 16 Oct 2001 15:42:10 +0200
On Tue, 16 Oct 2001 00:22:48 -0400
Normand Rivard <email@hidden> wrote:
>
The concept of abstract class has _nothing_ to do with
>
memory allocation. It has to do with data modelling
>
and code maintenance. It is a software engineering issue,
>
not a memory management issue. When I declare a class as
>
abstract, I am really saying to the compiler : "make
>
sure no one ever try to instanciate this class, because I
>
(as a class designer) have decided that it doesn't
>
make sense." The idea here is to protect a design
>
against future (bad) maintenance.
As Ondra's code demonstrates, if you really want abstract
classes, you can have them in Objective C too. The
difference is that the error would be caught at runtime
instead of compile time. Now you may argue that one is
better than the other, that static typing is better than
dynamic typing and so forth, but that's a different issue.
>
Of course, it can make sense to instanciate the class
>
in the future, in that case I only have to remove
>
the abstract keyword and no code will be broken.
Some would object that this is bad practice and that you
should instead derive another concrete class from your
abstract class, even if it does not, for now, override any
feature.
>
Too bad the only way to protect my design in Obj-C is to
>
write a comment...
It's not. Design in Smalltalk and Objective C is different,
more dynamic than in C++, and your protections are different
too.
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch