Objective C - Week 7 - Thursday

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

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

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
)].

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