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

title	tags	sr-due	sr-interval	sr-ease
12-modelling-behaviour	info201 lecture	2022-05-28	31	250

slides

modelling-behaviour

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

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.

Garbage Notes

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