CPP14 - Encapsulation

EncapsulationMichael Heron

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.

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.

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.

Back To Our Account Classclass 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); };

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Class Diagrams• At their simplest, class diagrams are just boxes with lines

connecting them to other boxes.• They show the relationship between classes only.

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.

Class Diagram with Attributes

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.