Benefits of using Setter and Getter methods vs. direct manipulation

Question

Sorry if this a beginner question but I was wondering what the benefits are to using setter and getter methods rather than directly manipulating them directly. I'm in obj-c and I'm wondering if there is any benefits in terms of memory/cpu usage.

For instance, I'm cropping an image before I upload it and I crop it after it is taken/picked. I put all my code in the didFinishPickingMediaWithInfo method. So it would look like the following:

-(void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info{

    //Create image
    imageFile = [info objectForKey:UIImagePickerControllerOriginalImage];

    //Unhide imageView and populate
    selectedImage.hidden = false;
    selectedImage.image = imageFile;

    //Create original image for reservation
    originalImage = imageFile;

    //Crop image
    UIGraphicsBeginImageContext(selectedImage.frame.size);
    CGContextRef context = UIGraphicsGetCurrentContext();
    CGContextRotateCTM(context, 2*M_PI);

    [selectedImage.layer renderInContext:context];
    imageFile =  UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();

    //Update imageView with croppedImage
    selectedImage.image = imageFile;

    //Dismiss image picker
    [imagePickerController dismissViewControllerAnimated:YES completion:nil];

}

So let's say I do the same thing but have a method for populating the selectedImage imageView and a method for cropping the image so it would look like the following:

-(void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info{

    //Create image
    [self setImage:[info objectForKey:UIImagePickerControllerOriginalImage]];

    //Create local image
    UIImage * localImage = [self returnImage];

    //Unhide imageView and populate
    selectedImage.hidden = false;
    [self populateImageView:localImage];

    //Create original image for reservation
    originalImage = localImage;

    //Crop image
    localImage = [self getImageFromContext:localImage withImageView:selectedImage];

    //Update imageView with croppedImage
    [self populateImageView:localImage];

    //Dismiss image picker
    [imagePickerController dismissViewControllerAnimated:YES completion:nil];

}

//Crop image method
-(UIImage *)getImageFromContext:(UIImage *)image withImageView:(UIImageView *)imageView{

    UIGraphicsBeginImageContext(imageView.frame.size);
    CGContextRef context = UIGraphicsGetCurrentContext();
    CGContextRotateCTM(context, 2*M_PI);

    [imageView.layer renderInContext:context];
    image =  UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();

    return image;

    image = nil;
    context = nil;

}

-(void)populateImageView:(UIImage *)image{

    selectedImage.image = image;

}

- (void)setImage:(UIImage *)image{

    imageFile = image;

}

-(UIImage *)returnImage{

    return imageFile;

}

So are there any other benefits other than readability and neatness of code? Is there anyway to make this more efficient?

Answer 1

You have a great benchmark made by Big Nerd Ranch on that topic.

Usually I use properties as a best practice. This is useful because you have:

• An expected place where your property will be accessed (getter)
• An expected place where your property will be set (setter)

This usually helps in debugging (you can override the setter or set a breakpoint there to check who is changing the property and when it is changing) and you can do some lazy instantiation.

Usually I do lazy instantiation with arrays or with programmatically created views. For instance:

@property(nonatomic, strong) UIView *myView;

-(UIView*) myView {
   if(!_myView) {
       //I usually prefer a function over macros
       _myView = [[UIView alloc] initWithFrame: [self myViewFrame]];
       _myView.backgroundColor = [UIColor redColor];
   }

   return _myView;
}

Another important factor bolded by Jacky Boy is that with properties you have a free KVO ready structure.