October 01, 2009

Issues
October 01, 2009
October 01, 2009
October 01, 2009
October 01, 2009
 October 01, 2009

Protocols
 October 01, 2009

A
Protocol
in
Objective‐C
is

identical
in
functionality
to
an

interface
in
Java,
or
a
purely

virtual
class
in
C++
 October 01, 2009

A
protocol,
in
Objective‐C,
is
a
list
of
method
declarations

that
any
class
that
wishes
to
adopt
the
protocol
must

implement.

We
write
a
protocol
in
a
similar
way
to
writing
an

@interface
declaration.
Here
is
one
typical
protocol.


@protocol
Document

‐
(int)
wordCount;

‐
(id)
title:
(char
*)
new_title;

‐
(char
*)
title;

@end
 October 01, 2009

@protocol Printing
-(void) print;
@end
 October 01, 2009

The protocol specification is quite simple. it is basically

@protocol ProtocolName
(methods you must implement)
@end.
·

·
To conform to a protocol, you put the protocols you're conforming to
in <>'s, and comma separate them.

Example: @interface SomeClass <Protocol1, Protocol2, Protocol3>

 October 01, 2009

Code
Time!
 October 01, 2009

The
methods
that
the
protocol

requires
to
be
implemented
are
not

required
to
be
in
the
list
of
methods

for
the
header
file.


As
you
can
see,
Complex.h
doesn't

have
a
definition
for
‐(void)
print,

but
it
still
implements
it
since
it

conforms
to
the
protocol.
 October 01, 2009

One
unique
aspect
of
Objective‐C's
interface
system
is
how
you
specify

types.
Rather
than
specifying
it
like
Java
or
C++
as:
Printing
*someVar
=

(
Printing
*
)
frac;
for
example,
you
use
the
id
type
with
a
restricted

protocol:
id
<Printing>
var
=
frac;
This
allows
you
to
dynamically
specify

a
type
that
requires
multiple
protocols,
all
with
one
variable.


Such
as:
id
<Printing,
NSCopying>
var
=
frac;

Much
like
using
@selector
for
testing
an
object's
inheritance,
you
can

use
@protocol
to
test
for
conformance
of
interfaces.

[object
conformsToProtocol:
@protocol(
SomeProtocol
)]
returns
a

BOOL
if
the
object
conforms
to
that
protocol.


This
works
the
same
for
classes
as
well:
[SomeClass

conformsToProtocol:
@protocol(
SomeProtocol
)].
 October 01, 2009

Categories
 October 01, 2009

When
you
want
to
add
methods
to
a
class,

you
typically
extend
it.
However
this

solution
isn't
always
perfect,
especially
if

you
want
to
rewrite
the
functionality
of
a

class
that
you
don't
have
the
source
code

to.
Categories
allow
you
to
add

functionality
to
already
existing
classes

without
extending
them.
 October 01, 2009

@interface Fraction (Math)

-(Fraction*) add: (Fraction*) f;
-(Fraction*) mul: (Fraction*) f;
-(Fraction*) div: (Fraction*) f;
-(Fraction*) sub: (Fraction*) f;
@end
 October 01, 2009

Code Time!
 October 01, 2009

The
magic
here
is
the
two

@implementation
and
@interface
lines:

@interface
Fraction
(Math)
and

@implementation
Fraction
(Math).

There
can
only
be
one
category
with
the

same
name.
Additional
cateogies
may
be

added
on
with
different
but
unqiue
names.


Categories
can't
add
instance
variables.
 October 01, 2009

Categories
allow
us
to
split
up
a
large
class
into
several
pieces.

Each
can
be
developed
and
created
independently,
and
then

brought
together
at
the
end
to
form
the
class.

As
a
consequence
however,
this
allows
us
some
nice

advantages.
We
can,
in
essence,
extend
the
functionality
of
any

class
that
may
fall
into
our
hands,
whether
it
is
in
a
class
you

create
yourself,
or
in
a
binary
form,
such
as
in
the
Cocoa

frameworks,
we
can
add
a
category
to
NSString
to
provide

functionality
that
the
original
NSString
did
not
provide.

Categories
can
also
be
used
to
override
previous
functionality,

which
allows
us
then
to
"patch"
these
preexisting
classes
also,

which
might
be
provided
with
a
bug.
October 01, 2009