1 Inheritance

1.1 Via Specialisation

Inheritance via specialisation is when something is subclass of something else. Subclasses inherit all public members of their parents. They are able to replace or customise inherited existing methods and add their own specialsed methods (including constructors). example class diagram, example java code

1.2 Via Interface

An interface is a class that specifies a set of common behaviour.

public methods and constant fields only (no variable fields)
effectively an “inheritable” public API (no implementation) ⇒ Catalogue must implement all Search methods
independent of inheritance via specialisation
a class can implement multiple interfaces

example class diagram

in Java:

example java code
Examples of built-in Java interfaces: (also see INFO 202)
Collection: collections of objects (lists, sets, maps, …)
Iterable: collections that can be iterated over
Comparable: objects that have a concept of ordering

1.3 Public vs Private

The public API defines what a class can do
- e.g., read and write data, manage a list of items
- effectively a “promise” or “contract” to other classes that use it
- should be as stable as possible
The private implementation defines how a class behaves
- e.g., data stored in memory vs. CSV files vs. SQL DBMS vs. …, unsorted lists vs. sorted vs. unique vs. …
- can change to improve speed, reduce memory, redesign architecture, take advantage of new language features, …
- shouldn’t be exposed to other classes

1.3.1 Why

More stable public API:
- doesn’t expose internal implementation details
- can change internals without breaking promised behaviour
More flexible public API:
- less coding required to switch implementations
- can easily switch internal implementations on the fly (e.g., print receipt vs. save as PDF vs. send as email)
Programming to an interface (i.e., public API):
- encapsulate public API into a class or (Java) interface
- subclass or implement this to create specific implementations
- use the top-level class or interface everywhere you would otherwise use the specialised implementations

2 Behaviour

2.1 Anaemic domain models

In an anaemic domain model the domain objects also called Models contain (mostly) only data, and very little logic.

The services set the properties of the models via getters and setters. This defines the logic of the application

anaemic example

Processor objects are often used in anaemic systems to move data between objects. Also called services

processor example

2.2 Rich domain models

In a rich domain model logic is contained within real domain models. And the service layer thin and used only for third party services.

This means that the behaviour of the domain models is encapsulated within them

rich example

#unfinished

4.1 KiB Raw Blame History Unescape Escape