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

2. 2 Module Outline zIntroduction zThe non object oriented basics zClasses zDesign Approaches zTesting z Inheritance z Aggregation z Polymorphism z Multifile Development

3. 3 Today: zLast week zEncapsulation zFriendship

4. 4 Types of object zFour types of object (or any other data type) yAutomatic (local) objects yExternal (global) objects yStatic objects yDynamic objects

5. 5 Types of object zFour types of object (or any other data type) yAutomatic (local) objects yExternal (global) objects yStatic objects yDynamic objects First three are objects with specific names

6. 6 Types of object zFour types of object (or any other data type) yAutomatic (local) objects yExternal (global) objects yStatic objects yDynamic objects When objects are predictable enough to be identified at compile time

7. 7 Types of object zFour types of object (or any other data type) yAutomatic (local) objects yExternal (global) objects yStatic objects yDynamic objects No fixed unique name Identified by the memory address which they occupy

8. 8 Types of object zFour types of object (or any other data type) yAutomatic (local) objects yExternal (global) objects yStatic objects yDynamic objects For objects that can’t be defined at compile time: their number or identity may vary at run time

9. 9 Automatic objects zInstantiated within the scope of a part of the program (between curly brackets somewhere) zAutomatically destroyed when object falls out of scope zvisible only within that scope (between when object declared and closing } )

10. 10 Dynamic objects zUseful where we can’t predict object identities, number or lifetimes. zCreated using the new keyword (you get a pointer to the object) zDestroyed using the delete keyword zNot destroyed automatically: You have to do it yourself!!

11. 11 new in Java and C++ zIn Java you have a „Cleaner“ who cleans up your mess. z 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, you end up with a messed up memory.

12. 12 Summary Automatic/external/static objects zHave a unique name zUseful when objects are predictable enough to be identified at compile time Dynamic objects zNo fixed unique name zIdentified by the memory address which they occupy zFor objects that can’t be defined at compile time: their number or identity may vary at run time

13. 13 What is Object Oriented Programming? An object is like a black box. The internal details are hidden. z Identifying objects and assigning responsibilities to these objects. z Objects communicate to other objects by sending messages. z Messages are received by the methods of an object

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

15. Example: The Person class #include class Person{ private: char name[20]; int yearOfBirth; public: void displayDetails() { cout << name << " born in " << yearOfBirth << endl; } //... }; private data public processes

16. 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. 17 Basic Terminology zAbstraction is the Representation of the essential features of an object. These are ‘encapsulated’ into an abstract data type. zEncapsulation 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. 18 Encapsulation zWhat is Encapsulation? zPreventing 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. 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. 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. 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. 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. 23 Encapsulation From the C++ FAQ Lite Is Encapsulation a Security device? No! Encapsulation prevents mistakes, not espionage. Encapsulation  Security.

24. 24 Breaking Encapsulation – Friends zC++ provides a way to enable a class or function to access the private parts of another class. zThis 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; } }; born1997 The function rejuvenate can now access the private attribute yearOfBirth: void rejuvenate(Creature & c) { c.yearOfBirth = c.yearOfBirth + 5; }

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; } }; born1997 The class Fred can now access the private attribute yearOfBirth: class Fred { void mature(Creature &c ) { c.yearOfBirth = c.yearOfBirth - 5; } //... }

28. 28 Breaking Encapsulation? zDo friends violate encapsulation? zNo! 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.

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 class 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. 31 Summary zEncapsulation is one of the key concepts in object oriented programming. zThe friend keyword allows breaking the encapsulation. zHowever, it depends on the point of view if friends do violate the encapsulation principle.