@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.