Software Construction: Encapsulation

In software design we encapsulate both data and computation to limit the number of contact points between different parts of the code.

Advantages

• it makes it easier to understand a piece of code in isolation
• it makes the use of the isolated part by rest of the code less error-prone
• it makes it easier to change one part of the code without breaking anything else

The tendency to use primitive types to represent other abstractions. This is bad design!

Shown with the example of a (bad) card implementation.

Major drawbacks: 

• the representation of a card does not map to the corresponding domain concept
• the representation of a card is coupled to its implementation
• it is easy to corrupt a variable that represents a card

List<Card> deck = new ArrayList<>();

This (as standalone solution) is bad design, because

• a list of cards is not strongly tied to the concept of a deck
• using a list of cards ties the representation of a deck in the program with its implementation
• the structure can easily be corrupted

By returning values as references (i.e. return aRank in getRank) we reveal the underlying implementation of the program, this is bad design! We need to escape the references!

By returning a reference to deck we also return a reference to the underlying implementation (i.e. the client is able to then also use methods of the two cards, even if unwanted!). This is bad design!

getCards() returns a reference to aCards. This is bad design, as the client can then directly edit the deck without using the class Deck!

This is bad design, as the client can directly edit the cards after adding it to the deck!

Having a class that is mostly accessed through getters and setters.

(De.: Unveränderlichkeit) Objects are immutable if their class provides no way to modify the internal state of the object after initialization. E.g. Strings are constant; their values cannot be changed after they are created because String objects are immutable they can be shared (i.e. their reference).

By declaring aRank & aSuit private and omitting setters, we ensure that the class Card is immutable.

We can avoid exposing our internal data by either

• using an Extended Interface: Instead of returning the whole list Cards, we only return one (by the client specified) card reference.
• or Returning Copies: We return a copy of the internal list, thus the client has the data but can't modify the internal data (as he has no reference to it).
• or using the Copy Constructor: We avoid creating a new object with the same reference as the old one by creating a new one with the same internal values of the old one.

???