• 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: NSData (again!)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSData (again!)


  • Subject: Re: NSData (again!)
  • From: Joe Osborn <email@hidden>
  • Date: Sat, 14 Dec 2002 10:38:13 -0600

It's much more flexible to compose the NSData<-->YourObject entity at runtime. By using the interface declared in NSData, YourObject can actually interact with any subclass of NSData, given at runtime, or even any object that conforms to the NSData interface. If you subclass NSData, you end up putting a lot of stuff into the NSData heirarchy that isn't really NSData's responsibility. Furthermore, if subclasses of NSData arise who extend NSData in interesting ways, you won't be able to take advantage of them as easily.
If you wanted YourData to be mutable, for instance, you'd have to subclass NSMutableData- if you wanted an immutable version, however, you'd subclass NSData. But what if you want to switch between both? By making a new class and giving it an NSData instance variable,you can swap at runtime the mutability of the data. It wouldn't matter at all to YourObject.

For more on this, and the difference between compile-time structure and runtime structure, see www.c2.com/cgi/wiki?WelcomeVisitors and "Design Patterns: Elements of Reusable Object-Oriented Software"(Gamma, Helm, Johnson, Vlissides).

--joie

On Saturday, Dec 14, 2002, at 08:32 US/Central, Pascal Goguey wrote:

Hello!

Summary of the history:
The other day, I asked a question about how to subclass NSData
from the interface builder. I got a few replies (thanks again), and learned
about forwardInvocation which is a very nice concept. All the replies
I got were telling me that "I should not subclass NSData" or "I probably
don't want to subclass NSData".

I guess it is probably true, that there is probably a good technical reason
to prefer wrapping to inheritance, otherwise the people who wrote
Project Builder and Interface Builder would have enabled the possibility
to subclass NSData.

Now, what I need to know is WHY it is bad practice to subclass.
There are some subclass (e.g. NSApplocation inherits from NSResponder).
So why should my class not inherit NSData, but only wrap it?

Thanks,

Pascal
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >NSData (again!) (From: Pascal Goguey <email@hidden>)

  • Prev by Date: Re: How to run prefPane from Project Builder/gdb
  • Next by Date: Re: IB problem with object hierarchy
  • Previous by thread: NSData (again!)
  • Next by thread: Sample MultiColumn Text Code Finished!
  • Index(es):
    • Date
    • Thread