Component Based Software Engineering Chapter 6 Polymorphism

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

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

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

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.

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

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

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

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

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.

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

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!

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

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

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

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

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

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

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

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

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

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