Object oriented programming is a way of thinking about programming in terms of objects. An object in programming is like an object in the real world. That is, an object is something that you can describe and does things. Objects in the real world also have relationships to other objects. That is, an object in the real world may be made up or other objects, use other objects or it may be a variation of another object.

To help understand objects in programming, consider the example of a real world object like a car. You can describe a car as something that has four wheels, a color, model, make and so on. A car also does things like go forward, turn left and stop. Finally, a car is related to other objects in the world. A car is a type of vehicle (which itself is a kind of object), a car is made up on other objects (engine, wheels, stereo system) and a car is used by a person.

This way of describing and organizing things is natural for most of us. We tend to think of the world in terms of objects. In programming, objects are like the car example: an object’s attributes can be described and they can demonstrate behavior. Sometimes objects in programming actually correspond to objects in the real world. Programming objects also have relationships to other programming objects.

Programming languages that support objects are called object oriented programming languages. The object oriented programming language that is used with iOS is called Objective-C.

In order to really understand object oriented programming and how to implement objects in your app we need to get comfortable with some of the vocabulary and high-level concepts.

Object

In programming, an object is an entity that contains both data and behavior. Objects are described by many data points and may have many behaviors.

Objects in programming can correspond to objects in the real world like cars and people. In these cases, an object in our computer program acts as a model (a simplified version) of the real world object. An object in our program that represents a person may have data that represents things like a person’s eye color, height and weight and the object will also have a way to represent a person’s behaviors like walking, talking and eating.

Objects also are used to represent more abstract things like decision-making processes and software components like menus and buttons and Internet connections.

Attributes And Properties

The data that is contained in an object is referred as attributes or properties. An attribute is a data point that describes an aspect of an object. So a person object may include a name property as well as a height, age and weight property. Objects are described by this collection of property values. Properties describe what the object IS.

Behavior And Methods

Objects contain both data (properties) and behavior. Behavior is what the object can do. A person object may have the behavior of walking and talking. More software-centric objects may have behavior like opening an Internet connection or writing to the file system. Each behavior that an object can do is called a method. Methods describe what the object can DO.

Messages

Objects communicate to one another using messages. So if a person object wanted a car object to slow down the person object would need to send a slowDown message to the car object. A message will correspond to a method in a given object. That is, in the example above the person object sent the message to the car object. This works only if the car object has a method defined in its class (defined next) that corresponds to the message. Here the car would need to have a slowDown message defined in its class definition.

Class Definition

Class definitions are used to define an object in programming. Just like we need to define our own composite type before we can use them we need to define our own class type before we can use objects. The class is what is used to define all the properties and methods that will make up the object that we will be using.

Classes are related to objects like blueprints are related to widgets in a factory. You create a blueprint once and then use this blueprint as a guide to create any number of widgets. Class definitions are used to define what makes up an object and are used to create any number of classes.

Instantiation And Constructors

The process of creating an object from a class definition is called instantiation. Objects may be instantiated from a class as often as the program needs more objects. Instantiation requires a special method called a constructor. A constructor is a method that returns an object based on the object’s class definition. In Objective-C you can tell what when a method is a constructor when it has the prefix init.

Here is an example of an object being instantiated from a constructor that you see often in iOS:

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Alert View"
	                                                 message:@"Hello World"
	                                                delegate:self
	                                       cancelButtonTitle:@"Ok", nil
	                                       otherButtonTitles:nil];

The code you see above is an example of creating an object using a constructor. Here we are using a class that has already been defined for us. The class name is UIAlertView. The object here is called alert. You may notice that alert has an asterisk * in front of it. This is something that is required for object declarations that you do not need for primitive or composite types. The constructer method is all the stuff that comes after the part that starts with initWithTitle:.

Object-Oriented Design Concepts

OOP is a way of thinking about code that helps programmers keep complex systems organized. OOP also helps programmers conceptualize systems by creating models and systems of interaction based on the what people expect in the real world. The first part of this has to do with the idea of objects. But, there are a few more design considerations unique to OOP that go beyond the idea of grouping methods and data together in objects.

You can think of the following design considerations as guideposts on how to think of the objects you create. Knowing the design ideas below will also help you to consume objects that other programmers create.

Responsibility

Responsibility has to do with the design idea that an object should be ultimately responsible for all the information and behavior that belongs to its domain. That is, if you have created a person object then that object will be responsible for everything that a person is and does.

You would not attach methods or properties that logically belong to the person object with other objects. This is something that you may find tempting when quickly coding something in your app. For example, it may not be out of the range of possibility that I would carelessly define a car method that had a rouge property on it called something like driversEyeColor even though this is not something that logically a car object would be responsible for. The problem with defining behaviors and attributes in a class were they don’t belong is that it becomes quite painful to attempt to debug these things when needed later on.

Encapsulation

Encapsulation means that the internal workings of an object are hidden from the rest of the program. This means that any data and procedures required for the object to work are not directly accessible by other objects. Really other objects do not care or need to know how your object gets things done, they just need to know that certain things will get done.

You as the program must choose what will remain privately encapsulated in your object and what will become publicly available to other objects. Some behavior and data are not really important to the rest of the program so you may decide to just keep them to yourself. There will be some data and behaviors that you do want exposed to other objects and that is ok but you will have to make a judgment about what is private and stays encapsulated in your object and what is public and available for use by other objects.

These two ideas of responsibility and encapsulation with objects is what makes object oriented programming much easier to create an organized system. If you stick to following the notion of responsibility then you can be pretty sure that methods and data that you need to maintain in the future can be located in the appropriate class definition. Encapsulation ensures that we don’t inappropriately meddle in the inner workings of other objects and keeps us from wasting unnecessary time on code that our other objects can’t touch.

Inheritance (Is-A Relationship)

Objects in programs can have relationships just like objects in the real world. The inheritance relationship refers to kind of relationship where one object is a specific type of another object. Imagine that you have a computer object where you encapsulate everything that you know about what a computer is and does. This computer object is fine most of the time but if you think about it there are other types of computers in the world: Windows PC, Macs, iPhones, onboard car computers and so on. Each of these things is-a computer but they are more than that as well.

In programming we call this relationship inheritance because if you were to design a class definition for iPhone your first step would be to inherit everything that already exists for Computer. This way we do not have to re-code everything that we have already coded for Computer. The class that you are inheriting from is called the parent class and when you inherit a parent class you automatically get all the parent classes attributes and behaviors as if you coded them again in your new class.

The inheritance relationship is one way in which object oriented programmers can efficiently deal with the problem of code entities that are mostly the same but have variations.

Composition (Has-A Relationship)

Composition is another relationship that objects can have and you will see this one all the time when you are looking at class definitions. What composition means is that objects may be composed of other objects. So maybe you have an office object. That object may have as part of its definition other objects that make it up. You will probably have a fax object, a secretary object, a desk object and objects for everything that makes up an office. We would say that an office object is composed of a desk object, a fax object and a secretary object.

This notion of composition allows us to still use the behaviors and attributes that we need for other objects while maintaining the idea of responsibility and encapsulation. So, in our office example we have a fax object that will be responsible for everything fax. The office object is not responsible for the behavior of the fax object even though the office object can use the fax object.

The Person Object Example

To make things a bit more concrete I am going to go through the process of describing a person in object oriented programming terms. If this is starting to feel a bit abstract don’t worry too much about that – in the next chapter you will start to see how these object oriented concepts are applied to iOS programming with Objective-C.

When framing things in object oriented terms it helps to think of the object itself and just write down what the object is and what the object does. When I think of a person as an object some things that come to mind are that a person can be described by their name, age, eye color and height. Some things that a person can do is walk, talk and eat.

If I were to diagram this definition of a person that will eventually turn into a class definition for a person in my program it would look something like this:

Now if I wanted to use this class definition of a person I would need to create objects by instantiating person objects using this class definition. Each person object would have the same attributes but the attribute values would be different. For example,

My program may also need specific types of persons to deal with cases when a person has a special abilities or roles. So if I needed something to deal with artists, police officers and programmers I might have something like this:

Artist, Police Officer and Programmer are all a kind of Person. Each of these have their own attributes and behaviors but they all inherit things like name, eye color and the ability to walk and talk based on their relationship to the Parent class definition.

So this wraps up the high level object oriented stuff. In the next chapter, you will see these how these ideas are used in the object-oriented frameworks Foundation and UIKit that are used in iPhone development.