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

1. Encapsulation
Michael Heron

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Class Diagram with Attributes

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.