61FIT3SE1 - Software Engineering 1

Lecture 2
Type Hierarchy (2)
Data abstraction
What is data abstraction?

 Simply put, data abstraction is the modeling of real

objects using programming language.
 It allows us to extend the programming language
with new data types.
 In a given context, preserving relevant information
and discarding irrelevant information.
{
name: “Car”,
model: “M1”,
color: “red”,
power: 450
}
Features of data abstraction
 Representation (rep): the equivalent of real
object properties in programming language.
 E.g. A String is equivalent to a name, an int is
equivalent to a person’s age…
 Abstraction function: the mapping function
between real object and virtual object’s instance
variables
 Rep invariant: a statement of conditions that all
legitimate objects satisfy
 Not all objects of the class are legitimate representations
of abstract objects
 E.g. {name: “Quan”, age: -1} is not a valid person
object
 Data abstraction specification

Specifying the rep

 Use @attributes tag in Javadoc

comment block before class
header
 List the names and data types
of attributes
Specifying the abstract function

 Abstract function is the

mapping between real object
and virtual object
 It is implemented in the
toString() method
 Use @object tag
 Describe a typical object
Specifying the abstract function

 In the @effects tag of each constructor

 Describe the object created by the constructor
Specifying the rep invariant

 Rep invariant refers to the

conditions which all legitimate
objects satisfy
 It is implemented by the repOk()
method along with validateX()
methods where X is an attribute.
 To specify, use
@abstract_properties tag in the
class header comment
Specify supertype & subtypes

 Supertype is a class Something wrong???

 Use extends keyword
 Supertype is an interface
 Use implements keyword
 Specify a supertype with common behavior
 Specify each subtype relative to the supertype:
 Adding new attributes (modify rep) if needed
 Specify new or overriding behaviors
 Annotate overriding operations with @Override
Class/interface rules

 Class can be a subtype of:

 One class and/or
 Multiple interfaces
 Interface can only be a subtype of another interface
 Interface has specifications and implementations
 Implementations are specified using extension methods
 Extension methods has default keyword
 Object is the (root) supertype of all types
 Need not be specified
Class/interface rules

 Interfaces can have attributes

 Interface attributes are public static final by default
 Interfaces cannot have constructor
 Interface methods are public abstract by default
Substitution principle

 Cannot create objects of abstract classes or interfaces

 But it’s possible to use abstract classes or interfaces
as data type for variables
 Used as apparent type
 Actual type is one of the subtypes
Specialize the rep invariant
 Given a supertype named Super and an attribute A,
the following is a specialization of the rep invariant
of A in a subtype:
Example: Bus's restriction on weight

P_Vehicle.weight ⋀ min(weight) = 5000

Vehicle's
Bus's further
restriction restriction
on weight on weight
(inherited)
Example: Car's restriction on weight

P_Vehicle.weight ⋀ min(weight) = 2000

Vehicle's
Car's further
restriction restriction
on weight on weight
(inherited)
Specify overriding methods

 An overriding method in the subtype must satisfy

two rules in relation to the overridden method:
 Header rule
 Methods rule
Header rule

 Overriding method must be header compatible

with the overridden method.
 Same signature
 Method name
 Number and types of parameters
 Order of parameters
 Return type: same type or one of the subtypes
 Same thrown Exceptions
Are these correct overriding
methods?
 Method to be overridden:
 validateWeight(double w): boolean
 Candidate overriding methods:
 validateWeight(float w): boolean
 validateWeight(double w): int
 validateW(double w): boolean
 validateWeight(double w)
 validateWeight(): boolean
Are these correct overriding
methods?
 Method to be overridden:
 validateWeight(double w): boolean
 Candidate overriding methods:
 validateWeight(float w): boolean -> different param
 validateWeight(double w): int -> different type
 validateW(double w): boolean -> different name
 validateWeight(double w) -> different type (void)
 validateWeight(): boolean -> different param
Example: different return type

 Method to be overridden:
 getInstance(): Vehicle
 Overriding method:
 getInstance(): Car
 Reason for compatibility:
 Car is a subtype of Vehicle
Methods rule

 Pre-condition (@requires) of overriding method is the

same as or weaker than that of overridden method.
 Post-condition (@effects) of overriding method is the
same or stronger than that of overridden method.

Precondition rule: Presuper >= presub

Post condition rule: (Presuper && Postsub)>=
Postsuper
Qualities of subtype specification

 To conform to the substitution principle, a subtype

specification must satisfy 3 substitution rules:
 Signature rule: subtype must have all the methods of
the supertype with compatible signatures
 Methods rule: pre- and post-condition rules
 Properties rule: subtype must not violate supertype's
rep invariant
Implement a type hierarchy in Java

 Use keyword super to refer to supertype's members

 Can access protected members of super
 Implementation can be full or partial
 An abstract class is partial
 This is not completely true because interfaces can
also have method body
 Overriding repOk() must invoke super.repOk()
 To ensure Properties rule
Subtypes with additional attributes

 Design specification of the subtype needs to take

into account the additional attributes:
 Class header specification
 Rep @attributes
 Abstract function @object
 @rep_invariant
 Constructors may have extra argument(s)
 New operations may be needed, e.g.
getter/setter/validator
 Supertype's operations may need to be overridden
 Especially repOk() and toString()
Abstract class

 A super-type that cannot be instantiated

 Though still have constructors
 Provides either partial or full implementation
 Partial implementation must contain abstract
methods
Multiple implementations

 Example: there are many types of Lists

 The same behavior
 Different underlying implementations
 The implemented type can be defined either by an
interface or by an abstract class
 The whole point is to defer implementation details
to subclasses
 The subtype:
 Must provide constructors
 Strictly follow behaviors defined by supertype
Multiple implementations

 ArrayList and Vector

 Same behaviors
 Different versions of concrete implementations
Java’s dynamic method dispatching

 A run-time mechanism to find the right version

of an overridden method to execute
 It is how Java implements runtime
polymorphism
 The implementation from the actual or runtime
type of the variable will be chosen.
Summary

 THs make program structure easier to

understand
 THs enables shared specification for the related
types
 THs supports extensibility
 Subtypes obey the substitution principle