This article is part 3 of a series. Check out part 1 and part 2.
Objective-C is an “object-oriented” programming language, but what exactly does that mean? In an earlier post, I described how “an object-oriented language is one that is built around the concept of objects.” By that I mean that the programming language is used in such a way that real-world objects can be represented in code in an intuitive manner that makes sense.
As is often the case, this is best illustrated with an example. Let’s imagine that we are working on an app that let’s users order pizzas from a local restaurant. The user’s order is an example of an “object.” It has properties about it, like the user’s name, phone number, and items ordered. Each item, like a pizza, is another “object” that has its own properties, like size and toppings. The properties are represented a certain way in code and can be accessed throughout the app. This gives the code an organized structure that becomes more apparent with use and practice.
Anything, physical or abstract, can be as an “object” in code. (ninacoco/Flickr)
These objects can also have behaviors associated with them. With the order example, it can be submitted or canceled. Those two behaviors can be represented as “methods” in code, which you might remember from another earlier post.
In code, this might be represented as the following, which creates a simple order for Ben, adds a pepperoni pizza, and submits the order to the store:
Order *order = [[Order alloc] init];
order.name = @"Ben";
[order.items addObject:[Pizza initWithToppings:@"Pepperoni"]];
[order submit];
Why Does This Matter?
Programmers loathe inefficiency and have spent decades establishing conventions and patterns for software development that improve efficiency in different ways. Object-oriented principles allow for better reuse, organization, and understanding of code. It separates code into modules that can be easily reused or changed, and does so in a meaningful way that is easier for someone working with the code to understand. If you care to know more about the “why” of object-oriented programming, check out this very informative (and surprisingly easy-to-read) Wikipedia entry.
Classes and Objects in Objective-C
In general, files of code in Objective-C are organized as classes. Classes are usually represented by two files: a header file and a corresponding implementation file. A class is meant to define an object and how it works. In this way, a class is like a blueprint of an object. Classes define things about objects as properties, and abilities of the object are defined as methods.
A class is like a blueprint for an object. (wondermonkey2k/Flickr)
Header Files in Objective-C
The header file (with the file extension .h) defines the class and everything about it for the world to know. The idea is to separate the definition of a class from its nitty gritty implementation details. In this case, the header file acts as the interface to the rest of your program. Your other code will access everything about a class based on what is made available in its interface, including available properties and methods.
Let’s take a look at a class that could be used to represent a simple connection to a website. This simple object has one property, a URL, and two methods: “connect” and “canHandleRequest.” The header file might look something like this:
UrlConnection.h
01 #import <Foundation/Foundation.h>
02
03 @interface UrlConnection : NSObject
04
05 @property NSString *url;
06
07 - (void)connect;
08 + (BOOL)canHandleRequest:(NSString *)type forUrl:(NSString *)url;
09
10 @end
The first line is what is known as an import statement. This is used to import required files that the code inside this class needs. In this example we are importing the Foundation classes, which includes NSObjects like NSString, NSArray, etc. A class can have many import statements, each on its own line.
(One quick thing to point out about import statements: Sometimes you will see the names of things in angle brackets, like this example, and other times you’ll see the names in double quotes, like #import "PizzaViewController.h". Angle brackets tell the compiler to search for the code to import in certain system paths, whereas the double quotes tell it to search within the current project.)
The next line (line 3) is the interface declaration. It begins with @interface and ends with @end on line 10. These special markers designate the beginning and end of the class interface definition. After @interface is the name, so the name of this example class is “UrlConnection.” The name here must match the name used in the .h and .m files.
Up next on line 3 is a colon and another name. The colon means that the next name is the parent class of this class. Object-oriented programming languages have a concept called inheritance that is used to share properties and methods from one class to another. In this example, our UrlConnection class is inheriting from the NSObject class, which is Objective-C’s generic object class. NSObject defines some very basic structure about objects in Objective-C, but classes can inherit from any other class. For example, we could create another class named YouTubeUrlConnection that inherits from this UrlConnection class, and the interface declaration would look like this:
@interface YouTubeUrlConnection : UrlConnectionLet’s stop with the @interface line here, but additional information can appear on this line. For more details about it, check out Introduction to Objective-C in Treehouse’s Objective-C Basics course.
Properties
The next line in the class (line 5) declares a property of the class called “url.”
@property NSString *url;Properties, remember, are data items about the object. In this case, it would be the actual URL that this object will be trying to connect to. Properties are declared with the special @property keyword and end with the semicolon. After @property we have a regular variable declaration that includes its data type (NSString in this case) and name (“url”).
I should also point out that properties can have attributes that are defined inside parenthesis after the @property keyword:
@property (nonatomic, strong) NSString *url; // Example attributesThese are added to show other objects how to interact with the property and to tell the compiler how to automatically create “getter” and “setter” methods that can be used to set or retrieve the value of the property. For more details about attributes, check out this extensive tutorial.
Methods
After the properties of a class, the methods (think behavior) are usually listed. Methods are used to organize our code into reusable (and understandable) chunks that save us a lot of time and energy.
On lines 7 and 8 in our example, we have two methods listed:
- (void)connect;
+ (BOOL)canHandleRequest:(NSString *)type forUrl:(NSString *)url;
Notice that these are just the names of the method. This is known as the method signature. It also tells us what kind of data will be returned (if any), and what parameters might be required to call it. The connect method does not have any parameters, nor does it return anything. The canHandleRequest method returns a BOOL value and has two parameters, both NSStrings.
Instance vs. Class Methods
Method declarations begin with either a minus (-) or a plus sign (+). The minus sign indicates that this method is an instance method. This means that an instance of the class must be available to call this method. Or, in other words, it means that in our code we need to be using an object made from this class, like if we allocated and initialized a UrlConnection object as a variable.
Class methods (beginning with the plus sign), can be used simply by referencing the class. No instance of the class is needed. We can call a class method anywhere in our code as long as the header file for the class is imported. Let’s take a look at an example of using this UrlConnection class:
01 BOOL canHandleIt = [UrlConnection canHandleRequest:@"GET"
02 forUrl:@"http://www.teamtreehouse.com"];
03
04 if (canHandleIt) {
05 UrlConnection *connection = [[UrlConnection alloc] init];
06 connection.url = @"http://www.teamtreehouse.com";
07 [connection connect];
08 }
On lines 1 and 2 we set a BOOL variable using the canHandleRequest method. (Yes, method calls can span more than one line if we want! It’s up to us.) Notice that no instance of UrlConnection has been declared yet, but we reference the method using the class name.
On line 6 we have a UrlConnection variable named “connection.” We use this variable, an instance of the UrlConnection class, to call the connect method.
We are not allowed to write [connection canHandleRequest:@"GET"], nor can we write [UrlConnection connect].
Implementation Files in Objective-C
The other half of a class is the implementation file (with the file extension .m). This is where the magic happens, where the rubber meets the road, and where the dirty work and the heavy lifting occurs. Implementation files implement all those things that we declare to be available in the header files. Every method that we say a class has must be defined with all its necessary code in the implementation file.
Continuing with our UrlConnection example, the following is a shortened version of what the implementation file might look like:
UrlConnection.m
01 #import "UrlConnection.h"
02
03 @implementation UrlConnection
04
05 - (void)connect {
06 /* In here would be code to attempt a connection to the
07 * specified URL, while possibly handling connection errors.
08 */
09 }
10
11 + (BOOL)canHandleRequest:(NSString *)type
12 forUrl:(NSString *)url {
13 /* And in here would be code to see if the given URL passed
14 * in is capable of handling the HTTP request type specified
15 * by the "type" parameter. It will return YES or NO.
16 */
17 }
18
19 @end
Notice that the header file must be imported (line 1). Because these are two separate files, the compiler must be told where to find the header file that belongs to this implementation file. As we saw earlier, the double quotes are used on this line to indicate that the file should be located in the same project as this implementation file.
Next, on line 3, we begin the actual implementation of the class with the @implementation keyword. This correlates to the @interface keyword for the header file. And in the same manner, the implementation ends with the @end keyword on line 19.
Primarily, we see method definitions inside the implementation. In our example, we have two methods, which are defined here. Notice that the signature for the methods is the exact same as what we saw in the header file. What’s different is that the body of the method, the code that makes it up, is also shown here as a bunch of statements inside curly braces that immediately follow the method signature. Now, we do not have any code in this example because that is not what we are focusing on here. But the comments provided give an idea as to what the Objective-C statements inside the methods will be doing.
How do I apply this knowledge?
The main thing I hope you take away from this article is an understanding of classes and objects in Objective-C so that you will know what is going on and how to use them as you write your code. Knowing how to organize and structure your objects is an art that even experienced programmers are constantly refining.
As usual, if you want to learn more about anything we have covered here, or would like to practice with actual code in your browser, check out the Treehouse course Objective-C Basics, as well as any of the iOS projects. Good luck, and happy coding!
*Shiba Inu blueprint courtesy of wondermonkey2k and pizza image courtesy of ninacoco under the Creative Commons license.
The post The Beginner’s Guide to Objective-C: Classes and Objects appeared first on Treehouse Blog.
]]>
