1

Object Oriented ProgrammingDevelopment - Week 5

By: Marc ConradUniversity of Luton

Email: Marc.Conrad@luton.ac.ukRoom: D104

2

Module Outline

IntroductionThe non object

oriented basicsClassesDesign ApproachesTesting

InheritanceAggregationPolymorphismMultifile

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 nameIdentified 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 can’t 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 can’t predict object identities, number or lifetimes.

Created using the new keyword (you get a pointer to the object)

Destroyed using the delete keywordNot 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 don‘t 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 can’t be defined at compile time:

their number or identity may vary at run time

13

What is Object Oriented Programming?

An object is like a black box.

The internal details are hidden.

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

14

What is Object Oriented Programming?

An object is like a black box.

The internal details are hidden.

Example: The Person class#include<string>#include<iostream>class Person{ private: char name[20]; int yearOfBirth;public: void displayDetails() { cout << name << " born in " << yearOfBirth << 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.

From the C++ FAQ Lite

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.

19

Encapsulation

From the C++ FAQ Lite

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.

20

Encapsulation

From the C++ FAQ Lite

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.

21

Encapsulation

From the C++ FAQ Lite

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.

22

Encapsulation

From the C++ FAQ Lite

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

23

Encapsulation

From the C++ FAQ Lite

Is Encapsulation a Security device?

No!

Encapsulation prevents mistakes, not espionage.

Encapsulation Security.

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.

Friends of the Creatureclass Creature { friend void rejuvenate(Creature & c);friend class Fred;private: int yearOfBirth;public: Creature(int year) { yearOfBirth = year; } int getYearOfBirth() { return yearOfBirth; } };

born1997

Friends of the Creatureclass Creature { friend void rejuvenate(Creature & c);friend class Fred;private: int yearOfBirth;public: Creature(int year) { yearOfBirth = year; } int getYearOfBirth() { return yearOfBirth; } };

born1997

The function rejuvenate can now access the private attribute yearOfBirth:

void rejuvenate(Creature & c) { c.yearOfBirth = c.yearOfBirth + 5; }

Friends of the Creatureclass Creature { friend void rejuvenate(Creature & c);friend class Fred;private: int yearOfBirth;public: Creature(int year) { yearOfBirth = year; } int getYearOfBirth() { return yearOfBirth; } };

born1997

The class Fred can now access the private attribute yearOfBirth:

class Fred { void mature(Creature &c ) { c.yearOfBirth = c.yearOfBirth - 5; }// ... }

28

Breaking Encapsulation?

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

encapsulation.

From the C++ FAQ Lite

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.

Friends of the Creature – A private constructorclass Creature { friend class Fred;

private: int yearOfBirth; Creature(int year) { yearOfBirth = year; }public: int getYearOfBirth() { return yearOfBirth; } }; born1997

Friends of the Creature – A private constructorclass Creature { friend class Fred;

private: int yearOfBirth; Creature(int year) { yearOfBirth = year; }public: int getYearOfBirth() { return yearOfBirth; } }; born1997

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;}// ... }

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.