The document discusses encapsulation in object-oriented programming, emphasizing the importance of keeping data and functions together within classes to prevent issues associated with global scope. It highlights private and public visibility modifiers, the impact of changes in code, and the necessity of maintaining a clear interface to ensure usability and consistency. Lastly, it introduces class diagrams as tools to represent relationships and attributes within classes, enhancing the understanding of complex object-oriented architectures.

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.