Chapter 4 - Object State

Question 1

static/compile-time perspective

Answer 1

looking at a software system in terms of the software elements declared in the source code and the relations between them

Question 2

dynamic perspective

Answer 2

• looking at a software system in terms of objects - corresponds to the set of all values and references held by the variables in a program at different points in time
• can be represented by object, state and sequence diagrams

Question 3

object state

Answer 3

the particular pieces of information the object represents at a given moment

Question 4

concrete state

Answer 4

collection of values stored in the object’s fields

Question 5

abstract state

Answer 5

arbitrarily defined subset of the concrete state space

Question 6

state space

Answer 6

• set of all possible states for a variable/object
• with fields of reference types, the cardinality of the state space increases dramatically

Question 7

stateless objects

Answer 7

objects that do not store any values (eg. function objects which have no fields besides constants)

Question 8

state diagrams

Answer 8

• used to represent how objects can transition from one abstract state to another as a reaction to external events (like method calls)
• represent a dynamic view of a software system

Question 9

TEMPORARY FIELD antipattern

Answer 9

information should not be stored in an object unless it uniquely contributes to the intrinsic value represented by the object

Question 10

ways to model absent values

Answer 10

1. optional types
2. NULL OBJECT design pattern

Question 11

Optional types

Answer 11

• to make a value of type T optional for a variable, declare variable to be of type Optional<T></T>
• to represent absent variable -> Optional.empty()
• to represent a value that can never be null -> Optional.of(value)
• to represent a value which can be null -> Optional.ofNullable(value)
• to get a value wrapped by instance of Optional -> Optional.get()
• to check if a value is null -> !variable.isPresent()

Question 12

NULL OBJECT design pattern

Answer 12

• relies on polymorphism so only applicable to situations where a type hierarchy is possible
• create a class to represent a NULL object

Question 13

default methods

Answer 13

methods that have an implementation in the interface which is applicable to instances of all implementing types (don’t need to provide implementation for them in implementing classes but can override them)

Question 14

final keyword

Answer 14

• prevents changing the value of a field after initialization -> can only be assigned value in declaration of variable or in constructor
• does not make referenced objects immutable

Question 15

identity

Answer 15

• refers to fact that we are referring to a particular object, represented by object ID
• two different objects with same value will still have different IDs

Question 16

== operator

Answer 16

• returns true if two operands evaluate to the same VALUE
• for reference types -> same value means referring to same object ID

Question 17

object equality

Answer 17

• can be programmer defined by overriding equals methods in Object class (default implementation is a == b)
• need to override hashCode

Question 18

FLYWEIGHT design pattern

Answer 18

• used to ensure uniqueness of objects of a class
• control creation of flyweight objects by:
  1. private constructor
  2. static flyweight store: keeps a collection of flyweight objects
  3. static access method: returns unique flyweight object that corresponds to some identification key

Question 19

SINGLETON design pattern

Answer 19

• provides a way to ensure there is only one instance of a given class at any point in the execution of the code
• template:
  1. private constructor
  2. global variable
  3. accessor method called instance()