1. Component Based Software Engineering
Chapter 6
Polymorphism

2. Polymorphism  Many Shapes
The ability to appear in multiple shapes, depending on context

3. Substitutability
Self-standing contractually specified interfaces decouple client and providers
Interfaces must be specified carefully, not requiring too much or too little
Preconditions, postconditions
Clients may establish more than required by preconditions
Providers may establish more than required by postconditions

4. Pre- and postconditions
Established by certain client
 demanded by interface = Precondition
 required by certain provider
Established by certain provider
 guaranteed by interface = Postcondition
 expected by certain client

5. Implementation of an interface
an implementation of an interface may have a more relaxed precondition and a strengthened postcondition, but:
prec. interface  prec. implementation
postc. implementation  postc. interface
Clients based on the interface contract will not benefit from changes
implementations can be substituted if they satisfy the same contract.

6. Types, Subtypes and Type Checking
Checking if all contracts are satisfied is not feasible
Type checking is feasible
Type names all operations on an interface
number and types of parameters
type of returned values

7. Subtypes Objects may implement more than the required interface
implement multiple interfaces
extended version of required interface
legal because: client expecting a certain type expects an object fulfilling a certain contract
structural subtyping: instead of naming a base class, repeat all operations

8. Subtypes continued Postconditions may be stronger
output parameters & return types can be subtypes of the types laid down in contract
Covariance
Preconditions may be weaker
input parameters can be replaced by supertypes of types laid down in contract
Contravariance
Input/Output variables cannot change!
Invariance

9. Object languages and types
No explicit type system
only run-time checking
examples: Smalltalk, Python
Explicit type system
static type checking
narrowing cast checking at run-time
examples: Java, Component Pascal
Few languages support co- or contravariant changing of types when forming subtypes

10. Types, interfaces & components
Self-standing interfaces have to be fully and explicitly typed to benefit from type checking
Some languages use structural subtyping
can be dangerous, because this only relies on operations and type system, not full contract
but, mostly small chance of actual accidental structural subtyping, except for small interfaces.

11. Multiple interfaces Components can support multiple interfaces
COM IDL: sets of interfaces called categories
useful for testing if a component provides all required interfaces
In Java, C#, Object Pascal, objects can implement multiple interfaces
Java can mimmick categories by letting objects implement an interface that extends all required interfaces

12. Independent extensibility
a system is independently extensible if it is extensible and independently developed extensions can be combined
example: Operating Systems can load and execute applications
WWW-Browsers: plug-ins
Micro-kernels → Components everywhere!

13. Efficiency
Most real micro-kernels fail, because of lack of efficiency: Too many context switches
Same problem with component systems with a lot of communication between components
Solution: carefully choose granularity of components so most interactions stay within component boundaries

14. Safety by construction
Type-safe systems
example Java
automatic memory management (garbage collection)
run-time checks on dangerous operations (array bounds checking)
recheck static properties when loading non-local class files

15. Module safety Components specify which services they require
They are not allowed to access any other services (security manager)
Some languages do not offer module safety, but do offer class safety

16. Safety in multilanguage environment
a strong Interface Definition Language can provide safety features for multiple languages
This often limits languages to a safe subset
components with unsafe methods can be rejected if they do not have the right credentials

17. Safety, security & trust
Very few languages are formally proven to be correct
if proven: implementation can still break correct properties
Trust in safety and security is mostly sociological and can be earned:
UNIX security mechanism
Java security strategies

18. Dimensions of independent extensibility
Traditional class frameworks are frozen at construction time
In independently extensible frameworks extensions from independent sources can be combined
Each feature that can be extended is called a dimension of extensibility
Dimensions are not always orthogonal
Extension space should be complete

19. Bottleneck interfaces & Singleton configurations
Bottleneck interfaces: Fixed interfaces for interactions between indepently extended abstractions
Singleton configurations: Exactly one component extends a dimension

20. Parallel, orthogonal and recursive extensions
Parallel: Same dimension. Sometimes needs to be arbitrated if multiple extensions use the same necessarily unique resource
Orthogonal: Different dimensions. Needs bottleneck interfaces for interaction
Recursive: Introduce a new component framework

21. Evolution & immutability of interfaces & contracts
Contracts cannot be changed at will.
Providers can stop providing an interface
Changes to contracts:
to interface: syntactic change
to specification: semantic change
Contracts can expire
Contracts can be overridden be newer contracts

22. Other forms of polymorphism
Overloading: same name for unrelated operations
Parametric: Same implementation serves a variety of types (C++ templates)
Bounded: Mix between subtype and parametric polymorphism, where there can be restrictions on which types can be used