• 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: Is encapsulation deprecated in ObjC?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is encapsulation deprecated in ObjC?


  • Subject: Re: Is encapsulation deprecated in ObjC?
  • From: Chris Gehlker <email@hidden>
  • Date: Thu, 16 Aug 2001 09:31:58 -0700

On 8/16/01 7:47 AM, "Lloyd Sargent" <email@hidden> wrote:

> I'm not going to argue one way or the other, but apparently in the OOP
> community there are two camps: one that likes public accessors and
> others that don't. Personally, I learned that the point of OOP was that
> you TOLD and object to do something (what I think of as 'active') vs.
> setting/asking it for its contents (what I think of as 'passive').
> However, sometimes that doesn't always fly. For example, how do I
> determine if a button is in a particular state? Uh, er, I guess I have
> to ask it for it's value <shuffle's feet and whistles tunelessly>. :^)
>
> The problem is that sometimes ya' gotta have public accessors, IMHO.

That helps clarify my thinking but it still doesn't completely answer my
question. For one thing, I should have focused on setters. I personally
don't see any reason at all why getters could be a problem since they don't
change the object's state. I have heard an argument that even getters are
bad but I don't think I can do it justice.

But lets take your switch controller example. It could be written like this:

ParanoidController.h
#import <Cocoa/Cocoa.h>

@interface ParanoidController : NSObject
{
@private
IBOutlet NSButton *mySwitch;
}

- (BOOL)switchIsOn;

@end

ParanoidController.m
#import "ParanoidController.h"

@interface ParanoidController (PrivateMethods)
- (IBAction)switchClicked:(id)sender;
@end

@implementation ParanoidController

- (IBAction)switchClicked:(id)sender
{
if ([sender state] == NSOnState)
NSBeep();
}

- (BOOL)switchIsOn
{
if ([mySwitch state] == NSOnState)
return YES;
return NO;
}

@end

And I know people who would actually write it that way. There argument goes
something like:

It's important that any code dealing with the switch be isolated in
ParanoidController. That way if any bugs crop up that have to do with the
switch I know they are isolated in ParanoidController and half my work is
done.

I don't reject this argument out of hand but it leaves out something. The
thing that's left out is:

"I have discovered though my own experience that the price I pay in terms of
extra work and loss of code clarity is worth the benefits I get it terms of
isolating bugs."

They mostly seem to take it as an article of faith that its a tradeoff worth
making.

That's why it's so exciting to me to find a community that tends to make the
trade-off the other way. Especially when that community includes so many
people who have been doing OOP for a long time.
--
Many individuals have, like uncut diamonds, shining qualities beneath a
rough exterior. - Juvenal, poet (c. 60-140)


  • Follow-Ups:
    • Re: Is encapsulation deprecated in ObjC?
      • From: "Dennis C. De Mars" <email@hidden>
References: 
 >Re: Is encapsulation deprecated in ObjC? (From: Lloyd Sargent <email@hidden>)

  • Prev by Date: Re: Category vs Subclass
  • Next by Date: Re: Online C++ resources?
  • Previous by thread: RE: Is encapsulation deprecated in ObjC?
  • Next by thread: Re: Is encapsulation deprecated in ObjC?
  • Index(es):
    • Date
    • Thread