Object Oriented Programming Development - Week 5

1
Object Oriented ProgrammingDevelopment - Week 5

• By
• Marc Conrad
• University of Luton
• Email
• Marc.Conrad_at_luton.ac.uk
• Room
• D104

2
Module Outline

• Introduction
• The non object oriented basics
• Classes
• Design Approaches
• Testing

• Inheritance
• Aggregation
• Polymorphism
• Multifile Development

3
Today

• Last week
• Encapsulation
• Friendship

4
Types of object

• Four types of object (or any other data type)
• Automatic (local) objects
• External (global) objects
• Static objects
• Dynamic objects

5
Types of object

• Four types of object (or any other data type)
• Automatic (local) objects
• External (global) objects
• Static objects
• Dynamic objects

First three are objects with specific names
6
Types of object

• Four types of object (or any other data type)
• Automatic (local) objects
• External (global) objects
• Static objects
• Dynamic objects

When objects are predictable enough to be
identified at compile time
7
Types of object

• Four types of object (or any other data type)
• Automatic (local) objects
• External (global) objects
• Static objects
• Dynamic objects

No fixed unique name Identified by the memory
address which they occupy
8
Types of object

• Four types of object (or any other data type)
• Automatic (local) objects
• External (global) objects
• Static objects
• Dynamic objects

For objects that cant be defined at compile
time their number or identity may vary at run
time
9
Automatic objects

• Instantiated within the scope of a part of the
  program (between curly brackets somewhere)
• Automatically destroyed when object falls out of
  scope
• visible only within that scope (between when
  object declared and closing )

10
Dynamic objects

• Useful where we cant predict object identities,
  number or lifetimes.
• Created using the new keyword (you get a pointer
  to the object)
• Destroyed using the delete keyword
• Not destroyed automatically You have to do it
  yourself!!

11
new in Java and C

• In Java you have a Cleaner who cleans up your
  mess.

• In C you have to clean your mess yourself.

But the cleaner comes only once a week on
Wednesday,so you have less freedom in
influencing your objects lifetime.
If you dont clean, youend up with a messed
upmemory.
12
Summary

• Automatic/external/static objects
• Have a unique name
• Useful when objects are predictable enough to be
  identified at compile time
• Dynamic objects
• No fixed unique name
• Identified by the memory address which they
  occupy
• For objects that cant be defined at compile
  time their number or identity may vary at run
  time

13
What is Object Oriented Programming?

• Identifying objects and assigning
  responsibilities to these objects.
• Objects communicate to other objects by sending
  messages.
• Messages are received by the methods of an object

• An object is like a black box.
• The internal details are hidden.

14
What is Object Oriented Programming?

• An object is like a black box.
• The internal details are hidden.

15
Example The Person class

• includeltstringgt
• includeltiostreamgt
• class Person
• private
• char name20
• int yearOfBirth
• public
• void displayDetails()
• cout ltlt name ltlt " born in "
• ltlt yearOfBirth ltlt endl
  
• //...

private data
public processes
16
The two parts of an object

• Object Data Methods
• or to say the same differently
• An object has the responsibility to know and the
  responsibility to do.

17
Basic Terminology

• Abstraction is the Representation of the
  essential features of an object. These are
  encapsulated into an abstract data type.
• Encapsulation is the practice of including in an
  object everything it needs hidden from other
  objects. The internal state is usually not
  accessible by other objects.

18
Encapsulation

• What is Encapsulation?
• Preventing unauthorized access to some piece of
  information or functionality.

The key money-saving insight is to separate the
volatile part of some chunk of software from the
stable part. Encapsulation puts a firewall around
the chunk, which prevents other chunks from
accessing the volatile parts other chunks can
only access the stable parts. This prevents the
other chunks from breaking if (when!) the
volatile parts are changed. In context of OO
software, a "chunk" is normally a class or a
tight group of classes.
From the C FAQ Lite
19
Encapsulation
The "volatile parts" are the implementation
details. If the chunk is a single class, the
volatile part is normally encapsulated using the
private and/or protected keywords. If the chunk
is a tight group of classes, encapsulation can be
used to deny access to entire classes in that
group.
The "stable parts" are the interfaces. A good
interface provides a simplified view in the
vocabulary of a user, and is designed from the
outside-in (here a "user" means another
developer, not the end-user who buys the
completed application). If the chunk is a single
class, the interface is simply the class's
public member functions and friend functions. If
the chunk is a tight group of classes, the
interface can include several of the classes in
the chunk.
From the C FAQ Lite
20
Encapsulation
How can I prevent other programmers from
violating encapsulation by seeing the private
parts of my class? Not worth the effort
encapsulation is for code, not people. It
doesn't violate encapsulation for a programmer to
see the private parts of your class, so long as
they don't write code that somehow depends on
what they saw. In other words, encapsulation
doesn't prevent people from knowing about the
inside of a class it prevents the code they
write from becoming dependent on the insides of
the class.
From the C FAQ Lite
21
Encapsulation
Why is it a difference of a person knowing
private parts and code knowing private
parts? Your company doesn't have to pay a
"maintenance cost" to maintain the gray matter
between your ears but it does have to pay a
maintenance cost to maintain the code that comes
out of your finger tips. What you know as a
person doesn't increase maintenance cost,
provided the code you write depends on the
interface rather than the implementation.
From the C FAQ Lite
22
Encapsulation
And what, if the programmer intentionally tries
to access the private parts of a class? "My
recommendation in such cases would be to change
the programmer, not the code" James Kanze, cited
from the C FAQ Lite.
From the C FAQ Lite
23
Encapsulation
Is Encapsulation a Security device?
No! Encapsulation
prevents mistakes, not espionage.
Encapsulation ? Security.
From the C FAQ Lite
24
Breaking Encapsulation Friends

• C provides a way to enable a class or function
  to access the private parts of another class.
• This is done by using the friend keyword in the
  class declaration.

25
Friends of the Creature

• class Creature
• friend void rejuvenate(Creature c)
• friend class Fred
• private
• int yearOfBirth
• public
• Creature(int year)
• yearOfBirth year
• int getYearOfBirth()
• return yearOfBirth

born1997
26
Friends of the Creature

• class Creature
• friend void rejuvenate(Creature c)
• friend class Fred
• private
• int yearOfBirth
• public
• Creature(int year)
• yearOfBirth year
• int getYearOfBirth()
• return yearOfBirth

The function rejuvenate can now access the
private attribute yearOfBirth void
rejuvenate(Creature c) c.yearOfBirth
c.yearOfBirth 5
born1997
27
Friends of the Creature

• class Creature
• friend void rejuvenate(Creature c)
• friend class Fred
• private
• int yearOfBirth
• public
• Creature(int year)
• yearOfBirth year
• int getYearOfBirth()
• return yearOfBirth

The class Fred can now access the private
attribute yearOfBirth class Fred void
mature(Creature c ) c.yearOfBirth
c.yearOfBirth - 5 // ...
born1997
28
Breaking Encapsulation?

• Do friends violate encapsulation?
• No! If they're used properly, they enhance
  encapsulation.

Many people think of a friend function as
something outside the class. Instead, try
thinking of a friend function as part of the
class's public interface. A friend function in
the class declaration doesn't violate
encapsulation any more than a public member
function violates encapsulation both have
exactly the same authority with respect to
accessing the class's non-public parts.
From the C FAQ Lite
29
Friends of the Creature A private
constructor

• class Creature
• friend class Fred
• private
• int yearOfBirth
• Creature(int year)
• yearOfBirth year
• public
• int getYearOfBirth()
• return yearOfBirth

born1997
30
Friends of the Creature A private
constructor
The class Fred (and the class Creature itself)
are now the only classes which are able to
generate Creatures. class Fred public
Creature createCreature97() Creature
pc new Creature(1997) return pc //
...

• class Creature
• friend class Fred
• private
• int yearOfBirth
• Creature(int year)
• yearOfBirth year
• public
• int getYearOfBirth()
• return yearOfBirth

born1997
31
Summary

• Encapsulation is one of the key concepts in
  object oriented programming.
• The friend keyword allows breaking the
  encapsulation.
• However, it depends on the point of view if
  friends do violate the encapsulation principle.