Learn Objective-C: Day 2

Welcome to part two of this introductory series on Objective-C. After spending last week reviewing the fundamentals of the C language upon which Objective-C is built, this week we will transition to focusing on what makes Objective-C such a great language for software development. Specifically, we will discuss the fundamentals of Object Oriented Programming (OOP) and demonstrate how to create a class and send messages to objects in Objective-C.

Object Orientated Programming

Why do we have Objective-C? Why not just use the underlying C language? The reason we have Objective-C is to give us an object oriented playground within which to build our applications. OOP is a programming paradigm that attempts to allow developers to think about software design in terms of objects and attributes instead of variables and functions. Specifically, OOP attempts to obtain data abstraction, encapsulation, modularity, polymorphism, and inheritance. The topic of OOP could easily fill a book (or a tutorial series) on its own, so instead I’ll introduce you to the basic principles by way of example.

Imagine that you have a car. You can think of your car as an object. There are many other cars in the world and you might even own more than one. Your car has various properties to it: make, model, color, engine type, and many more. In Object Oriented Programming terms, we would call the abstract concept of a car a “class” and the individual car that you own an object or instance (instantiated object) of the class. When a new car is manufactured, a new instance of the car class is instantiated (or created) and given its own set of properties.

Still a little fuzzy? Another great analogy is that of the cookie and the cookie cutter. The class is the cookie cutter, and the object is the cookie.

So, why think in terms of objects? One of the best reasons is because this is how your brain naturally conceptualizes life in the real world, and there are many benefits to being able to abstract software development in similar terms.

Classes (and hence objects) are made up of methods and attributes. If you come from another programming language, you may be more familiar equating methods with functions and attributes with variables. We will discuss each in turn next.

Methods

So we have an “instance” of a car, now that what do we do with it? Well, we drive it and fill it with petrol, among other things. Driving and filling with petrol apply only to the cars that we use, meaning that when we fill up a car or drive a car, we are only impacting one instance, and not all the cars in the world. Therefore, filling up the car instance is considered an instance method. Itʼs something we do to our instance and only our instance.

On the other hand, if we ask the original car class how many colors of car are available, this is a class method because we are no longer only talking about the car we drive around but all cars in general.

Many of these principles become more clear with use, so letʼs look at a little bit of syntax.

In Objective-C, we call object methods by passing messages. When we want to know how much gas is in our instance of car, then we send a message to our instance and the message is the method we want to apply. Programmatically it looks like this:

[recipient message];

The brackets indicate we are sending a message. The first parameter is who should receive this message and the second parameter is what the message actually is. Finally, we end with a semi-colon as is common to most programming languages.

So, with our previous example in mind, this is how we would interact with our instance of car to add gas to the tank;

[dansCar addGas];

The example above assumes that we have instantiated an instance of the Car class and named it “dansCar.” We then pass the “addGas” message to the object “dansCar,” which is the equivalent of calling a function. In another language, this line might look like:

dansCar.addGas();

Attributes

Letʼs say our car class has a gas tank thatʼs stored as a percentage. For example, if the gas tank is at 50% then it is half-full and if it is at 100%, it means it is full to the brim. Now, if we want to know how much gas is in the tank, we donʼt just directly take that information from an attribute. Instead, we would use an accessor method to access the internal variable for us. Likewise, when we want to fill the tank, we donʼt just give the gas tank attribute a new percentage, we use a setter to update the attribute for us. This process is known as data encapsulation.

What we mean by data encapsulation is that data is contained (so to speak) by methods meaning to access it we need to use methods. Some of you who have programmed in other languages and havenʼt heard of data encapsulation may be wondering why we do things this way. The answer is that by encapsulating data, there is a nice cushion between the developer of a class and the user of a class. Because the class methods manage and maintains the attributes within the class, they can more easily maintain data integrity. Another major benefit is that when a developer distributes his class, the people using it donʼt have to worry about the internals of the class at all. A developer may update a method to make it faster or more efficient, but this update is transparent to the user of the class as he/she still uses the same method with no change to his/her code.

This brings us nicely on to the next section weʼre going to look at, which is how Objective- C separates interface from implementation.

Interface and Implementation

When you create or work with a simple class in Objective-C you will see that it, by default, has two files. One is the implementation file which is a file that ends with a suffix of .m and the interface file which is a file that ends with a suffix of .h.

Interface

#import 
@interface Car : NSObject {
    //This is where attributes go
    float fillLevel;
}
//This is where methods go
- (void)addGas;
@end

First of all, weʼre importing Cocoa.h which is a standard library with a lot of reusable code that we can use inside our app.

Next, weʼre declaring that this is the interface for the Car, but weʼre also putting NSObject into that declaration. Adding “: NSObject” means that the Car class inherits from the NSObject class. We’ll talk more about inheritance in a future tutorial.

Our instance variable “fillLevel” is declared next, and we specify that it is of the “float” data type so we can easily represent a percentage.

The next line declares our “addGas” method. The “-” indicates that this is an instance method, not a class method. The “(void)” portion means that the method will not return anything back when it finishes executing. If the class was going to return an integer, this would be changed to “(int)” and the same for any other data type. Finally, we finalize the method declaration with a semicolon.

Implementation

#import "Car.h"
@implementation Car
-(void) addGas {
    // code goes here to add gas
}
@end

The implementation in this case contains the method to add gas to the tank. We also import Car.h, which is the interface file. Where our addGas method sits, we could add many more methods, but today’s scope is to simply get you to understand how classes work rather than make a fully-fledged class.

Next Time

Next time weʼll be looking more in depth at methods and at using variables with methods (as well as the basics of managing variables in Objective-C). This tutorial wasn’t too long as itʼs often a bit confusing for new developers as to why we separate classes in to more than one file. If youʼre feeling at all confused then please re-read the above or ask questions in the comments section below. Classes will be a constant reoccurrence in this series and itʼs important you understand how they work.

Challenge

Seeing as this part of the series was fairly theoretical, thereʼs not too much you can do to practice. However, I do recommend this week that you sign up for Appleʼs developer website as itʼs an invaluable reference. Once youʼve done that, have a snoop around some of their downloadable classes and download a few simple ones. You donʼt need to understand all of the code, just look at how the classes are formed and separated across files.