Download Beyond 2000 Beyond Object-Orientation

Beyond 2000, Beyond Object-Orientation
Intro
GP
AOP
FP
Com
End
László Kozma <[email protected]>
Ákos Frohner <[email protected]>
Tamás Kozsik <[email protected]>
Zoltán Porkoláb <[email protected]>
Introduction
Intro
GP
AOP
FP
Com
End
•
•
•
•
•
•
•
2000-05-05
Paradigms
Object-orientation
Generic programming
Aspect-oriented programming
Functional programming
Component-oriented software technology
Conclusion
Beyond 2k Beyond OO
2
Object-Orientation
• Object
• Class
– data structure
– operation
– role
Intro
GP
AOP
FP
Com
End
• Inheritance hierarchy
• Polymorphism (inclusion)
2000-05-05
Beyond 2k Beyond OO
3
GP - Example (1)
Intro
GP
AOP
FP
Com
End
2000-05-05
class stack {
public:
virtual void push( ? );
virtual ?
pop();
// ...
private:
int capacity;
int stack_ptr;
?
*elems;
// ...
};
Beyond 2k Beyond OO
class intStack {
public:
void push(int);
int pop();
};
class ptrStack {
public:
void push(char*);
char* pop();
};
4
GP - Example (2)
Intro
GP
AOP
FP
Com
End
2000-05-05
template <typename T>
class stack {
public:
virtual void push( T );
virtual T
pop();
// ...
private:
int capacity;
int stack_ptr;
T
*elems;
// ...
};
Beyond 2k Beyond OO
5
Generic Programming
•
•
•
•
Intro
GP
AOP
FP
Com
End
Compile-time type checking
Automatic instantiation
Efficient ( vs. Reflection )
Simple
• Negative variance: template specialisation
• (Parametric) Polymorphism
2000-05-05
Beyond 2k Beyond OO
6
GP - Standard Template Library
• A. Stepanov, D. Musser
• ADA, C++, JAVA (Pizza, GJ, Collection)
• C++ Standard Template Library
Intro
GP
AOP
FP
Com
End
– containers
– algorithms
– iterators
• Part of the ISO C++ standard (1997)
2000-05-05
Beyond 2k Beyond OO
7
Standard Template Library
Iterator
Find
Vector
Iterator
Intro
GP
AOP
FP
Com
End
2000-05-05
Merge
Iterator
List
Beyond 2k Beyond OO
8
GP - Coexistence with OO
• C++ Standard Library (!= STL)
template <class CharType,
class Attr=char_traits<CharType>,
class Allocator=allocator<T>>
class basic_string { … };
typedef basic_string<char> string;
Intro
GP
AOP
FP
Com
End
• Reduce interface-size
• Template specialisation
2000-05-05
Beyond 2k Beyond OO
9
Aspect-Oriented Programming
• The need - poor modularity:
–
–
–
–
Intro
GP
AOP
FP
Com
End
shared resources (locking)
multi-object protocols
error handling
complex performance optimisations
• The solution - crossing boundaries:
2000-05-05
– crosscutting concerns in one source file (aspect)
– weaver or pre-processor to scatter the aspects
Beyond 2k Beyond OO
10
AOP - OO Example
Monitoring of a system’s state.
The “system”:
Intro
GP
AOP
FP
Com
End
2000-05-05
public class Variable {
private int v;
public Variable() { v = 0; }
public int getV() { return v; }
public void setV(int v) { this.v = v; }
}
Beyond 2k Beyond OO
11
AOP - Monitoring
Monitoring: displaying the state on each change
Solutions:
Intro
GP
AOP
FP
Com
End
– producer-observer pattern
(needs to subclass from a specific class)
– introspection - catching method calls
(needs special run-time architecture like Component
Filters; has runtime overhead)
Goal:
2000-05-05
– do not modify the original source (by hand)
– do not add unnecessary run-time complexity
Beyond 2k Beyond OO
12
AOP - Aspect
Monitoring code:
Intro
GP
AOP
FP
Com
End
2000-05-05
aspect Trace {
advise * Variable.*(..) {
static before {
System.out.println("Entering " +
thisJoinPoint.methodName + " v=" + thisObject.v);
}
static after {
System.out.println("Exiting " +
thisJoinPoint.methodName + " v=" + thisObject.v);
}
}
}
Beyond 2k Beyond OO
13
AOP - AspectJ
• Implementation: Java/AspectJ from Xerox
• weaver: general-purpose source level preprocessor
Intro
GP
AOP
FP
Com
End
2000-05-05
–
–
–
–
–
crossing normal visibility borders
adding new methods
adding common private variables
code segments before and after old methods
affecting otherwise unrelated classes
Beyond 2k Beyond OO
14
AOP - Woven
Intro
GP
AOP
FP
Com
End
2000-05-05
public class Variable {
private int v;
public Variable() { v = 0; }
public int getV() {
int thisResult;
System.out.println("Entering "+"getV"+" v="+this.v);
thisResult = v;
System.out.println("Exiting "+"getV"+" v="+this.v);
return thisResult;
}
public void setV(int v) {
System.out.println("Entering "+"setV"+" v="+this.v);
this.v = v;
System.out.println("Exiting "+"setV"+" v="+this.v);
}
}
Beyond 2k Beyond OO
15
AOP - Coexistence with OO
• Aspects reduce code repetition
– improves readability
– improves maintainability
Intro
GP
AOP
FP
Com
End
• Mature OO design can be applied in large-scale
• Aspects may be written in any language
(weaver implementation is the only limitation)
2000-05-05
Beyond 2k Beyond OO
16
Functional programming languages
• Functional program = a set of function definitions
+ an expression to be evaluated
• Usual properties
Intro
GP
AOP
FP
Com
End
– support parametric polymorphism
(see Generic Programming)
– advance program correctness
– flexible manipulations with functions
• co-exist with object-oriented programming
2000-05-05
Beyond 2k Beyond OO
17
FP - Parametric Polymorphism
• modern functional languages
(ML, Miranda, Haskell, Clean)
length :: [a] -> Int // optional type specification
length [] = 0
length [first:rest] = 1 + length rest
Intro
GP
AOP
FP
Com
End
• application: length [1,2,3,4] evaluates to 4
• applicable to lists regardless of base type
• only one compiled function, used everywhere
2000-05-05
Beyond 2k Beyond OO
18
FP - Program Correctness (1)
• correct programs are hard to write
– formal methods
– testing
•
Intro
GP
AOP
FP
Com
End
formal methods are often hard to use in practice
– code is too large (complexity explosion)
– gap between specification and implementation
•
2000-05-05
solutions
– object-oriented programming
– functional programming
Beyond 2k Beyond OO
19
FP - Program Correctness (2)
What does OOP offer?
Intro
GP
AOP
FP
Com
End
- implementation decisions encapsulated in objects
+ reduce complexity by appropriately structuring the program
+ (sometimes does not work -> see GP, AOP)
- model the real world
+ objects and their relations correspond to entities of the real
world
+ solve the problem in the problem domain
2000-05-05
Beyond 2k Beyond OO
20
FP - Program Correctness (3)
What does FP offer? (1)
- executable specifications
+ radically reduce the gap between specification and
implementation
+ support abstraction by focusing on "what" instead of "how"
Intro
GP
AOP
FP
Com
End
2000-05-05
qsort [] = []
qsort [x:xs] = qsort [y <- xs | y<x]
+++ [x] +++
qsort [y <- xs | y>=x]
Beyond 2k Beyond OO
21
FP - Program Correctness (4)
What does FP offer? (2)
Intro
GP
AOP
FP
Com
End
2000-05-05
- forces programming without side-effects
+ easy to reason about programs
+ simple mathematical machinery
+ semi-automatic proof tools
Beyond 2k Beyond OO
22
FP - Manipulations with
computations (functions)
• functions as parameters or results
+ example: the "map" function, element wise processing
on a list: map inc [1,2,3,4] evaluates to [2,3,4,5]
+ similar possibilities are already present
Intro
GP
AOP
FP
Com
End
• pointers to functions in C
• subprogram types in Modula 2
• functions as generic parameters in Ada
• greater flexibility, increased expressive power
+ e.g. currying: partial applications:
map ((+) 2) [1,2,3,4] evaluates to [3,4,5,6]
2000-05-05
Beyond 2k Beyond OO
23
FP - co-existence with OOP
modern func. langs support many OOP concepts
– abstract data types by type classes - allow alternative
representations - similar to Java interfaces
Intro
GP
AOP
FP
Com
End
2000-05-05
class Stack s e where
instance Stack [e] e where
push :: s e -> s
pop :: s e -> s
top :: s e -> e
push list elem = [elem:list]
pop [first:rest] = rest
top [first:rest] = first
– record types with functional components
• powerful dynamic binding
• existential types -> inhomogeneity
– encapsulation (modules, abstract datatypes)
– subtyping, inheritance and dynamic types
Beyond 2k Beyond OO
24
FP - Conclusion
• functional programming can co-exist with OOP
• the marriage endows OOP with valuable
properties
• promising future
(efficiency problems are disappearing, e.g. Clean)
Intro
GP
AOP
FP
Com
End
2000-05-05
Beyond 2k Beyond OO
25
Component-oriented programming
Intro
GP
AOP
FP
Com
End
• New trend in the development of software
applications is away from closed systems towards
open system.
• Opens systems must be ˝open˝ in at least three
ways:
topology
platform
evolution
2000-05-05
Beyond 2k Beyond OO
26
Component-oriented programming
• Topology
– Open applications run on configurable networks.
• Platform
– The hardware and software platforms are
heterogeneous.
Intro
GP
AOP
FP
Com
End
• Evolution
2000-05-05
– Requirements are unstable and constantly change
Beyond 2k Beyond OO
27
Object-Oriented Software
Development
Intro
GP
AOP
FP
Com
End
• It partially addresses these needs by hiding data
representation and implementation details behind
object-oriented interfaces, thus permitting multiple
implementations of objects to coexists while
protecting clients from changes in implementation
or representation.
2000-05-05
Beyond 2k Beyond OO
28
Evolution II.
Intro
GP
AOP
FP
Com
End
• Evolution is only partially addressed, however,
since changes in requirements may entail changes
in the way that the objects are structured and
configured.
• It is necessary to view each application as only
one instance of a generic class of applications,
each built up of reconfigurable software
components.
2000-05-05
Beyond 2k Beyond OO
29
Component
Intro
GP
AOP
FP
Com
End
• The notion of component is more general than that
of an object, and in particular may be of either
much finer or coarser granularity.
• An object encapsulates data and its associated
behavior, whereas a component may encapsulate
any useful software abstraction.
2000-05-05
Beyond 2k Beyond OO
30
From Methodological Aspect
Intro
GP
AOP
FP
Com
End
• A component is a component because it has been
designed to be used in a compositional way
together with other components. It is designed as
part of a framework of collaborating components.
Components need not be classes and frameworks
need not be abstract class hierarchies.
2000-05-05
Beyond 2k Beyond OO
31
Examples
• Valid examples of components may be:
Intro
GP
AOP
FP
Com
End
2000-05-05
functions
macros
procedures
templates
modules
Beyond 2k Beyond OO
32
From Technical Aspect
• At a software technology level, the vision of
component-oriented development is a very old
idea, which was already present in the first
developments of structured programming and
modularity.
Intro
GP
AOP
FP
Com
End
2000-05-05
Beyond 2k Beyond OO
33
Implementation
Intro
GP
AOP
FP
Com
End
• Component-oriented software development is not
easy to realize for both technological and
methodological reasons.
• For a programming language to support
component-oriented development, it must
integrate both computational and compositional
aspects of software development.
2000-05-05
Beyond 2k Beyond OO
34
Computational and compositional
aspects
• An application can be viewed simultaneously as a
computational entity that delivers results and
• as a construction of software components that fit
together to achieve those results.
Intro
GP
AOP
FP
Com
End
2000-05-05
Beyond 2k Beyond OO
35
Integration
• The integration of these two aspects is not
straightforward, since their goals may conflict. For
example concurrency mechanisms, which are
computational, may conflict with inheritance,
which is a compositional features
Intro
GP
AOP
FP
Com
End
2000-05-05
Beyond 2k Beyond OO
36
Semantic Foundation
Intro
GP
AOP
FP
Com
End
• In order to achieve a clean integration of
computational and compositional features a
common semantic foundation is needed in which
one may reason about both kinds of features and
their interplay.
• The key concepts of such foundations are:
objects
functions
agents.
2000-05-05
Beyond 2k Beyond OO
37
Exact Notion of Components
• A component is a static abstraction with plugs
• Static
– By ˝static˝, we mean that a software component is a long-lived
entity that can be stored in a software base, independently of the
applications in which it has been used.
• Abstraction
Intro
GP
AOP
FP
Com
End
– By “abstraction”, we mean that a component puts a more or less
opaque boundary around the software it encapsulates.
• With plugs
2000-05-05
– “With plugs” means that there are well-defined ways to interact
and communicate with the component (parameters, ports,
Beyond 2k Beyond OO
messages, etc.)
38
Outside view of a component
• Seen from the outside, a component is a single
entity, which may be moved around a copied , and
in particular may be instantiated in a particular
context, where the plugs will be bound to values
or to other components.
Intro
GP
AOP
FP
Com
End
2000-05-05
Beyond 2k Beyond OO
39
Technical Support
• Component-oriented software development not
only requires a change of mind-set and
methodology but it also requires new
technological support.
Intro
GP
AOP
FP
Com
End
2000-05-05
Beyond 2k Beyond OO
40
Technical Support II.
• Some issues that arise:
Intro
GP
AOP
FP
Com
End
2000-05-05
–
–
–
–
–
–
–
paradigm and mechanism for binding components together
structure of a software component
characterization of the composition process
formal model of components and composition,
verification method of correct compositions
concurrent computational model and software
composition.
Beyond 2k Beyond OO
41
Assembling Components
• The fundamental composition mechanisms are the
following:
Intro
GP
AOP
FP
Com
End
2000-05-05
- functional composition
- blackboard
- extensibility.
Beyond 2k Beyond OO
42
Functional composition
Intro
GP
AOP
FP
Com
End
• This is the most fundamental composition mechanism. In
this paradigm one entity is first encapsulated and
parameterized as a functional abstraction, and is
instantiated by receiving arguments that are bound to its
parameters. This compositional mechanism occurs in
nearly every programming environment not only in
functional programming languages.
2000-05-05
Beyond 2k Beyond OO
43
Blackboard
• Agent environments use a global composition mechanism
often called a blackboard.
Intro
GP
AOP
FP
Com
End
• A blackboard is a shared space, known by every
component, in which information can be put and retrieved
at particular locations. For systems of agents
communicating through channels, the blackboard is the
global space of channel names.
2000-05-05
Beyond 2k Beyond OO
44
Extensibility
Intro
GP
AOP
FP
Com
End
• Object-oriented systems have introduced a new
paradigm for software composition with the notion
of extensibility - the possibility of adding
functionality to a component while remaining
“compatible” with its previous uses.
• Extensibility is obtained in object-oriented
languages through inheritance
2000-05-05
Beyond 2k Beyond OO
45
Structure of a Software Component
Intro
GP
AOP
FP
Com
End
• Components are static entities; moreover, they always
consists of some kind of abstraction.
• Static software entities are procedures, functions, modules,
classes etc.
- A procedure is an abstraction for a sequence of
instructions.
- A class is an abstraction for a collection of objects.
- A module is a a set of named abstractions.
• All software components are treated as first-class values
that can be passed as parameters to other components.
2000-05-05
Beyond 2k Beyond OO
46
The Composition Process
• A component -oriented lifecycle is needed.
Intro
GP
AOP
FP
Com
End
2000-05-05
Beyond 2k Beyond OO
47
Verification of Composition
Intro
GP
AOP
FP
Com
End
• Whenever components are assembled to perform a
common task, there is always an implicit contract
between them about the terms of the collaboration.
• Two approach can be taken for dealing with verifying
the correctness of a configuration:
- Meyer’s approach used in Eiffel
- improve the expressiveness of type system.
2000-05-05
Beyond 2k Beyond OO
48
Concurrency and Components
• Features needed to model in a language that supports
component-oriented development:
- Active Objects: objects can be viewed as
autonomous agents or processes.
- Components: they are abstractions over the
computational space of active objects.
Intro
- Composition: generalized composition is supported,
GP
not just inheritance.
AOP
FP
- Types: both objects and components have typed
Com
End
interfaces.
- Subtypes: subtyping should be based on a notion of
“plug compatibility“. Beyond 2k Beyond OO
2000-05-05
49
Conclusion
Old and new paradigms could/should live together:
multi-paradigm programming
Advantages:
Intro
GP
AOP
FP
Com
End
2000-05-05
–
–
–
–
–
OO: mature large-scale design, good modularity
GP: parametrised type constructs
AOP: crosscutting concerns
FP: formal-proof, data-flow optimisation
Components: easy deployment and configuration
Beyond 2k Beyond OO
50