Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

larswik

macrumors 68000
Original poster
Sep 8, 2006
1,552
11
When I create a custom Class it is a subclass of NSObject. Where NSObject is the Superclass of my new class. This I get. When I add an NSButton or NSWindow do I say "Mybutton is a subclass of of some greater class?" is that why I see subclass everywhere when they talk about buttons, windows and everything else? I knew it applied to Classes but every object has that same relationship?

I simply was saying I drag a NSButton out of the library and stick it in/on my NSWindow". Is the proper way to say it "I subclass'd an NSButton"?
 
I simply was saying I drag a NSButton out of the library and stick it in/on my NSWindow". Is the proper way to say it "I subclass'd an NSButton"?

No. This has absolutely 100% nothing to do with subclassing. All you are doing is creating an instance of NSButton.

I suggest you need to learn the basics of Object Oriented Programming.
 
Robbie's right, the term subclass in that context doesn't make sense. Can you quote an example? Please quote exactly and don't paraphrase, otherwise we can't correctly explain it to you.
 
The way I was originally taught about subclasses was the animal example.

All animals in the real world have characteristics and actions, which lends itself to an object. But there are different kinds of animals, so you can subclass Animal.

For instance, you have a class Animal, with properties such as legs, communication method, size, etc. Now, suppose you want to create a Cat. This cat is an animal (and importantly, a Cat is an Animal!), but posses a unique characteristic: the boolean canAlwaysLandOnFeet. Instead of making a Cat that duplicates the characteristics of an Animal and adding that boolean, you can simply subclass Animal into a Cat. (A Cat inherits all of the methods/properties from Animal.) You would then only have to add the canLandOnFeetAlways property to Cat, saving yourself a lot of work. This would be especially true if you wanted to add a property such as hair color, which all animals have. Just add it to Animal, and it automagically becomes part of Cat.

If you had a class Animal, creating a class Cat based off of Animal would be subclassing Animal, resulting in a distinct class that happens to be a subclass.

I hope this answers your question well. I might have gone off what a subclass is more than how to properly use the word, but maybe this example will help with that, too.
 
@Thom_Edwards's analogy is great. To put it into context for Cocoa apps, take a look at Figure 1-8 from this documentation. It shows the App Kit class hierarchy. So you can see for example that NSPanel inherits from NSWindow which inherits from NSResponder which inherits from NSObject. This means that an instance of NSPanel object can use the methods of NSResponder for example.

In the case of the button, you're likely not subclassing NSButton (unless you're trying to make some crazy new type of button like a triangle button or something like that) but you're instantiating 1 unique instance of the NSButton class and giving that instance a name. To refer back to the animal analogy, you're not subclassing cat (and breeding some new species of glow-in-the-dark cat), but you're instantiating (giving birth to) and giving the name to one individual cat: mrWhiskers.

In the other thread I was suggesting you subclass NSWindowController. In this case, you want to create a unique "species" of NSWindowController one that handles the preferences of your app, it's buttons and does the things that a LARSPreferencesWindowController would want to do. You accomplish this by subclassing NSWindowController. This new "species" can do all of the things it's parent class NSWindowController can do, and it's parents etc, but you can add the additional specific variables and methods that will be unique to making a LARSPreferencesWindowController do what it does (displaying crit boxes etc.).

You will still need to create an instance of this class or potentially several instances if you had a need for multiple preference windows open simultaneously (not likely but possible in theory); in this case, each LARSPreferencesWindowController instance would manage it's own unique set of buttons, textfields etc.

I hope this helps clarify things a bit.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.