CODEWITHSUNDEEP
objective-ciosuitableviewencapsulation
mnort9
mnort9

Reputation: 1820

Local or instance variable

I have a very simple TableViewController. I'm only implementing the data source methods and two other methods to modify the data source. The table's dataSource array is an array retrieved from the @"dataSource key in TableViewController's NSDictionary property classData. I'm probably over thinking this, which is the best way to use dataSource array in my TableViewController:

1) Define a property in .h and set the property to the dictionary's @"dataSource key in viewDidLoad

@property (strong, nonatomic) NSMutableArray *dataSource;

2) Define the variable in .m interface

@interface TableViewController () {
    NSMutableArray *dataSource;
}
@end

3) Create an instance of the array in every method I need it

NSMutableArray *dataSource = [self.classData objectForKey: @"dataSource"];

I'm leaning towards option 2 because none of the classes in my app need access to the array. However, option 3 keeps it encapsulated even further. I would like to know the correct approach for this simple situation.

Upvotes: 0

Views: 857

Answers (3)

Jonathan
Jonathan

Reputation: 21

You could also declare the property in a private class extension, rather than the public interface. This lets you maintain it as a true property (getting the benefit of setter/getter methots you can overload later if that becomes useful) and also keep the value private to the class.

See here for more info: http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/objectivec/Chapters/ocCategories.html#//apple_ref/doc/uid/TP30001163-CH20-SW2

As a side note, private class extensions also provide a way to create private methods.

Upvotes: 1

sergio
sergio

Reputation: 69027

The decision between option 1 and 2 is pretty easy to resolve: it all depends on whether your datasource should be public or private; if it is private, then go with option 2.

On the other hand, option 3 does does not seem really a good option (if either 1 or 2 is).

If your datasource is meant to be a local variable (i.e., a variable whole lifecycle is bound by the containing method runtime), then it is fine; but in this case you would not even think of declaring that variable as an instance variable.

You declare a variable as instance variable when you need to share its value across multiple calls to some methods of the declaring class (even the same method called at different times). This will decide if the variable is local or instance.

If you mean using a static global variable whose scope is limited to the declaring method, then this is only superficially appealing. Indeed, the issue with it is that you cannot exactly foresee the use that will be required of datasource in the future: it may be the case that you will need to access it - for whatever reasons - from another method, then that design would not adapt itself.

More generally speaking, in terms of encapsulation, I think that in OOP, the correct level of encapsulation is the class level, IMO. This would also rule out again option 3.

Upvotes: 1

rmaddy
rmaddy

Reputation: 318794

I don't understand your statement for option #3. How does writing less efficient code make it more encapsulated? Personally, option #2 is the proper choice.

Upvotes: 0

Related Questions