mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 05:14:06 -06:00
191 lines
7.1 KiB
Markdown
191 lines
7.1 KiB
Markdown
---
|
||
title: "12-modelling-behaviour"
|
||
tags:
|
||
- cosc201
|
||
- lecture
|
||
sr-due: 2022-04-10
|
||
sr-interval: 3
|
||
sr-ease: 250
|
||
---
|
||
[slides](https://blackboard.otago.ac.nz/bbcswebdav/pid-2892846-dt-content-rid-18407618_1/courses/INFO201_S1DNIE_2022/2022/lectures/lecture_12_slides.pdf)
|
||
|
||
- 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. |