quartz/content/notes/12-modelling-behaviour.md

title	tags	sr-due	sr-interval	sr-ease
12-modelling-behaviour	cosc201 lecture	2022-04-13	2	230

slides

• method signatures
• inheritance of behaviour
• lower level sequencing and flow of control
• compartmentalisation into "subsystems"

1 Example of Linked UML (not realistic)

2 Inheritance

2.1 Inheriting behaviour via specialisation

e.g.,

• subclass of item
  • inherit all public members of Item
  • can replace or customeise any intherited method
  • can add their own specialised methods (including constructors)
  • can’t concurrently be subclasses of anything else (single inheritance)
• Things that know how to use Item will also accept Book or Disc.

2.1.1 Specialisation in Java

2.2 Inheriting behaviour via implenting an interface

• Search 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
• Things that know how to use Search will also accept Catalogue.

2.2.1 Interface in java

• 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

2.3 Public API vs private implementation

• 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

2.4 Why public and private are decoupled

• 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.5 Java collection interface example

• A collection is a container for groups of objects:
  • e.g., lists, sets, stacks, trees, …
  • common behaviour (public API): add, remove, count items, …
  • specialised behaviour (private implementation): indexing, uniqueness, sorting, …
• Java’s Collection interface defines common behaviour:
  • add() or remove() items
  • get size() of collection
  • …
• All Java collection types implement Collection.

Anything coded to work with Collection will accept any Java collection type. (e.g., ArrayList, HashSet, TreeMap, …)

2.5.1 Bad example

• Internal details (ArrayList) are exposed in public API.
• What if requirements change so that each product can appear only once? (requires HashSet)
• Could change all ArrayList to HashSet, but:
  • need to update everywhere getAllProducts() and getProductsByName() are called! (⇒ massive breakage potential)
  • what if requirements change again

2.5.2 Good Example

• Public API specifies Collection. (general)
• Private implementation uses ArrayList. (specific)
• Everything outside Inventory sees only Collection. (internal details not exposed)
• Can switch to HashSet, TreeSet, … without breaking anything.

3 Behaviour in Domain models

3.1 Rich domain models

• True OO involves sending objects “native instructions” beyond basic getter/setter methods:
  • e.g., they can save, display, update, validate, etc., themselves
  • often requires communicating with other objects
• Advantages:
  • better encapsulation ⇒ more scope for reuse
  • methods are highly cohesive (focused)
  • natural fit with programming to an interface
• Disadvantages:
  • many “chicken and egg” situations ⇒ harder to use
  • bordering on taking things too far (too much abstraction)
  • well beyond comfort zone of many developers (“exotic”)

3.1.1 Rich domain example: Library system

3.2 Contrast with anaemic domain models

• Objects have relatively little “native” behaviour: (if any)
  • mostly just state
  • don’t inherit from anything else (class or interface)
  • getters/setters don’t really encapsulate much
  • methods manipulate only internal state (no external communication)
  • generally referred to as JavaBeans in Java (also POJO)
• Require a lot of “plumbing” code to shift data into and out of objects so we can do something useful with it.
• De facto standard for most programmers/systems

3.3 Reducing the plumbing in anaemic models

• Frequently need to move data between domain objects and other (sub)systems, e.g.:
  • GUI components (see INFO 202)
  • data stores (also see Lecture 17)
  • barcode management subsystem
  • shipping (sub)system
  • inventory (sub)system
  • …
• “Processor objects” can encapsulate these interactions:
  • effectively “(sub)system APIs” that group related behaviour
  • either classes or (Java) interfaces, as appropriate
  • methods take relevant domain objects as arguments
• Third-party frameworks can reduce the amount of code you need to write even further. (see INFO 202)

4 Lecture summary

• There are a variety of behavioural diagrams in UML.
• Behaviour can be inherited directly via specialisation, or indirectly by implementing an interface.
• interfaces decouple public API from private implementation
• programming to an interface
• Domain models can be “rich” or “anaemic”.
• anaemic more common
• use “processors” to encapsulate “plumbing” code

5 Revision questions

1. Compare and contrast the two typical approaches to inheriting behaviour in OO systems.
2. What does it mean to “program to an interface” and why is this important?
3. Compare and contrast “rich” versus “anaemic” domain models with regards to behaviour.
4. Give an example of a “processor” in the context of OO system design and explain why these are useful.