September 29, 2009
Issues
September 29, 2009
September 29, 2009
September 29, 2009
September 29, 2009
September 29, 2009
September 29, 2009
September 29, 2009
September 29, 2009
Protocols
September 29, 2009
A
Protocol
in
Objective‐C
is
identical
in
functionality
to
an
interface
in
Java,
or
a
purely
virtual
class
in
C++
September 29, 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
September 29, 2009
@protocol Printing -(void) print; @end
September 29, 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
September 29, 2009
Code
Time!
September 29, 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.
September 29, 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
var
=
frac;
This
allows
you
to
dynamically
specify
a
type
that
requires
multiple
protocols,
all
with
one
variable.
Such
as:
id
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
)].
September 29, 2009
Categories
September 29, 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.
September 29, 2009
@interface Fraction (Math) -(Fraction*) add: (Fraction*) f; -(Fraction*) mul: (Fraction*) f; -(Fraction*) div: (Fraction*) f; -(Fraction*) sub: (Fraction*) f; @end
September 29, 2009
Code Time!
September 29, 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.
September 29, 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.
September 29, 2009