Intr o GP AOP FP Com End Beyond 2000, Beyond Object- Orientation László Kozma <[email protected]> Ákos Frohner <[email protected]> Tamás Kozsik <[email protected]> Zoltán Porkoláb <[email protected]>
Jan 05, 2016
IntroGP
AOPFP
ComEnd
Beyond 2000, Beyond Object-Orientation
László Kozma <[email protected]>
Ákos Frohner <[email protected]>
Tamás Kozsik <[email protected]>
Zoltán Porkoláb <[email protected]>
2000-05-05 Beyond 2k Beyond OO 2
IntroGP
AOPFP
ComEnd
Introduction
• Paradigms• Object-orientation• Generic programming• Aspect-oriented programming• Functional programming• Component-oriented software technology• Conclusion
2000-05-05 Beyond 2k Beyond OO 3
IntroGP
AOPFP
ComEnd
Object-Orientation
• Object• Class
– data structure
– operation
– role
• Inheritance hierarchy• Polymorphism (inclusion)
2000-05-05 Beyond 2k Beyond OO 4
IntroGP
AOPFP
ComEnd
GP - Example (1)
class stack {
public:
virtual void push( ? );
virtual ? pop();
// ...
private:
int capacity;
int stack_ptr;
? *elems;
// ...
};
class intStack {public: void push(int); int pop();};
class ptrStack {public: void push(char*); char* pop();};
2000-05-05 Beyond 2k Beyond OO 5
IntroGP
AOPFP
ComEnd
GP - Example (2)
template <typename T>
class stack {
public:
virtual void push( T );
virtual T pop();
// ...
private:
int capacity;
int stack_ptr;
T *elems;
// ...
};
2000-05-05 Beyond 2k Beyond OO 6
IntroGP
AOPFP
ComEnd
Generic Programming
• Compile-time type checking• Automatic instantiation• Efficient ( vs. Reflection )• Simple
• Negative variance: template specialisation
• (Parametric) Polymorphism
2000-05-05 Beyond 2k Beyond OO 7
IntroGP
AOPFP
ComEnd
GP - Standard Template Library
• A. Stepanov, D. Musser• ADA, C++, JAVA (Pizza, GJ, Collection)• C++ Standard Template Library
– containers
– algorithms
– iterators
• Part of the ISO C++ standard (1997)
2000-05-05 Beyond 2k Beyond OO 8
IntroGP
AOPFP
ComEnd
Standard Template Library
Vector
List
Find
Merge
Iterator
Iterator
Iterator
2000-05-05 Beyond 2k Beyond OO 9
IntroGP
AOPFP
ComEnd
GP - Coexistence with OO
• C++ Standard Library (!= STL)
• Reduce interface-size• Template specialisation
template <class CharType, class Attr=char_traits<CharType>, class Allocator=allocator<T>>class basic_string { … };
typedef basic_string<char> string;
2000-05-05 Beyond 2k Beyond OO 10
IntroGP
AOPFP
ComEnd
Aspect-Oriented Programming
• The need - poor modularity: – shared resources (locking)
– multi-object protocols
– error handling
– complex performance optimisations
• The solution - crossing boundaries:– crosscutting concerns in one source file (aspect)
– weaver or pre-processor to scatter the aspects
2000-05-05 Beyond 2k Beyond OO 11
IntroGP
AOPFP
ComEnd
AOP - OO Example
Monitoring of a system’s state.
The “system”:public class Variable {
private int v;
public Variable() { v = 0; }
public int getV() { return v; }
public void setV(int v) { this.v = v; }
}
2000-05-05 Beyond 2k Beyond OO 12
IntroGP
AOPFP
ComEnd
AOP - Monitoring
Monitoring: displaying the state on each change
Solutions:– 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:– do not modify the original source (by hand)
– do not add unnecessary run-time complexity
2000-05-05 Beyond 2k Beyond OO 13
IntroGP
AOPFP
ComEnd
AOP - Aspect
Monitoring code: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);
}
}
}
2000-05-05 Beyond 2k Beyond OO 14
IntroGP
AOPFP
ComEnd
AOP - AspectJ
• Implementation: Java/AspectJ from Xerox
• weaver: general-purpose source level preprocessor– crossing normal visibility borders
– adding new methods
– adding common private variables
– code segments before and after old methods
– affecting otherwise unrelated classes
2000-05-05 Beyond 2k Beyond OO 15
IntroGP
AOPFP
ComEnd
AOP - Woven
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);
}
}
2000-05-05 Beyond 2k Beyond OO 16
IntroGP
AOPFP
ComEnd
AOP - Coexistence with OO
• Aspects reduce code repetition– improves readability
– improves maintainability
• 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 17
IntroGP
AOPFP
ComEnd
Functional programming languages
• Functional program = a set of function definitions + an expression to be evaluated
• Usual properties– 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 18
IntroGP
AOPFP
ComEnd
FP - Parametric Polymorphism
• modern functional languages (ML, Miranda, Haskell, Clean)
length :: [a] -> Int // optional type specification
length [] = 0
length [first:rest] = 1 + length rest
• 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 19
IntroGP
AOPFP
ComEnd
FP - Program Correctness (1)
• correct programs are hard to write– formal methods
– testing
• formal methods are often hard to use in practice– code is too large (complexity explosion)
– gap between specification and implementation
• solutions– object-oriented programming
– functional programming
2000-05-05 Beyond 2k Beyond OO 20
IntroGP
AOPFP
ComEnd
FP - Program Correctness (2)
What does OOP offer?- 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 21
IntroGP
AOPFP
ComEnd
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"
qsort [] = []
qsort [x:xs] = qsort [y <- xs | y<x]
+++ [x] +++
qsort [y <- xs | y>=x]
2000-05-05 Beyond 2k Beyond OO 22
IntroGP
AOPFP
ComEnd
FP - Program Correctness (4)
What does FP offer? (2)
- forces programming without side-effects
+ easy to reason about programs
+ simple mathematical machinery
+ semi-automatic proof tools
2000-05-05 Beyond 2k Beyond OO 23
IntroGP
AOPFP
ComEnd
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• 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 24
IntroGP
AOPFP
ComEnd
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 class Stack s e where instance Stack [e] e where
push :: s e -> s push list elem = [elem:list]
pop :: s e -> s pop [first:rest] = rest
top :: s e -> e top [first:rest] = first
– record types with functional components• powerful dynamic binding• existential types -> inhomogeneity
– encapsulation (modules, abstract datatypes)
– subtyping, inheritance and dynamic types
2000-05-05 Beyond 2k Beyond OO 25
IntroGP
AOPFP
ComEnd
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)
2000-05-05 Beyond 2k Beyond OO 26
IntroGP
AOPFP
ComEnd
Component-oriented programming
• 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:
topologyplatformevolution
2000-05-05 Beyond 2k Beyond OO 27
IntroGP
AOPFP
ComEnd
Component-oriented programming
• Topology– Open applications run on configurable networks.
• Platform– The hardware and software platforms are
heterogeneous.
• Evolution– Requirements are unstable and constantly change
2000-05-05 Beyond 2k Beyond OO 28
IntroGP
AOPFP
ComEnd
Object-Oriented Software Development
• 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 29
IntroGP
AOPFP
ComEnd
Evolution II.
• 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 30
IntroGP
AOPFP
ComEnd
Component
• 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 31
IntroGP
AOPFP
ComEnd
From Methodological Aspect
• 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 32
IntroGP
AOPFP
ComEnd
Examples
• Valid examples of components may be:
functionsmacrosprocedurestemplatesmodules
2000-05-05 Beyond 2k Beyond OO 33
IntroGP
AOPFP
ComEnd
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.
2000-05-05 Beyond 2k Beyond OO 34
IntroGP
AOPFP
ComEnd
Implementation
• 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 35
IntroGP
AOPFP
ComEnd
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.
2000-05-05 Beyond 2k Beyond OO 36
IntroGP
AOPFP
ComEnd
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
2000-05-05 Beyond 2k Beyond OO 37
IntroGP
AOPFP
ComEnd
Semantic Foundation
• 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:objectsfunctionsagents.
2000-05-05 Beyond 2k Beyond OO 38
IntroGP
AOPFP
ComEnd
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– By “abstraction”, we mean that a component puts a more or less
opaque boundary around the software it encapsulates.
• With plugs– “With plugs” means that there are well-defined ways to interact
and communicate with the component (parameters, ports, messages, etc.)
2000-05-05 Beyond 2k Beyond OO 39
IntroGP
AOPFP
ComEnd
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.
2000-05-05 Beyond 2k Beyond OO 40
IntroGP
AOPFP
ComEnd
Technical Support
• Component-oriented software development not only requires a change of mind-set and methodology but it also requires new technological support.
2000-05-05 Beyond 2k Beyond OO 41
IntroGP
AOPFP
ComEnd
Technical Support II.
• Some issues that arise:– 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.
2000-05-05 Beyond 2k Beyond OO 42
IntroGP
AOPFP
ComEnd
Assembling Components
• The fundamental composition mechanisms are the following:
- functional composition- blackboard- extensibility.
2000-05-05 Beyond 2k Beyond OO 43
IntroGP
AOPFP
ComEnd
Functional composition
• 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 44
IntroGP
AOPFP
ComEnd
Blackboard
• Agent environments use a global composition mechanism often called a blackboard.
• 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 45
IntroGP
AOPFP
ComEnd
Extensibility
• 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 46
IntroGP
AOPFP
ComEnd
Structure of a Software Component
• 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 47
IntroGP
AOPFP
ComEnd
The Composition Process
• A component -oriented lifecycle is needed.
2000-05-05 Beyond 2k Beyond OO 48
IntroGP
AOPFP
ComEnd
Verification of Composition
• 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 49
IntroGP
AOPFP
ComEnd
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.
- Composition: generalized composition is supported, not just inheritance.
- Types: both objects and components have typed interfaces.
- Subtypes: subtyping should be based on a notion of “plug compatibility“.
2000-05-05 Beyond 2k Beyond OO 50
IntroGP
AOPFP
ComEnd
Conclusion
Old and new paradigms could/should live together:
multi-paradigm programming
Advantages:– 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