Object Oriented Programming Development - Week 5

1. By: Marc Conrad University of Luton Email: Marc.Conrad@luton.ac.uk Room: D104 Object Oriented ProgrammingDevelopment - Week 5

2. Introduction The non object oriented basics Classes Design Approaches Testing Inheritance Aggregation Polymorphism Multifile Development Module Outline

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 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 keyword • Not destroyed automatically: You have to do it yourself!!

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

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

14. An object is like a black box. The internal details are hidden. What is Object Oriented Programming?

15. #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

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

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

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

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

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

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.