Software Construction: Encapsulation
Cards to learn encapsulation
Cards to learn encapsulation
Kartei Details
| Karten | 15 |
|---|---|
| Sprache | Deutsch |
| Kategorie | Informatik |
| Stufe | Universität |
| Erstellt / Aktualisiert | 03.01.2020 / 10.01.2020 |
| Weblink |
https://card2brain.ch/box/20200103_software_construction_encapsulation
|
| Einbinden |
<iframe src="https://card2brain.ch/box/20200103_software_construction_encapsulation/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
System Decomposition software design principle (Definition)
Decompose a system into distinct manageable abstractions. For a decomposition to be useful, the abstractions have to be well isolated from each other.
Encapsulation (Definition)
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
Primitive Obsession Design antipattern (Definition)
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
Example representing a card using enums
Example representing a deck of cards using a list
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
Example Scope & Visibility Restrictions (Simple Card implementation)
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!
Example (simple) Cards Object Diagram
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!
Example (simple) Deck Implementation
getCards() returns a reference to aCards. This is bad design, as the client can then directly edit the deck without using the class Deck!
Example Object Diagram returning a reference to an internal object
Example of storing an external reference internally
This is bad design, as the client can directly edit the cards after adding it to the deck!
Design antipattern Inappropriate Intimacy (Definition)
Having a class that is mostly accessed through getters and setters.
Immutability (Definition)
(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).
Example immutable class Card
By declaring aRank & aSuit private and omitting setters, we ensure that the class Card is immutable.
How do we avoid exposing internal data? (3 methods)
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.
Example Object Diagram of exposing internal data (?)
???
