Object oriented programming development week 5 l.jpg
Advertisement
This presentation is the property of its rightful owner.
1 / 31

Object Oriented Programming Development - Week 5 PowerPoint PPT Presentation

By: Marc Conrad University of Luton Email: [email protected] Room: D104 Object Oriented Programming Development - Week 5 Introduction The non object oriented basics Classes Design Approaches Testing Inheritance Aggregation Polymorphism

Download Presentation

Object Oriented Programming Development - Week 5

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Object oriented programming development week 5 l.jpg

By:

Marc Conrad

University of Luton

Email:

[email protected]

Room:

D104

Object Oriented ProgrammingDevelopment - Week 5


Module outline l.jpg

Introduction

The non object oriented basics

Classes

Design Approaches

Testing

Inheritance

Aggregation

Polymorphism

Multifile Development

Module Outline


Today l.jpg

Today:

  • Last week

  • Encapsulation

  • Friendship


Types of object l.jpg

Types of object

  • Four types of object (or any other data type)

    • Automatic (local) objects

    • External (global) objects

    • Static objects

    • Dynamic objects


Types of object5 l.jpg

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


Types of object6 l.jpg

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


Types of object7 l.jpg

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


Types of object8 l.jpg

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


Automatic objects l.jpg

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 } )


Dynamic objects l.jpg

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 keyword

  • Not destroyed automatically: You have to do it yourself!!


New in java and c l.jpg

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

In C++ you have to clean your mess yourself.

new in Java and C++

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.


Summary l.jpg

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


What is object oriented programming l.jpg

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

What is Object Oriented Programming?


What is object oriented programming14 l.jpg

An object is like a black box.

The internal details are hidden.

What is Object Oriented Programming?


Example the person class l.jpg

#include<string>

#include<iostream>

class Person{

private:

char name[20];

int yearOfBirth;

public:

void displayDetails() {

cout << name << " born in "

<< yearOfBirth << endl;

}

//...

};

Example: The Person class

private

data

public

processes


The two parts of an object l.jpg

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.

=

+


Basic terminology l.jpg

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.


Encapsulation l.jpg

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


Encapsulation19 l.jpg

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


Encapsulation20 l.jpg

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


Encapsulation21 l.jpg

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


Encapsulation22 l.jpg

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


Encapsulation23 l.jpg

Encapsulation

Is Encapsulation a Security device?

No!

Encapsulation prevents mistakes, not espionage.

Encapsulation  Security.

From the C++ FAQ Lite


Breaking encapsulation friends l.jpg

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 creature l.jpg

class Creature {

friend void rejuvenate(Creature & c);

friend class Fred;

private:

int yearOfBirth;

public:

Creature(int year) {

yearOfBirth = year;

}

int getYearOfBirth() {

return yearOfBirth;

}

};

Friends of the Creature

born1997


Friends of the creature26 l.jpg

class Creature {

friend void rejuvenate(Creature & c);

friend class Fred;

private:

int yearOfBirth;

public:

Creature(int year) {

yearOfBirth = year;

}

int getYearOfBirth() {

return yearOfBirth;

}

};

Friends of the Creature

The function rejuvenate can now access the private attribute yearOfBirth:

void rejuvenate(Creature & c) {

c.yearOfBirth = c.yearOfBirth + 5;

}

born1997


Friends of the creature27 l.jpg

class Creature {

friend void rejuvenate(Creature & c);

friend class Fred;

private:

int yearOfBirth;

public:

Creature(int year) {

yearOfBirth = year;

}

int getYearOfBirth() {

return yearOfBirth;

}

};

Friends of the Creature

The class Fred can now access the private attribute yearOfBirth:

class Fred {

void mature(Creature &c ) {

c.yearOfBirth = c.yearOfBirth - 5;

}

// ...

}

born1997


Breaking encapsulation l.jpg

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


Friends of the creature a private constructor l.jpg

class Creature {

friend class Fred;

private:

int yearOfBirth;

Creature(int year) {

yearOfBirth = year;

}

public:

int getYearOfBirth() {

return yearOfBirth;

}

};

Friends of the Creature – A private constructor

born1997


Friends of the creature a private constructor30 l.jpg

class Creature {

friend class Fred;

private:

int yearOfBirth;

Creature(int year) {

yearOfBirth = year;

}

public:

int getYearOfBirth() {

return yearOfBirth;

}

};

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;

}

// ...

}

born1997


Summary31 l.jpg

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.


  • Login