• 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
A Challenge WAS Accessor method idioms...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A Challenge WAS Accessor method idioms...


  • Subject: A Challenge WAS Accessor method idioms...
  • From: John Brownlow <email@hidden>
  • Date: Thu, 24 Mar 2005 14:11:21 -0500

I see your point but here's mine.

Implementing dudley do-right accessors like these is a lot of sweat and the benefits in many cases are purely notional. What you actually end up with is using Accessorizer and generating swathes of code which you never actually read. Your classes become utterly unreadable and you miss things like the fact that you should be returning a copy here instead of a reference.

I'm a HUGE fan of Accessorizer but here is 50+ lines for a single array. Let's say I have ten arrays, not at all unlikely... now it's 500 lines of mechanical code that I haven't ever read. Yuk. And I am completely reliant on the genius of Accessorizer because believe me I am NOT going to type those 500 lines myself and neither is anyone else.

There are cases where it makes a lot of sense, especially when you are implementing something that is a bit off kilter. But in my own experience stuff like this below actually makes your code harder to maintain.

CHALLENGE: I have introduced a simple and obvious bug into the code below. Can you find it?


//---------------------------------------------------------- // things //---------------------------------------------------------- - (NSMutableArray *) things { return things; } - (void) setThings: (NSMutableArray *) theThings { if (things != theThings) { [things release]; things = [theThings retain]; } }

///////  things  ///////

- (unsigned int) countOfThings;
- (id) objectInThingsAtIndex: (unsigned int)index;
- (void) insertObject: (id)anObject inThingsAtIndex: (unsigned int)index;
- (void) removeObjectFromThingsAtIndex: (unsigned int)index;
- (void) replaceObjectInThingsAtIndex: (unsigned int)index withObject: (id)anObject;



/////// things ///////

- (unsigned int) countOfThings
{
    return [[self things] count];
}

- (id) objectInThingsAtIndex: (unsigned int)index
{
    id myThings = [self things];
    unsigned int thingsCount = [myThings count];
    if ( thingsCount == 0 || index > (thingsCount - 1) ) return nil;

    return [myThings objectAtIndex: index];
}

- (void) insertObject: (id)anObject inThingsAtIndex: (unsigned int)index
{
    id myThings = [self things];
    unsigned int thingsCount = [myThings count];
    if (index < thingsCount) return;

    if (anObject) [myThings insertObject: anObject atIndex: index];
}

- (void) removeObjectFromThingsAtIndex: (unsigned int)index
{
    id myThings = [self things];
    unsigned int thingsCount = [myThings count];
    if ( thingsCount == 0 || index > (thingsCount - 1) ) return;

    [myThings removeObjectAtIndex: index];
}

- (void) replaceObjectInThingsAtIndex: (unsigned int)index withObject: (id)anObject
{
id myThings = [self things];
unsigned int thingsCount = [myThings count];
if ( thingsCount == 0 || index > (thingsCount - 1) ) return;


    [myThings replaceObjectAtIndex: index withObject: anObject];
}








On Mar 24, 2005, at 1:17 PM, M. Uli Kusterer wrote:

Here's a simple one: maybe one day you decide that instead of NSArray you want to use another (faster, or more flexible, or whatever) data structure. With objectFromThingsAtIndex: it's easy. With [[self things] objectAtIndex:] you're bound to supporting access via an NSArray.

The less of such details your class exposes to its clients, the easier it is for you to change it without having to change the clients. That's the entire reason encapsulation and accessors exist for in the first place.
--
John Brownlow
Deep Fried Films, Inc

http://www.johnbrownlow.com
http://www.pinkheadedbug.com

_______________________________________________
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


  • Follow-Ups:
    • Re: A Challenge WAS Accessor method idioms...
      • From: Nicko van Someren <email@hidden>
    • Re: A Challenge WAS Accessor method idioms...
      • From: Jonathon Mah <email@hidden>
References: 
 >Accessor method idioms... (From: Mike Ferris <email@hidden>)
 >Re: Accessor method idioms... (From: John Brownlow <email@hidden>)
 >Re: Accessor method idioms... (From: "M. Uli Kusterer" <email@hidden>)

  • Prev by Date: Re: Accessor method idioms...
  • Next by Date: Re: A Challenge WAS Accessor method idioms...
  • Previous by thread: Re: Accessor method idioms...
  • Next by thread: Re: A Challenge WAS Accessor method idioms...
  • Index(es):
    • Date
    • Thread