Session 3 - Object oriented programming with Objective-C (part 1)

Object Oriented Programming with
Objective-C (Part 1)
These are conﬁdential sessions - please refrain from streaming, blogging, or taking pictures
Session 3
Vu Tran Lam
IAD-2013

• Object-oriented programming (OOP) concept
• Classes and objects
• Properties
• Methods
Today’s Topics

• Data and operation
• Interface and Implementation
OOP Concept

• Programming languages have traditionally divided the world into two parts
—data and operations on data.
• Data is static and immutable, except as the operations may change it.
• The procedures and functions that operate on data have no lasting state of their
own; they’re useful only in their ability to affect data.
• With a procedural programming language like C, that’s about all there is to
it. The language may offer various kinds of support for organizing data and
functions, but it won’t divide the world any differently. Functions and data
structures are the basic elements of design.
• Object-oriented programming doesn’t so much dispute this view of the
world as restructure it at a higher level. It groups operations and data into
modular units called objects and lets you combine objects into structured
networks to form a complete program. In an object-oriented programming
language, objects and object interactions are the basic elements of
design.
Data and operation

• To invent programs, you need to be able to capture abstractions
and express them in the program design.
• All programming languages provide devices that help express
abstractions. In essence, these devices are ways of grouping
implementation details, hiding them, and giving them, at least to
some extent, a common interface—much as a mechanical object
separates its interface from its implementation,
Interface and Implementation

• As in many other object-oriented programming language,
Objective-C classes provide the blueprint for creating objects. First,
you deﬁne a reusable set of properties and behaviors inside of a
class. Then, you instantiate objects from that class to interact with
those properties and behaviors.
• Objective-C is similar to C++ in that it abstracts a class’s interface
from its implementation. An interface declares the public properties
and methods of a class, and the corresponding implementation
deﬁnes the code that actually makes these properties and methods
work. This is the same separation of concerns that we saw with
functions.
Classed and Objects

Classed and Objects
Data
method
method
method
method
Data
method
method
method
method
Data
method
method
method
method
Data
method
method
method
method
Data
method
method
method
method
create
Objects
Class

• To create a new class, navigate to File > New > File > OS X >
Cocoa > Objective - C class and then name class with “Car”. After
these steps, Xcode a class with two ﬁles, interface ﬁle named Car.h
(also called a “header”) and whose implementation resides in Car.m.
Creating Classes

• Car.h contains some template code, but let’s go ahead and change it to the
following. This declares a property called model and a method called drive.
• An interface is created with the @interface directive, after which come the
class and the superclass name, separated by a colon. Protected variables
can be defined inside of the curly braces, but most developers treat
instance variables as implementation details and prefer to store them in
the .m file instead of the interface.
• The @property directive declares a public property, and the (copy) attribute
defines its memory management behavior. In this case, the value assigned
to model will be stored as a copy instead of a direct pointer. The Properties
module discusses this in more detail. Next come the property’s data type
and name, just like a normal variable declaration.
• The -(void)drive line declares a method called drive that takes no
parameters, and the (void) portion defines its return type.
Interfaces

#import <Foundation/Foundation.h>
!
@interface Car : NSObject
{
// Protected instance variables (not recommended)
}
!
@property (copy) NSString *model;
!
- (void)drive;
!
@end
Interfaces

• The ﬁrst thing any class implementation needs to do is import its
corresponding interface. The @implementation directive is similar to
@interface, except you don’t need to include the super class. Private
instance variables can be stored between curly braces after the class
name.
• The drive implementation has the same signature as the interface, but
it’s followed by whatever code should be executed when the method is
called. Note how we accessed the value via self.model instead of the
_model instance variable. This is a best practice step because it utilizes
the property’s accessor methods. Typically, the only place you’ll need to
directly access instance variables is in init methods and the dealloc
method.
• The self keyword refers to the instance calling the method (like this in C
++ and Java).
Implementations

#import "Car.h"
!
@implementation Car
{
// Protected instance variables (not recommended)
double odometer;
}
!
@synthesize model = _model; // automatically create _mode in Xcode 4.4+
!
- (void)drive
{
NSLog(@"Drive a %@ Vrooooom!", self.model);
}
!
@end
Implementations

• Any files that need access to a class must import its header file
(Car.h)—they should never, ever try to access the implementation
file directly. That would defeat the goal of separating the public API
from its underlying implementation.
• After the interface has been imported with the #import directive,
you can instantiate objects with the alloc/init pattern shown above.
As you can see, instantiation is a two-step process: first you must
allocate some memory for the object by calling the alloc method,
then you need to initialize it so it’s ready to use. You should never
use an uninitialized object.
• To call a method on an Objective-C object, you place the instance
and the method in square brackets, separated by a space:
[toyota setModel:@"Toyota Corolla"]
Instantiation and Usage

#import "Car.h"
!
int main(int argc, const char * argv[])
{
@autoreleasepool
{
// Create an instance of Car object
Car *toyota = [[Car alloc]init];
// Use get/set model method to update car's model
[toyota setModel:@"Toyota Corolla"];
NSLog(@"Created a %@", [toyota model]);
// Use property to update car's model
toyota.model = @"Toyota Camry";
NSLog(@"Changed the car to %@", toyota.model);
// Call method drive of toyota object
[toyota drive];
}
return 0;
}
Instantiation and Usage

• The above snippets define instance-level properties and methods,
but it’s also possible to define class-level ones. These are
commonly called “static” methods/properties in other programming
languages (not to be confused with the static keyword).
• Class method declarations look just like instance methods, except
they are prefixed with a plus sign instead of a minus sign. For
example, let’s add the following class-level method to Car.h
// Decalare class method
+ (void) setDefaultModel:(NSString *)model;
Class Methods and Variables

• Similarly, a class method implementation is also preceded by a plus
sign. While there is technically no such thing as a class-level
variable in Objective-C, you can emulate one by declaring a static
variable before deﬁning the implementation:
#import "Car.h"
!
static NSString *_defaultModel;
!
@implementation Car
!
...
!
+ (void)setDefaultModel:(NSString *)model
{
_defaultModel = [model copy];
}
!
@end

• Class methods use the same square-bracket syntax as instance
methods, but they must be called directly on the class, as shown
below. They cannot be called on an instance of that class
([toyota setDefaultModel:@"Model T"] will throw an error).
// Call class method
[Car setDefaultModel:@"Nissan Versa"];

• There are no constructor methods in Objective-C. Instead, an
object is initialized by calling the init method immediately after it’s
allocated. This is why instantiation is always a two-step process:
allocate, then initialize. There is also a class-level initialization
method that will be discussed in a moment.
• init is the default initialization method, but you can also deﬁne your
own versions to accept conﬁguration parameters. There’s nothing
special about custom initialization methods—they’re just normal
instance methods, except the method name should always begin
with init. An exemplary “constructor” method is shown below.
// Declare the contructor
- (id)initWithModel:(NSString *)model;
“Constructor” Methods

• To implement this method, you should follow the canonical
initialization pattern shown in initWithModel: below. The super
keyword refers to the parent class, and again, the self keyword
refers to the instance calling the method. Go ahead and add the
following methods to Car.m.
- (id)initWithModel:(NSString *)aModel
{
self = [super init];
if (self)
{
_model = [aModel copy];
odometer = 0;
}
return self;
}

• In main.m class you can create an instance of Car by using
initWitModel contructor:
// Car.m
Car *toyota = [[Car alloc]initWithModel:@"Toyota Corolla"];

• We’ll be working with a class called Car whose interface resides in
a file named Car.h (also called a “header”) and whose
implementation resides in Car.m. These are the standard file
extensions for Objective-C classes. The class’s header file is what
other classes use when they need to interact with it, and its
implementation file is used only by the compiler.
• Xcode provides a convenient template for creating new classes. To
create our Car class, navigate to File > New > File… or use the
Cmd+N shortcut. For the template, choose Objective-C class
under the iOS > Cocoa Touch category. After that, you’ll be
presented with some configuration options:
Dynamic Typing

• An object’s properties let other objects inspect or change its state.
But, in a well-designed object-oriented program, it’s not possible to
directly access the internal state of an object. Instead, accessor
methods (getters and setters) are used as an abstraction for
interacting with the object’s underlying data.
• The goal of the @property directive is to make it easy to create and
conﬁgure properties by automatically generating these accessor
methods. It allows you to specify the behavior of a public property
on a semantic level, and it takes care of the implementation details
for you.
Properties

• First, let’s take at what’s going on under the hood when we use the
@property directive. Consider the following interface for a simple Car
class and it’s corresponding implementation.
// Car.h
@property BOOL running;
!
// Car.m
@synthesize running = _running;
• The compiler generates a getter and a setter for the running property.
The default naming convention is to use the property itself as the getter,
preﬁx it with set for the setter, and preﬁx it with an underscore for the
instance variable, like so:
- (BOOL)running
{
return _running;
}
!
- (void)setRunning:(BOOL)running
{
_running = running;
}
The @property Directive

• If you don’t like @property’s default naming conventions, you can
change the getter/setter method names with the getter= and
setter= attributes. A common use case for this is Boolean
properties, whose getters are conventionally preﬁxed with is. Try
changing the property declaration in Car.h to the following:
// Car.h
@property (getter = isRunning) BOOL running;
!
• The generated accessors are now called isRunning and
setRunning. Note that the public property is still called running, and
this is what you should use for dot-notation:
// Car.m
Car *honda = [[Car alloc]init];
honda.running = YES; // [honda setRunning:YES]
NSLog(@"%d", honda.running); // [honda isRunning]
NSLog(@"%d", [honda running]); // Error: method no longer exists
The getter= and setter= Attributes

• The readonly attribute is an easy way to make a property read-only.
It omits the setter method and prevents assignment via dot-
notation, but the getter is unaffected. As an example, let’s change
our Car interface to the following. Notice how you can specify
multiple attributes by separating them with a comma.
// Car.h
@property (getter = isRunning, readonly) BOOL running;
!
- (void)startEngine;
- (void)stopEngine;
The readonly Attribute

• Instead of letting other objects change the running property, we’ll
set it internally via the startEngine and stopEngine methods. The
corresponding implementation can be found below.
// Car.m
- (void)startEngine
{
_running = YES;
NSLog(@"Car is running!");
}
!
- (void)stopEngine
{
_running = NO;
NSLog(@"Car is stopped");
}

• Remember that @property also generates an instance variable for
us, which is why we can access _running without declaring it
anywhere (we can’t use self.running here because the property is
read-only). Let’s test this new Car class by adding the following
snippet to main.m.
[honda startEngine];
NSLog(@"%d", honda.running);
honda.running = NO; // Error: read-only property

• Atomicity has to do with how properties behave in a threaded
environment. When you have more than one thread, it’s possible for
the setter and the getter to be called at the same time. This means
that the getter/setter can be interrupted by another operation,
possibly resulting in corrupted data.
// Car.h
@property (nonatomic) NSString *model;
The nonatomic Attribute

• In any OOP language, objects reside in the computer’s memory,
and—especially on mobile devices—this is a scarce resource. The
goal of a memory management system is to make sure that
programs don’t take up any more space than they need to by
creating and destroying objects in an efﬁcient manner.
• Many languages accomplish this through garbage collection, but
Objective-C uses a more efﬁcient alternative called object
ownership. When you start interacting with an object, you’re said to
own that object, which means that it’s guaranteed to exist as long
as you’re using it. When you’re done with it, you relinquish
ownership, and—if the object has no other owners—the operating
system destroys the object and frees up the underlying memory.
Memory Management

• With the advent of Automatic Reference Counting, the compiler
manages all of your object ownership automatically.
Memory Management

• The implementation is shown below. It uses the default accessors
generated by @property. It also overrides NSObject’s description
method, which returns the string representation of the object.
// Person.h
!
!
@interface Person : NSObject
!
@property (nonatomic) NSString *name;
!
@end
The strong Attribute

• The implementation is shown below. It uses the default accessors
generated by @property. It also overrides NSObject’s description
method, which returns the string representation of the object.
// Car.h
!
#import "Person.h"
!
@interface Car : NSObject
!
@property (nonatomic) NSString *model;
@property (nonatomic, strong) Person *driver;
!
@end

• Then, consider the following iteration of main.m:
!
// main.m
!
Person *john = [[Person alloc]init];
john.name = @"John";
honda.model = @"Honda Civic";
honda.driver = john;
NSLog(@"%@ drives a %@", honda.driver, honda.model);

• Most of the time, the strong attribute is intuitively what you want for object
properties. However, strong references pose a problem if, for example,
we need a reference from driver back to the Car object he’s driving. First,
let’s add a car property to Person.h:
// Person.h
!
!
@class Car;
!
@interface Person : NSObject
!
@property (nonatomic) NSString *name;
@property (nonatomic, strong) Car *car;
!
@end
• The @class Car line is a forward declaration of the Car class. It’s like
telling the compiler, “Trust me, the Car class exists, so don’t try to ﬁnd it
right now.” We have to do this instead of our usual #import statement
because Car also imports Person.h, and we would have an endless loop
of imports.
The weak Attribute

• Next, add the following line to main.m right after the honda.driver
assignment:
// main.m
!
honda.driver = john;
john.car = honda; // Add this line
• We now have an owning relationship from honda to john and
another owning relationship from john to honda. This means that
both objects will always be owned by another object, so the
memory management system won’t be able to destroy them even if
they’re no longer needed.
The weak Attribute

!
!
!
!
• This is called a retain cycle, which is a form of memory leak, and
memory leaks are bad. Fortunately, it’s very easy to ﬁx this problem
—just tell one of the properties to maintain a weak reference to the
other object. In Person.h, change the car declaration to the
following:
// Person.h
@property (nonatomic, weak) Person *driver;
The weak Attribute
A retain cycle between the Car and Person classes

• The weak attribute creates a non-owning relationship to car. This
allows john to have a reference to honda while avoiding a retain
cycle. But, this also means that there is a possibility that honda will
be destroyed while john still has a reference to it. Should this
happen, the weak attribute will conveniently set car to nil in order to
avoid a dangling pointer.
The weak Attribute
A weak reference from the Person class to Car

• A common use case for the weak attribute is parent-child data
structures. By convention, the parent object should maintain a
strong reference with it’s children, and the children should store a
weak reference back to the parent. Weak references are also an
inherent part of the delegate design pattern.
• The point to take away is that two objects should never have strong
references to each other. The weak attribute makes it possible to
maintain a cyclical relationship without creating a retain cycle.
The weak Attribute

• The copy attribute is an alternative to strong. Instead of taking
ownership of the existing object, it creates a copy of whatever you
assign to the property, then takes ownership of that. Only objects
that conform to the NSCopying protocol can use this attribute.
• Properties that represent values (opposed to connections or
relationships) are good candidates for copying. For example,
developers usually copy NSString properties instead of strongly
reference them:
// Car.h
@property (nonatomic, copy) NSString *model;
The copy Attribute

• Now, Car will store a brand new instance of whatever value we
assign to model. If you’re working with mutable values, this has the
added perk of freezing the object at whatever value it had when it
was assigned. This is demonstrated below:
// main.m
!
NSMutableString *model = [NSMutableString stringWithFormat:@"Honda Civic"];
honda.model = model;
NSLog(@"%@", honda.model);
[model setString:@"Nissa Versa"];
NSLog(@"%@", honda.model); // Still Honda Civic
• NSMutableString is a subclass of NSString that can be edited in-
place. If the model property didn’t create a copy of the original
instance, we would be able to see the altered string (Nissan Versa)
in the second NSLog() output.
The copy Attribute

Attributes Summary
Attribute Description
getter= Use a custom name for the getter method.
setter= Use a custom name for the setter method.
readonly Don’t synthesize a setter method.
nonatomic Don’t guarantee the integrity of accessors in a multi-threaded
environment. This is more efﬁcient than the default atomic
behavior.strong Create an owning relationship between the property and the
assigned value. This is the default for object properties.
weak Create a non-owning relationship between the property and
the assigned value. Use this to prevent retain cycles.
copy Create a copy of the assigned value instead of referencing the
existing instance.

• Methods represent the actions that an object knows how to
perform. They’re the logical counterpart to properties, which
represent an object’s data. You can think of methods as functions
that are attached to an object; however, they have a very different
syntax.
Methods

• Objective-C methods are designed to remove all ambiguities from
an API. As a result, method names are horribly verbose, but
undeniably descriptive.
// Car.h
!
// Accessors
- (BOOL)isRunning;
- (void)setRunning:(BOOL)running;
- (NSString *)model;
- (void)setModel:(NSString *)model;
!
// Action methods
- (void)startEngine;
- (void)turnToAngle:(double)theAngle;
!
// Constructor methods
- (id)initWithModel:(NSString *)aModel;
- (id)initWithModel:(NSString *)aModel mileage:(double)theMileage;
!
// Factory methods
+ (Car *)car;
+ (Car *)carWithModel:(NSString *)aModel;
Naming Conventions

• Nesting method calls is a common pattern in Objective-C
programs. It’s a natural way to pass the result of one call to another.
Conceptually, it’s the exact same as chaining methods, but the
square-bracket syntax makes them look a little bit different:
Car *car = [[Car alloc]initWithModel:@"Honda Civic" mileage:400];
• First, the [Car alloc] method is invoked, then the init method is
called on its return value.
Nested Calling Methods

• There are no protected or private access modiﬁers for Objective-C
methods—they are all public. However, Objective-C does provide
alternative organizational paradigms that let you emulate these
features.
Protected and Private Methods

• Selectors are Objective-C’s internal representation of a method
name. They let you treat a method as an independent entity,
enabling you to separate an action from the object that needs to
perform it. This is the basis of the Target-Action design pattern, and
it is an integral part of Objective-C’s dynamic typing system.
• There are two ways to get the selector for a method name. The
@selector() directive lets you convert a source-code method name
to a selector, and the NSSelectorFromString() function lets you
convert a string to a selector (the latter is not as efﬁcient). Both of
these return a special data type for selectors called SEL. You can
use SEL the exact same way as BOOL, int, or any other data type.
Selectors

// main.m
!
Car *porsche = [[Car alloc] init];
porsche.model = @"Porsche 911 Carrera";
!
SEL stepOne = NSSelectorFromString(@"startEngine");
SEL stepTwo = @selector(driveForDistance:);
!
// This is the same as:
// [porsche startEngine];
[porsche performSelector:stepOne];
!
// This is the same as:
// [porsche driveForDistance:[NSNumber numberWithDouble:5.7]];
[porsche performSelector:stepTwo withObject:[NSNumber numberWithDouble:5.7]];
Selectors

Documentation
Object-Oriented Programming with Objective-C
https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/OOP_ObjC/Introduction/
Introduction.html
Programming with Objective-C
https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/
Introduction/Introduction.html

many thanks
to
lamvt@fpt.com.vn
please
say
Stanford University
https://developer.apple.com
Developer Center
http://www.stanford.edu/class/cs193p
xin
chào

Next: Object Oriented Programming with
Objective-C (Part 2)

Session 3 - Object oriented programming with Objective-C (part 1)

Recommended

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to Session 3 - Object oriented programming with Objective-C (part 1) (20)

More from Vu Tran Lam (16)

Recently uploaded (20)

Session 3 - Object oriented programming with Objective-C (part 1)