Object-oriented
programmingconceptsand
componentsystems
LenaBuffoni/TDDD05
Title/Lecturer
Anobject…
•
•
•
•
is a unit of instantiation, it has a unique identity
may have state and this can be externally observable
encapsulates its state and behavior
reusable
Objects can be thought of as a typing system.
•  Is everything an object?
APRIL 6, 2016
2
Title/Lecturer
APRIL 6, 2016
Whatisacomponent?
•  “A software component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only. A software component can be
deployed independently and is subject to
composition by third parties.”
•  Object => Component?
•  Component => Object ?
3
Title/Lecturer
WhiteboxvsBlackbox
APRIL 6, 2016
4
APRIL 6, 2016
Title/Lecturer
Leanness (ex:
lightweight…)
RobustnessvsLeanness
8557 Chapter 4 p33-48
3/10/02
10:31 PM
5
Page 46
vs
What a component is and is not
46
Robustness (ex: multiplatform, flexible,
configurable…)
Leanness
Robustness
0
100
% reuse (“outsourcing”)
Figure 4.1 Opposing forcefields of robustness (limited context dependence) and leanness (limited
“fat”), as controlled by the degree of reuse within a component.
a component designer has a choice. Increasing the context dependencies usually leads to leaner components by means of reuse, but also to smaller markets.
Title/Lecturer
APRIL 6, 2016
StandardizaEonandnormalizaEon
•  Increases leanness of components
•  Improves interoperability
Ex: TCP/IP standard, we reduce the kinds of bolts in
use …
•  Generic vs domain specific standardization
Ex: general UML standard vs specific UML-RT standard
6
Title/Lecturer
APRIL 6, 2016
Interfaces
•  A point of interaction between the component and
the environment
7
APRIL 6, 2016
Title/Lecturer
InterfacesinUML
InterfacesinJava
interface Animal {
public void eat();
public void travel();
}
GUI
8
Title/Lecturer
APRIL 6, 2016
DirectvsIndirectinterfaces
•  Direct (procedural) interfaces = implements
+ provided directly by a component corresponding
to interfaces of traditional libraries.
+ Definition & implementation belong to one
component.
•  Indirect(object) interfaces = has a
+ provided by objects implemented by a component,
corresponding to object interfaces.
+ Definition & implementation might sit in different
components.
9
8557 Chapter 5 p49-82
3/10/02
10:32 PM
Page 52
APRIL 6, 2016
Title/Lecturer
Example
Components, interfaces, and re-entrance
52
Wordprocessing component
Grammar-checking component
WordProcessor
GrammarChecker
3
4
1
2
TextServices
«interface»
ICheckGrammar
Text services mediator component
“has a”
implements
Figure 5.1 Example of direct and indirect interfaces.
5.1.2
Versions
Attention:
version checking in
In a component world, versions of components can be prolific. For example,
many
vendors may provide
various “upwards-compatible,” enhanced versions
indirect
interfaces
is tricky!
of a successful component. Traditional version management – often based on
the assignment of major and minor version numbers – assumes that the versions of a component evolve at a single source. In a free market, the evolution
of versions is more complex and management of version numbers can become
a problem in its own right.
A subtle aspect of versioning arises when moving from direct to indirect
10
Title/Lecturer
APRIL 6, 2016
Designbycontract
•  Between a client and a provider
•  What the client needs to do to use the interface.
•  What the provider has to implement to meet the
services promised by the interface.
11
Title/Lecturer
APRIL 6, 2016
Pre,postcondiEonsandinvariants
•  precondition A condition that must be true of the
parameters of a method and/or data members, if the
method is to behave correctly, PRIOR to running the
code in the method.
•  postcondition A condition that is true AFTER
running the code in a method.
•  class invariant A condition that is true BEFORE
and AFTER running the code in a method (except
constructors and destructors)
12
Title/Lecturer
APRIL 6, 2016
Whatelseshouldbeconsideredina
contract?
•  Extra functional (ex performance) requirements
•  Reliance on implicit/undocumented features
13
Title/Lecturer
APRIL 6, 2016
14
ExamplestackimplementaEon
•  What actions should be possible with a stack?
–  push() add an element to the top
–  pop() remove an element to the top
–  size() return the number of elements in stack
–  isEmpty() returns true, if stack is empty (size is 0)
–  peek returns the top element, without removing it
Title/Lecturer
APRIL 6, 2016
15
Invariants
•  first points to NULL or a valid node
•  first points to the top of the stack
•  each node's next pointer points to a node or a valid
node
•  the number of nodes is equal to the size data member
APRIL 6, 2016
Title/Lecturer
push(stringstr)
•  precondition true
•  postcondition
size == size' + 1 AND list == str + list'.
ADA:
procedure PUSH(S: in out STACK; E: in ELEM) is
begin if S.INDEX = SIZE then raise OVERFLOW; endif;
S.INDEX := S.INDEX + 1;
S.SPACE(S.INDEX) := E;
end PUSH;
16
Title/Lecturer
APRIL 6, 2016
OCL(ObjectConstraintLanguage)
•  Part of the UML standard Formal Specification
Language
•  Standardized formal semantics from OCL 2.0
onwards
17
Title/Lecturer
APRIL 6, 2016
ContractConformance
•  Contracts may be modified from version to version
•  What will be affected if the implementation of an
interface is revised from one version to another?
–  Respects the old contract by not breaking any old
clients
–  Breaks some old client(s) and results in a failure
of services
18
Title/Lecturer
APRIL 6, 2016
ContractConformance
•  Contract conformance
–  Pre-condition: Overriding method must demand
the same or less from its client
–  Post-condition: Overriding method must promise
the same or more to its client
–  Exceptions: overriding method must not throw
any exceptions overridden doesn’t
19
Title/Lecturer
APRIL 6, 2016
ParEalorcompletecorrectness?
•  Simple pre- and postconditions => Partial
correctness
•  A partially correct operation either terminates
correctly or does not terminate at all.
•  The requirement that an operation should also
eventually terminate leads to total correctness.
20
Title/Lecturer
APRIL 6, 2016
Types,subtypes,andtypechecking
•  Types can be viewed as simplified contracts
•  Safety by construction – viability of components
•  Typing polymorphism : subtypes
21
APRIL 7, 2016
Title/Lecturer
22
Polymorphism
Shape
Polymorphism is the ability of something to appear in
multiple forms, depending on context, and the ability
of different things to appear the same in a certain
context.
When can we
replace one subtype for another?
Rectangle
Triangle
Liskov's Substitution
Principle
Title/Lecturer
APRIL 6, 2016
CovarianceandContravariance
•  Covariance:
New parameter types, return value types, or exception types of
replacing methods are proper subtypes (more specific) of the
corresponding original types in the replaced method.
•
Contravariance:
New parameter types, return value types, or exception types of
replacing methods are proper supertypes (more general) of the
corresponding original types in the replaced method.
•  Invariance:
New parameter types etc. are of exactly the same type as in the
replaced method.
23
APRIL 6, 2016
Title/Lecturer
Covariance:simpletypes
public class Animal{}
public class Mammal extends Animal { }
public class Tiger extends Mammal { }
Animal
Mammal
Mammal m = new Tiger();
Animal a = m;
Tiger t = a;
OK
OK
NOT OK
Tiger
24
Title/Lecturer
APRIL 6, 2016
Covariance&Contravariance:methods
classSuper{
voiddoSomething(Stringparameter)
}
classSubextendsSuper{
voiddoSomething(Objectparameter)
}
Contravariance
Covariance
classSuper{
ObjectgetSomething(){}
}
classSubextendsSuper{
StringgetSomething(){}
}
25
Title/Lecturer
Invariance:Lists
List<Mammal> mammals = new List<Tiger>();
List<Animal> animals = mammals;
List<Tiger> tigers = animals;
APRIL 6, 2016
26
Title/Lecturer
APRIL 6, 2016
FragileBaseClassProblem
•  How does a class evolve over time?
•  Can a base class be updated without affecting the
system?
27
APRIL 6, 2016
Title/Lecturer
Thesyntac>cfragilebaseclassproblem
•  Is inheritance all that safe?
•  What happens when we edit a base class?
classA{
protectedintx;
protectedvoidm(){x++;}
protectedvoidn(){x++;}
}
classBextendsBase{
protectedvoidm(){
n();
}
}
A gets updated
classA{
protectedintx;
protectedvoidm(){x++;}
protectedvoidn(){m();}
}
28
APRIL 6, 2016
Title/Lecturer
29
Theseman>cfragilebaseclassproblem
Developer A
Developsalibrary
cointainingbaseClassA
Developer B
WritesclassBinheri?ngfromA
UpdatesA(back-wards
compa?ble)
Reinstallslibrary,relinks,runs
app
The release to release
compatibility problem
Application
crashes
Recompilestheapplica?on
All Ok!
APRIL 6, 2016
Title/Lecturer
MulEple-inheritance
A
B
C
D
Diamond inheritance principle
30
Title/Lecturer
APRIL 6, 2016
MulEple-inheritance&mixins
•  Multiple inheritance can be used in a particular style
called mixin inheritance (Bracha and Cook, 1990).
•  A class inherits interfaces from one superclass and
implementations from several superclasses
•  Each focusing on distinct parts of the inherited
interface.
•  The inherited classes are called mixins, as they are
used to mix implementation fragments into a class.
31
Title/Lecturer
APRIL 6, 2016
Summary
•  Different structuring concepts: objects, components,
interfaces
•  The design process is a constant tradeoff: flexibility
vs robustness, simplicity vs completeness
•  Promise more – get more
•  All technologies have limits and pitfalls
32