CPP14 - Encapsulation


Published on

This is an introductory lecture on C++, suitable for first year computing students or those doing a conversion masters degree at postgraduate level.

Published in: Software, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

CPP14 - Encapsulation

  1. 1. Encapsulation Michael Heron
  2. 2. Introduction • One of the things that distinguishes object orientation from other kinds of programming is the tight coupling between functions and data. • This is a principle known as encapsulation. • In this lecture we are going to talk about why this is such an important technique. • And the problems it was designed to resolve.
  3. 3. Scope • Cast your minds back to a few weeks ago when we talked about global scope. • I mentioned this was an easy way to cause problems in large programs. • By storing data along with the methods that act on that data (in a class), it is possible to have access to data without global scope. • Variables inside a class have class-wide scope.
  4. 4. Encapsulation • Encapsulation is the principle of keeping data and functions together in one unit. • The class • By doing this, we have a highly portable unit of data we can manipulate. • But only through the functions that we set. • We can set an interface on an object that permits us fine- grained control over access.
  5. 5. Back To Our Account Class class Account { private: int balance; int overdraft; public: int query_balance(); void set_balance (int); int query_overdraft(); void set_overdraft (int); bool adjust_balance (int); };
  6. 6. Private and Public • We set sections of the code to be either private or public. • private for variables • public for functions • These are known as visibility modifiers. • They change how visible these things are to other pieces of code. • There exists a third called protected. • Of more niche benefit.
  7. 7. Private • Private visibility means that variables (or functions) are available only to the class in which they are defined. • We can access balance and overdraft as variables within the methods of our object. • We cannot access them outside of that object. • We do this to make sure that people cannot simply set the value on our data. • They have to go through methods we provide
  8. 8. Public • Public means anything has access. • It’s the highest level of visibility. • We reserve this visibility for methods that we don’t mind everyone being able to use. • These methods make up our interface to the object. • We use a pair of such methods around private variables. • We call these access methods • Usually a query_x and a set_x.
  9. 9. Impact of Change • It’s very common when writing a program to have to change the way things work. • Alas, this comes with major side-effects for many situations. • When working with other developers especially, you need to be wary. • The interface to the objects you write is a kind of informal contract with your colleagues. • It’s important to be respectful when developing.
  10. 10. Impact of Change • Impact of Change defines how much code is likely to need changed if you make an adjustment to your code. • The higher the impact, the more code will need modified. • Some things are almost always safe to do. • Add in variables. • Add in methods • Some things are almost never safe to do. • Change what a method does
  11. 11. Impact of Change • In large object oriented programs, there may be thousands of classes. • All interrelated in complex ways. • It is not possible to know which objects may be using public methods and variables in your code. • You have to assume if it can be accessed, it will be accessed. • Can’t change code indiscriminately. • That’s not respectful.
  12. 12. Impact of Change • Instead, what we do is restrict visibility. • To private, ideally. • We expose as public only those methods we are happy to support. • This limits the impact of change. • We only need to change things in our own class if we modify things. • Important to be able to make adjustments in your code. • Private access permits this.
  13. 13. What is the benefit? • Simplify documentation. • External documentation can focus on only relevant functions. • Can ensure fidelity of access. • If the only access to data is through methods you provide, you can ensure consistency of access. • Hides the implementation details from other objects. • In large projects, a developer should not have to be aware of how a class is structures. • Simplifies code • All access to the object through predefined interfaces.
  14. 14. Designing A Class • A properly encapsulated class has the following traits. • All data that belongs to the class is stored in the class. • Or at least, represented directly in the class. • All attributes are private. • There’s almost never a good reason to make an attribute public. • Hardly ever a good reason to make an attribute protected.
  15. 15. The Class Interface • Classes have a defined interface. • This is the set of public methods they expose. • A properly encapsulated class has a coherent interface. • It exposes only those methods that are of interest to external classes. • A properly encapsulated class has a clean divide between its interface and its implementation.
  16. 16. Interfaces • The easiest way to think of an interface is with a metaphor. • Imagine your car’s engine. • You don’t directly interact with the engine. • You have an interface to that car engine that is defined by: • Gears • Pedals • Ignition • Likewise with the car wheels. • Your steering wheel is the interface to your wheels. • As long as the interface remains consistent… • It doesn’t matter what engine is in the car. • Change the interface, and you can no longer drive the car the same way.
  17. 17. Interface and Implementation • Within a properly encapsulated class, it does not matter to external developers how a class is implemented. • I know what goes in • I know what comes out • The interface to a class can remain constant even while the entirety of the class is rewritten. • Not an uncommon act in development.
  18. 18. Interface and Implementation • It’s important to design a clean an effective interface. • It’s safe to change encapsulated implementation. • It’s usually not safe to change a public interface. • You are committed to the code that you expose publicly. • When new versions of Java deprecate existing functionality, they never just switch it off.
  19. 19. Interface • Our interface may expose a set of public methods with a certain signature. • Return type • Name • Parameters • As long as we keep those signatures constant, it doesn’t matter how our class works internally.
  20. 20. Object Oriented Terminology • Object orientation comes with an extra jargon burden. • As with most things in programming. • Variables in classes are usually known as attributes. • It just means ‘a variable that belongs to a class’ • Functions are usually known as methods. • Or behaviours.
  21. 21. Object Oriented Programs • The relationship between objects and classes becomes very complex in many computer programs. • Some means of representing this complexity ‘at a glance’ is useful. • This is what a class diagram is used for. • It gives the static view of a program’s architecture. • Other techniques exist too. • They vary in effectiveness.
  22. 22. Class Diagrams • At their simplest, class diagrams are just boxes with lines connecting them to other boxes. • They show the relationship between classes only.
  23. 23. Class Diagrams • At the next level of usefulness, class diagrams also contain information about attributes and methods. • Attributes in the second row • Methods in the third • At their best, class diagrams contain class relationships, methods, attributes, and the visibility of each. • They also explicitly show multiplicity. • How many of one object relate to how many of another.
  24. 24. Class Diagram with Attributes
  25. 25. Summary • Today we talked about encapsulation. • Storing attributes along with the methods that act on them. • It is a powerful technique for ensuring fidelity of our objects. • People can’t change the except through the interfaces we provide. • Good object design is to keep attributes private. • And permit access only through accessor methods.