• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Q's about Obj-C
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Q's about Obj-C


  • Subject: Re: Q's about Obj-C
  • From: Normand Rivard <email@hidden>
  • Date: Tue, 16 Oct 2001 00:22:48 -0400

I have to disagree on this, Ondra. Java is a dynamic language too and it
is possible (and sometimes desirable) to declare a class as abstract.
Try to dynamically instanciate an abstract class like in the example and
you will end up with an exception.

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. 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. The
opposite is not true, however : it is sometimes hard to make a class
abstract after I said that it is not.

Too bad the only way to protect my design in Obj-C is to write a
comment...

Normand

On Monday, October 15, 2001, at 01:36 PM, Ondra Cada wrote:

> (i) You can't have compiler to enforce abstract classes since we have a
> dynamic language:
>
> Class c=runtime_known_value?[NonAbstractClass class]:[AbstractClass
> class];
> id o=[c new]; // and what now?!?
>
> (ii) You can have runtime-abstract class if you really want to (though I
> haven't *EVER* seen a situation when this would be desirable!!!):
>
> @implementation AbstractClass
> -init {
> [self autorelease];
> NSLog(@"Attempt to create an instance of anstract class %@",[self
> class]);
> return nil;
> }
> ...
> @end
>
> (iii) Instead of the slightly pathological situation of (ii), you can --
> thanks to the fexibility of the alloc/init system -- implement class
> clusters
> instead:
>
> @implementation AbstractClass
> -init {
> [self autorelease];
> return [[SomeReasonableConcreteSubclass alloc] init];
> }
> ...
> @end
> ---
> Ondra Cada
> OCSoftware: email@hidden http://www.ocs.cz
> 2K Development: email@hidden http://www.2kdevelopment.cz
> private email@hidden http://www.ocs.cz/oc
> _______________________________________________
> cocoa-dev mailing list
> email@hidden
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev


References: 
 >Re: Q's about Obj-C (From: Ondra Cada <email@hidden>)

  • Prev by Date: Client / Server Application
  • Next by Date: Re: Client / Server Application
  • Previous by thread: Re: Q's about Obj-C
  • Next by thread: Re: Q's about Obj-C
  • Index(es):
    • Date
    • Thread