Pre-assessment notes
Encapsulation
This is something we'll talk about later in the course, along with other
design qualities, but it does come up briefly in both Inf1OP and Inf2C-SE,
so I wondered how much people would know. There was a wide spread, many
people having no idea and many others knowing precisely.
The key idea is that something (data, or functionality) is hidden (has a
capsule placed around it, en-capsul(e)-ated, if you like) so that it can
only be accessed from a specific piece of code, e.g., the code of the class
that owns the data or functionality. E.g., a private attribute or method in
Java. To put it another way, clients of the enclosing unit cannot have a
dependency on the encapsulated thing.
Why is it important?
As someone wrote, "It allows for more maintainable software". It does, in
two distinct ways. Even more generally than that: it allows software to be
more understandable by humans, and that in turn brings many benefits,
including maintainability, but also, a higher chance of being correct in
the first place.
To see this, compare a public attribute with a private one, and consider
these two different situations that can arise.
- Suppose you need to change the attribute. For example, suppose it was
a single String attribute storing a name, and you decide that in order to
accommodate a change in requirements, you should be storing first name and
last name as separate strings. If the attribute was private, this is easy.
You replace the single attribute by two, and you change what was a simple
getter (saying return name; say) into a method that puts together
the two new attributes and returns their concatenation (return
(firstName + " " + lastName); say). Clients are unaffected. If you had
a setter method for the old single attribute, you also have to rewrite that.
If the attribute was public, however, you have to maintain it alongside
your new attributes, and make sure that both copies of the information are
kept consistent.
- Next, suppose in the course of debugging you find they're both getting
nonsensical values somehow. How can you fix this problem? For the public
attribute, you're going to have to find every place in the system that
accesses the attribute, and see whether it's being set to something
nonsensical there. For the private one, the actual value setting must be
being done inside the class. If there's a setter method, you might not
think you've gained very much: you might still have to look at everywhere
the setter method is invoked (as above, that's why you only have setter
methods if you really need them, by the way, don't just put them in
automatically!) But even then, you can put some extra validation code in
the setter method: you can do this without altering anything outside the
class.
A few basically correct answers to the what is it question:
- It is to... let objects take care of themselves. For example, a method
to let an object A attack an object B - if A kills B, then A should get
points. To see if A has killed B, it should not directly reduce B's health
(i.e. B.health-=1) but call a method in B (E.G
B.getHit(A.getAttackStrength()) )
- Limiting access to an object from other parts of the code. [doesn't
need to be an object, though that's likely to be where you've met it]
- Not completely sure - I believe it a way to hide data such as variables
in a class, and then using getters and setters to retrieve and set the
value of variables. There are also many other elements beyond variables
that can be encapsulated.
- Variables are private and must use getters and setters in order to
obtain/alter them.
- Encapsulation is to hide the internal workings of a class/programme
and only allow others to interact with it through an interface (e.g.
modification of attributes via accessor methods).
This page is maintained by
Perdita Stevens (
perdita@inf.ed.ac.uk
)