Re: class members? info
Re: class members? info
- Subject: Re: class members? info
- From: John Stiles <email@hidden>
- Date: Mon, 19 Sep 2005 18:02:28 -0700
On Sep 19, 2005, at 5:56 PM, Jeff Childers wrote:
On Monday, September 19, 2005, at 06:50 PM, John C. Randolph wrote:
On Sep 19, 2005, at 4:38 PM, Jeff Childers wrote:
is there a way to ask 'SomeClass' about its ivars?( or whatever
they are call).
.... Keep in mind that if you do this, you're breaking
encapsulation, etc, etc.
I am not trying to argue about but I am very curious about this.
encapsulation is a method of combining elements to create a entity
abstraction combining similar functions into a single function
information hiding is a process of hiding complexities into a
higher level object
if these definitions are correct
now if in my class furnishes my ivars names and data types then
this is ok but
if the class that I am passing my data and class info is able to
find class
information on its own it breaks the rules? what about abstraction?
or for that
matter simplicity which to me is way more important than the rules.
I'm missing the point somewhere?
Without commenting on the rest of your discussion too much, just
remember that the "rules" typically exist for the sake of simplicity.
Breaking the "rules" is usually a bad idea because you're making your
life complex by using a "dirty" solution when a "cleaner" one would do.
Manipulating another class' ivars directly is a bad idea because
- if the class wanted you to use its ivars, it should have accessors
for them
- in theory, you should be able to swap out Class A with any
functionally-identical Class B, and when you depend on implementation
details (such as ivars inside Class A), you can no longer do this.
Usually "Class B" is really version 2.0 of Class A, sporting the same
interface but brand-new extra optimized guts. This happens more often
than you'd think, particularly if you count the internals of Cocoa
itself.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden