Feature-oriented programming: A fresh look at objects
Citations
776 citations
Cites methods from "Feature-oriented programming: A fre..."
...We present the AHEAD (Algebraic Hierarchical Equations for Application Design) model that shows how step-wise refinement scales to synthesize multi-ple programs and multiple non-code representations....
[...]
453 citations
444 citations
436 citations
Cites background from "Feature-oriented programming: A fre..."
...Prehofer was the first who recognized the need for making features (and feature interactions) explicit at the programming language level [104]....
[...]
...He proposed to factor out code that is necessary to control the interaction of two features in a separate module, called a lifter [104]....
[...]
...As stated before, Prehofer was the first to note the necessity of making features explicit in code [104]....
[...]
...Prehofer was the first to note the relevance of feature interactions for implementing features [104]....
[...]
429 citations
Cites background from "Feature-oriented programming: A fre..."
...Prehofer (1997) proposed feature-oriented programming as an extension to object-oriented programming....
[...]
References
6,795 citations
"Feature-oriented programming: A fre..." refers methods in this paper
...The notation for type parameters is similar to C++ templates [19]....
[...]
4,383 citations
"Feature-oriented programming: A fre..." refers methods in this paper
...- Composition filters have been proposed in [ 1 ] to compose objects in layers, similar to the feature order in our approach....
[...]
...support this, we will show how to create Java [ 6 ] code for concrete feature se-...
[...]
880 citations
"Feature-oriented programming: A fre..." refers background or methods in this paper
...{ Mixins [2] have been proposed as a basic concept for modeling other inheritance concepts....
[...]
...Its success and its extensive use have led to several approaches to increase exibility (mix-ins [18, 2], around-messages in Lisp [8], class refactoring methods [12]) and to approaches using di erent composition techniques, such as aggregation and (abstract) subclasses....
[...]
...Features are similar to abstract subclasses or mixins [2]....
[...]
...Feature lock lock unlock lock unlock Feature lock Fig Alternative Feature Composition but we work with little endian such a conversion feature can just be added The adaptor feature provides the core functionality here the data conversion and interaction resolution adapts the operations of the object The following features and lifters sketch the solution of pluggable adaptors with features The adaptor feature Big to little endian adds a conversion function which is used in the lifter to provide the put method with big endian data input feature Big to little endian convert to little endian int big to little int a interface low level IO assumes little endian void put int a feature Big to little endian lifts low level IO void put int a super put big to little a A Note on Feature Composition When introducing our model of features there is one important design decision for composing features we assume that features are composed in a particular order Only from the outside interface it is possible to view an object as composed of a set of features There are several reasons for this ordering First it is in the spirit of inher itance and it seems to be the simplest structure capturing the essential object oriented ideas like inheritance Secondly there are problems when viewing features as unordered citizens We show in the following that although intuitive the idea of treating features without order is di cult wrt liftings or inheritance The problem seems to be similar to known problems with multiple inheritance Consider an example of an object integrating two unordered features both implementing a lock Such a con guration with lock and lock to which a fea ture O is added is shown in Figure The interaction is that closing lock should also close lock and vice versa Hence we need liftings from the two features to feature O The simple lifting model is to lift the functions of each feature to O e g by applying all lifters corresponding to the other present features The lifter of lock shall call lock lock and similarly the lifter for lock calls lock lock The problem is which version of lock should be called the lifted or the original of the feature If original is called then all other liftings are ig nored e g if other features are involved Or if the lifted version is called then the procedure diverges In cases where features are fully independent it is not needed to order them But still there is no harm with an ordering in this case and possibly a simple syntactic extension may alleviate the problem Related Work We brie y compare the feature model to other approaches Apart from the de tailed comparison we argue that the feature model provides maximal exibility with static typing and is as simple as possible Mixins have been proposed as a basic concept for modeling other in heritance concepts The main di erence is that we consider interactions and separate a feature from interaction handling If mixins are used also as lifters then the composition of the features and their quadratic number of lifters has to be done manually in the appropriate order Instead we can just select features here Method combination with before after and around messages in CLOS follows a similar idea as interactions As with mixins this does not consider interactions between two classes features and gives no architecture for com position of abstract subclasses Such after or before messages can be viewed as a particular class of interactions Composition lters have been proposed in to compose objects in layers similar to the feature order in our approach Messages are handled from outside in by each layer The main di erence is that we consider interactions on an individual basis and separate a feature from interaction handling Several other approaches allow to change class membership dynamically or propose other compositions mechanisms Note that one of the main ingredients for feature oriented programming lifting to a context can also be found in All of these do not consider a composition archi tecture as done here and address other problems such as name con icts Clearly the idea of features can also be applied to dynamic composition but this remains for future work Extensions We discuss in the following a few extensions and issues which have not been addressed so far As we have focused on feature composition several interesting aspects have not been addressed An aspect not yet considered is hiding For instance when adding the counter to a stack we may not want to inherit the inc and dec functions as they may turn the object into an inconsistent state Such hidings can easily be provided by adding an appropriate interface and by disabling the others Generic liftings via higher order functions are possible in Pizza In the stacks example it is easy to see that lifting to lock is schematic It is natural to express this by higher order functions Consider for instance the following function for lifting lock where void is the Pizza notation for a function type void lift to lock void f if this is unlocked f It can be used e g with void reset lift to lock super reset replaces void reset if this is unlocked super reset This can be made to a default lifter which is applied if no explicit lifters are provided Another extension is to consider exception handling as a feature which can be added as needed This is explored with monadic functional programming in and with rst examples in Java in Conclusions Feature oriented programming is an extension of the object oriented program ming paradigm Whereas object oriented programming supports incremental de velopment by subclassing feature oriented programming enables compositional programming and overwriting as in inheritance is accomplished by resolving feature interactions The recent interest in feature interactions mostly stemming from multimedia applications shows that there is a large demand for expressive composi tion concepts where objects with individual services can be created It also shows that our viewpoint of inheritance as interaction is a very natural concept Compared to classical object oriented programming feature oriented pro gramming provides much higher modularity and exibility Reusability is sim pli ed since for each feature the functional core and the interactions are sep arated This di erence encourages to write independent reusable features and to make the dependencies to other features clear In contrast inheritance with overwriting mixes both which often leads to highly entangled sub classes Compared to other extensions of inheritance the feature model contributes the following ideas The core functionality is separated from the interaction resolution It allows to create objects or classes freely by composing features For the composition we provide a composition architecture which general izes inheritance Acknowledgments The author is indebted to the ECOOP reviewers for their helpful e orts to improve the paper Also M Broy B Rumpe and C Klein contributed comments on earlier versions of this paper M Odersky made this paper possible by providing the Pizza compiler just in time...
[...]
500 citations
"Feature-oriented programming: A fre..." refers background in this paper
...{ Several other approaches allow to change class membership dynamically or propose other compositions mechanisms [9, 20, 4, 16, 10]....
[...]
458 citations
"Feature-oriented programming: A fre..." refers background or methods in this paper
...For Java, parametric classes have just recently been proposed and implemented in the language Pizza [11], which will be the target language for our translations....
[...]
...Feature lock lock unlock lock unlock Feature lock Fig Alternative Feature Composition but we work with little endian such a conversion feature can just be added The adaptor feature provides the core functionality here the data conversion and interaction resolution adapts the operations of the object The following features and lifters sketch the solution of pluggable adaptors with features The adaptor feature Big to little endian adds a conversion function which is used in the lifter to provide the put method with big endian data input feature Big to little endian convert to little endian int big to little int a interface low level IO assumes little endian void put int a feature Big to little endian lifts low level IO void put int a super put big to little a A Note on Feature Composition When introducing our model of features there is one important design decision for composing features we assume that features are composed in a particular order Only from the outside interface it is possible to view an object as composed of a set of features There are several reasons for this ordering First it is in the spirit of inher itance and it seems to be the simplest structure capturing the essential object oriented ideas like inheritance Secondly there are problems when viewing features as unordered citizens We show in the following that although intuitive the idea of treating features without order is di cult wrt liftings or inheritance The problem seems to be similar to known problems with multiple inheritance Consider an example of an object integrating two unordered features both implementing a lock Such a con guration with lock and lock to which a fea ture O is added is shown in Figure The interaction is that closing lock should also close lock and vice versa Hence we need liftings from the two features to feature O The simple lifting model is to lift the functions of each feature to O e g by applying all lifters corresponding to the other present features The lifter of lock shall call lock lock and similarly the lifter for lock calls lock lock The problem is which version of lock should be called the lifted or the original of the feature If original is called then all other liftings are ig nored e g if other features are involved Or if the lifted version is called then the procedure diverges In cases where features are fully independent it is not needed to order them But still there is no harm with an ordering in this case and possibly a simple syntactic extension may alleviate the problem Related Work We brie y compare the feature model to other approaches Apart from the de tailed comparison we argue that the feature model provides maximal exibility with static typing and is as simple as possible Mixins have been proposed as a basic concept for modeling other in heritance concepts The main di erence is that we consider interactions and separate a feature from interaction handling If mixins are used also as lifters then the composition of the features and their quadratic number of lifters has to be done manually in the appropriate order Instead we can just select features here Method combination with before after and around messages in CLOS follows a similar idea as interactions As with mixins this does not consider interactions between two classes features and gives no architecture for com position of abstract subclasses Such after or before messages can be viewed as a particular class of interactions Composition lters have been proposed in to compose objects in layers similar to the feature order in our approach Messages are handled from outside in by each layer The main di erence is that we consider interactions on an individual basis and separate a feature from interaction handling Several other approaches allow to change class membership dynamically or propose other compositions mechanisms Note that one of the main ingredients for feature oriented programming lifting to a context can also be found in All of these do not consider a composition archi tecture as done here and address other problems such as name con icts Clearly the idea of features can also be applied to dynamic composition but this remains for future work Extensions We discuss in the following a few extensions and issues which have not been addressed so far As we have focused on feature composition several interesting aspects have not been addressed An aspect not yet considered is hiding For instance when adding the counter to a stack we may not want to inherit the inc and dec functions as they may turn the object into an inconsistent state Such hidings can easily be provided by adding an appropriate interface and by disabling the others Generic liftings via higher order functions are possible in Pizza In the stacks example it is easy to see that lifting to lock is schematic It is natural to express this by higher order functions Consider for instance the following function for lifting lock where void is the Pizza notation for a function type void lift to lock void f if this is unlocked f It can be used e g with void reset lift to lock super reset replaces void reset if this is unlocked super reset This can be made to a default lifter which is applied if no explicit lifters are provided Another extension is to consider exception handling as a feature which can be added as needed This is explored with monadic functional programming in and with rst examples in Java in Conclusions Feature oriented programming is an extension of the object oriented program ming paradigm Whereas object oriented programming supports incremental de velopment by subclassing feature oriented programming enables compositional programming and overwriting as in inheritance is accomplished by resolving feature interactions The recent interest in feature interactions mostly stemming from multimedia applications shows that there is a large demand for expressive composi tion concepts where objects with individual services can be created It also shows that our viewpoint of inheritance as interaction is a very natural concept Compared to classical object oriented programming feature oriented pro gramming provides much higher modularity and exibility Reusability is sim pli ed since for each feature the functional core and the interactions are sep arated This di erence encourages to write independent reusable features and to make the dependencies to other features clear In contrast inheritance with overwriting mixes both which often leads to highly entangled sub classes Compared to other extensions of inheritance the feature model contributes the following ideas The core functionality is separated from the interaction resolution It allows to create objects or classes freely by composing features For the composition we provide a composition architecture which general izes inheritance Acknowledgments The author is indebted to the ECOOP reviewers for their helpful e orts to improve the paper Also M Broy B Rumpe and C Klein contributed comments on earlier versions of this paper M Odersky made this paper possible by providing the Pizza compiler just in time...
[...]
...If the parameter changes, this amounts to specialization for parameterized classes, which is problematic in typed imperative languages, as discussed in [11]....
[...]
...For translating parameterization into Java we refer to [11]....
[...]
...Fig Composing Objects in the Feature Model of a class which is hence often confused with the type of objects If a feature is added to a combination of n features we have to apply n lifters in order to adapt the inner features As we consider interactions of two features at a time there is only a quadratic number n n n of lifters but an exponential number n k k n of di erent feature combinations can be created For instance in the above example we have features with interactions and about sensible feature combinations This number grows if di erent implementations or variations of features are considered e g single or multi step undo The observation that most but not all interactions can be handled for two features at a time is a major premise of this approach We show that feature oriented programming generalizes object oriented tech niques and gives a new conceptual model of objects and object composition To support this we will show how to create Java code for concrete feature se lections rst using inheritance and then using aggregation and delegation This shows the relations with known techniques and compares both techniques In fact we will show two cases where aggregation is more expressive than inheri tance re ning earlier results To summarize feature oriented programming is advantageous for the follow ing reasons It yields more exibility as objects with individual services can be composed from a set of features This is clearly desirable if many di erent variations of one software component are needed or if new functionality has to be incorporated frequently As the core functionality is separated from interaction handling it provides more structure and clari es dependencies between features Hence it encour ages to write independent reusable code as in many cases subclasses should be an independent entity and not a subclass This also makes class refac toring much easier and sometimes unnecessary The idea is similar to abstract classes but we also cover dependencies between features We show that parameterized features similar to templates work nicely with interactions and liftings which replace inheritance As we will see there can also occur type dependencies between two features which can be clearly speci ed in our setting As we consider only liftings or interactions between two features at a time the model is as simple as possible In case of dependencies between several features liftings between two features can still su ce if we consider auxiliary features see Sec The technical contributions and results in this paper are as follows Translations of a feature based language extension of Java into Java one via inheritance and one via aggregation and delegation An analysis of parameterized features and type dependencies between fea tures followed by a translation into Pizza an extension of Java The translations lead to a detailed comparison of aggregation and inheri tance This unveils two cases where aggregation is more powerful than in heritance due to typing problems The origin of this idea of features in fact goes back to applications of monad theory in functional programming as discussed in In this earlier pa per composition of state monads was compared to inheritance and extended to other monads in functional programming The motivation for this work was the recent development in telecommunication and multimedia software where feature interactions have recently attracted great attention Examples for feature oriented programming in this area are discussed in In the following section we discuss the rst three features of the stack exam ple We de ne the feature oriented extension of Java via translations in Section followed by an extension to parameterized features in Section This section also discusses the remaining two features undo and bound Examples in Section and discussions of the approach in Section and Section conclude the paper A First Example for Feature Oriented Programming In this section we introduce feature oriented programming with the above ex ample modeling variations of stacks The undo and bound features are shown later in Section For this purpose we present an extension of Java in the following Note that we only treat stacks over characters parametric stacks will be considered later We rst de ne interfaces for features Although not strictly needed for our ideas they are useful if there are several implementations for one interface Furthermore they ease translation into Java as a class can implement several interfaces in Java interface Stack void empty void push char a void push char a void pop char top interface Counter void reset void inc void dec int size interface Lock void lock void unlock The code below provides base implementations of the individual features The notation feature SF de nes a new feature named SF which implements stacks Similar to class names in Java SF is used as a new constructor Using the other two feature implementations CF and LF new LF CF SF creates an object with all three features For interaction handling it is important that features are composed in a particular order e g the above rst adds CF to SF and then adds LF feature SF implements Stack String s new String void empty s Use Java Strings void push char a s String valueOf a concat s void pop s s substring char top return s charAt void push char a this push a this push a feature CF implements Counter int i void reset i void inc i i void dec i i int size return i feature LF implements Lock boolean l true void lock l false void unlock l true boolean is unlocked return l In addition to the base implementations we need to provide lifters which replace method overwriting in subclasses Such lifters are separate entities and always handle two features at a time In the following code features via interfaces are lifted over concrete feature implementations For instance the code below feature CF lifts Stack adapts the functions of Stack to the context of CF i e the counter has to be updated accordingly When composing features this lifter is used if CF is added to an object type with a feature with interface Stack and not just directly to a stack implementation This is important for exible composition as shown below feature CF lifts Stack void empty this reset super empty void push char a this inc super push a void pop this dec super pop feature LF lifts Stack void empty if this is unlocked super empty void push char a if this is unlocked super push a void pop if this is unlocked super pop feature LF lifts Counter void reset if this is unlocked super reset void inc if this is unlocked super inc void dec if this is unlocked super dec Methods which are una ected by interactions are not explicitly lifted e g top and size Note that the lifting to the lock feature is schematic Hence it is tempting to allow default lifters as discussed in Section The modular speci cation of the three features separated from their inter actions allows the following object compositions Stack with counter Stack with lock Stack with counter and lock Counter with lock For all these combinations the three lifters shown above adapt the features to the combinations The resulting objects behave as desired In addition we can of course use each feature individually even lock With the remaining two features bound and undo shown later many more combinations are possible in the same way The composition of lifters and features is shown in Figure for an example with three features To compose stack counter and lock we rst add the counter Environment Stack: Lock: lock, unlock empty, push, pop Counter: size, inc, dec Fig Composing features rounded boxes by lifters boxes with arrows to the stack and lift the stack to the counter Then the lock feature is added and the inner two are lifted to lock Hence the methods of the stack are adapted again using the lifter from stack to lock The composed object provides the functionality of all selected features to the outside but for composition we need an additional ordering In particular the outermost feature is not lifted similar to the lowest class in a class hierarchy whose functions are not overwritten Although inheritance can be used for such feature combinations all needed combinations including feature interactions have to be assembled manually In contrast we can re use features by simply selecting the desired ones when creating an object In the above example each feature can be run independently In other ex amples it is often needed to write a feature assuming that some other feature is available For this a feature declaration may require other features e g in the following example feature DisplayAdapter assumes AsciiPrintable void show window Consequently an implementation may use the operations provided by the feature AsciiPrintable in order to produce output on a window system In general the base functionality of a new feature can rely on the functionality of the required ones This idea of assuming other features is a further di erence to usual abstract subclass concepts Note that the extended object can obviously have more than just the required features Translation to Java To provide a precise de nition of our Java extension we show two translations into Java The rst translation uses inheritance while the second uses aggrega tion with delegation Hence this also serves to compare the feature model with both of these approaches and will highlight two cases where both di er We assume the following abstract program with Ii feature interfaces Ii tki methods declared for interface Ii Fi corresponding features Fi vardecls declaration of instance variables Fi fki code for methods Ii tki Fi j lifter for Fj to Ii Fi j fkj code for lifting Ij tkj interface I f I t method declarations I tk g interface Im f Im t Im tkm g feature F implements I assumes I l I ln f F vardecls variable declarations I t F f method implementations I tk F fk g lifters feature Fi lifts Ij f Ij t Fi j f function redefinitions Ij tkj Fi j fkj g For this schematic program concrete object creations can be translated into Java in two ways re ecting two object oriented programming techniques aggregation and inheritance For both translations the feature interfaces are preserved while the feature code is merged into concrete classes as shown below For sake of presentation the translation is simpli ed in order to make the obtained code as explicit as possible Therefore we assume the following The names of instance variables as well as method names are distinct for all features Assume that method calls to this are explicit i e always this fct instead of fct Variable declarations have no initializations Translation via Inheritance For this translation we create a concrete set of classes one extending the other for each used feature combination F F F Fn First a new class F F F is introduced which extends F F followed by a class F The class F F F adds the functionality for interface I and lifters for all others Formally an object creation new F F Fn translates to new F F Fn Furthermore we need the following Java classes for i n class Fi Fi Fn extends Fi Fn implements Ii In f Feature i implementation Fi vardecls variable declarations Ii t Fi f function implementations Ii tki Fi fki Lift Feature i to i Ii t Fi i f function redefinitions Ii tki Fi i fki Lift Feature n to i In t Fi n f function redefinitions In tkn Fi n fkn g Observe that n i lifters are needed which may call methods of the super class The translation assumes that the features required for Fi via assumes are present in the extended class Otherwise undeclared identi es occur in the translated code which would only be allowed in a dynamically typed language This assumption is not needed for aggregation which accounts for a small dif ference between the two translations Another di erence will be examined in the following section on parameterized features For instance our three features from the introduction translate into the fol lowing class hierarchy if an object of type LF CF SF is used class SF implements Stack String s new String void empty s void push char a s String valueOf a concat s void pop s s substring char top return s charAt void push char a this push a this push a class CF on SF extends SF implements Counter Stack int i void reset i void inc i i void dec i i lift SF to CF void empty this reset super empty void push char a this inc super push a void pop this dec super pop class LF on CF on SF extends CF on SF implements Lock Counter Stack boolean l true void lock l false void unlock l true boolean is unlocked return l lift CF to LF void reset if this is unlocked super reset void inc if this is unlocked super inc void dec if this is unlocked super dec lift SF to LF void empty if this is unlocked super empty void push char a if this is unlocked super push a void pop if this is unlocked super pop In this example the above code provides for most sensible combinations except for stack with lock only or counter with lock In general this translation intro duces intermediate classes which may be reused for other feature combinations Translation via Aggregation Aggregation is a common technique for composing objects from di erent classes to a larger object It is used in some object based systems as a replacement for inheritance This translation requires a set of base implementations and one new class for each feature combination The idea of the translation is to create a class where for each selected feature one instance variable of this type is used to delegate the services similar to We have to be careful with delegation and calls to this which should not be sent to the local object Hence we have to supply the delegate object with the right pointer to the enclosing object which replaces this For this purpose we create a base class for each feature implementation with an extra variable which will point to the composed object This construction enables us to check the assumes clauses globally i e wrt the newly created set of features With the inheritance translation we had to check these assumptions for each newly added class wrt its superclass Unlike the rst translation we need a few further technical assumptions For all lifters all methods are lifted explicitly e g int size return super size is assumed to be present Furthermore we need to assume that instance variables which are used in lifters are declared public Also the name self may not be used The main task of this translation is to compose the lifters i e all lifters for one method have to be merged at once here This can lead to more dense code as all needed lifters are composed in one class contrary to the inheritance translation An object creation new F F Fn translates to new F F Fn For this we rst need the following base classes for each feature implementa tion Fi i n For the type of self in the code below we use the class F F Fn If no assumes statements are used then just Ii is su cient and the class can be reused for other object creations Alternatively one can intro duce an intermediate class with just the needed interfaces Ii I i I li i class Fi implements Ii f F F Fn self reference for delegation Fi F F Fn s f self s g constructor for this class Fi vardecls Ii t F f function implementations Ii tki F fki g Note that public declarations are omitted throughout this presentation For delegation to work in the above we need to apply a substitution which renames this to self this self With the above base implementations we construct the class F F Fn via aggregation class F F Fn implements I I In f F b new F this delegate objects Fn bn new Fn this now need to nest lifters I t F f lift feature to I tk F fk I t F f lift feature to I tk F fk In t n n n n n nF n f lift feature n to In tkn n n n n n nF n fkn g For simplicity we only indicate the applications of nested lifters via unfolding operators i where i j unfolds the lifter from j to i sketched as i j super f Fi j f super fki Fi j fkj and also passes the actual parameters Unlike in the examples below unfolding is in general more involved for functions as we cannot have local blocks with return statements Hence we also assume for simplicity that methods return void Furthermore we have to delegate calls to super to the delegate objects For this purpose i shall rename the instance variables and method calls of methods in Ii to super correctly to the corresponding bi For instance super pop is translated to sf pop where sf is the name of the instance variable in the following example We show the translation for the combination of the three introductory features First new base classes are introduced with su x ag This is no restriction as in Java objects of primitive type can be wrapped into an object in order to be passed as variable parameters class SF ag implements Stack Stack self String s new String SF ag Stack s self s void empty s void push char a s String valueOf a concat s self replaces this for proper delegation void push char a self push a self push a void pop s s substring char top return s charAt class CF ag implements Counter Counter self CF ag Counter s self s int i void reset i void inc i i void dec i i int size return i class LF ag implements Lock Lock self LF ag Lock s self s boolean l true void lock l false void unlock l true boolean is unlocked return l A class for a composed object is shown below class LF CF SF implements Lock Counter Stack delegate objects SF ag sf new SF ag this CF ag cf new CF ag this LF ag lf new LF ag this delegate to lock void lock lf lock void unlock lf unlock boolean is unlocked return lf is unlocked delegate to lock void reset if this is unlocked cf reset void inc if this is unlocked cf inc void dec if this is unlocked cf dec int size return cf size delegate to stack void empty if this is unlocked this reset sf empty void push char a if this is unlocked this inc sf push a void push char a sf push a void pop if this is unlocked this dec sf pop char top return sf top Compared to the rst translation we need fewer classes here as the base classes can be reused On the other hand aggregation introduces another level of indi rection which may a ect e ciency Parametric Features In order to write reusable code it is often desirable to parameterize a class by a type In this section we introduce parametric features which are very similar to parametric classes Due to the exible composition concepts for features we also need expressive type concepts for composition For Java parametric classes have just recently been proposed and implemented in the language Pizza which will be the target language for our translations Apart from other nice extensions which are also used in some examples here Pizza introduces a rather powerful extension for type safe parameterization The notation for type pa rameters is similar to C templates A typical example is a stack feature parameterized by a type A as follows interface Stack A void empty void push A a void push A a void pop A top feature SF A implements Stack A List A s List Nil Use Pizza s List data type void empty s List Nil void push A a s List Cons a s void push A a this push a this push a void pop s s tail A top return s head Stacks over type char with a counter are then created via new CF SF char Note that it is sometimes useful to make assumptions on the parameter for providing operations e g interface Matrix A implements Number void multiply matrix Such an assumption is di erent from assumptions via assumes as it refers to a parameter and not to the inner feature combination The di erence is that this kind of parameterization is not subject to liftings For translating parameterization into Java we refer to We here only aim at translating into Pizza As we mostly use basic concepts it is not necessary to go into the details of the Pizza type system Type Dependencies For parameterized features new and interesting speci cation problems occur when combining features Not only can features depend on each other but the parameter types can also depend on each other This gets even more complicated if more than two features are involved as shown below For instance we may want to combine Stack A with a feature which only allows elements within a certain range Its implementation maintains two variables of type A used for ltering This feature Bound is parameterized by a numeric type interface Bound A boolean check bounds A el feature BF A implements Number implements Bound A A min max BF A mi A ma min mi max ma boolean check bounds A el Clearly we can only combine the two features when both are supplied with the same type This can be expressed by liftings feature BF A lifts Stack A Another example for such a dependency will be shown in Section Note that in feature implementations assumes conditions can also express type dependencies in the same way Multi Feature Interactions and Type Interactions In the following we discuss multi feature interactions and type interactions using the undo example This will lead to a new aspect of lifting features i e that lifting may change the type parameter The implementation of the undo feature is simple save the local state of the object each time a function of the other features is applied e g push pop Undo depends essentially on all inner features since it has to know the internal state of the composed object As we work in a typed environment the type of the state to be saved has to be known This multi feature interaction is solved by an extra feature called Store which allows to read and write the local state of a composed object The motivation for store is similar to the Memento pattern in We introduce the following interface for Store interface Store A void put s A a A get s Note that the parameter type depends on the types of all instance variables of the used features Consider for instance adding this feature to a stack with counter Then for both features the local variables have to be accessed With the Store feature we reduce the multi feature interaction to a type interaction problem This means that the parameter type of a feature has to change when a feature is lifted The following solution makes these type depen dencies explicit We use the Pizza class Pair A B providing for polymorphic pairs for type composition In the following lifter we state that the inner fea ture combination supports feature Store A for some type A For this we need a new syntactic construct namely assumes inner As feature stack ST adds an instance variable of type List B we can support the store feature with parameter Pair List B A feature ST B lifts Store Pair List B A assumes inner Store A Pair List B A get s return Pair Pair s local state super get s inner state void get s Pair List B A s The assumes inner however has some constraints The lifted feature may not have instance variables or calls to self where the changed type parameter type is used This can be allowed if the type change is a specialization which this is not the case in this example This inner condition is implicit in other lifters and is only needed if the type parameters change The lifting feature F lifts F A can be seen as an abbreviation for feature F lifts F A assumes inner F A We show below how this change of parameters a ects the two translations schemes of Section Continuing with the example we express that the counter CF adds an integer and LF a boolean variable with the following lifters feature CF lifts Store Pair A int assumes inner Store A feature LF lifts Store Pair A Boolean assumes inner Store A With the above lifters we can assure that the store feature works correctly and with the correct type for any feature combination All we need to add is a base implementation for store As the base implementation cannot store any thing useful we introduce a Pizza type class Void which has just one element void el class Void case void el feature ST implements Store Void base implementation void put s Void a Void get s return Void void el With the store feature we can now write the generic undo feature which can be plugged into any other feature combination It is important that the store feature xes the type of the state of the composed object The undo feature can then have an instance variable of this type Recall that this is not possible for store as the type parameter of store changes under liftings The undo feature consists of two parts storing the state before every change and retrieving it upon an undo call The latter is the core functionality of undo whereas the former will be xed for each function with a ects the state via liftings First consider the undo feature and its implementation which uses a variable backup to store the old state Since there may not be an old state we use the algebraic Pizza type Option A which contains the elements None or Some a for all elements a of type A interface Undo A void undo class Option A case None case Some A value feature UF A implements Undo A assumes Store A Option A backup None void undo switch Option backup case Some A a put s a An alternative version of undo may store several or all old states Due to our exible setup we can just exchange such variations For each of the other features we have to lift all functions which update the internal state As for lock this lifting is canonical e g for push void push A a backup Option Some get s super push a Note that there is an interesting interaction between lock and undo shall undo reverse the locking or shall lock disable undo as well We chose the latter for simplicity and hence add lock after undo Lifting undo to lock is canonical and not shown here As an example we can create an integer stack with undo and lock as follows new LF UF Pair int Void SF int ST Translation into Pizza We show in the following how to translate the above extensions into Pizza This will reveal another di erence between aggregation and inheritance for inheri tance we cannot cope with the change of parameters Otherwise the translation to Pizza is quite simple For aggregation additional inner statements just translate into types of the instance variables of class generated for a combination This is shown in the following code for a class generated for a composed object with both stack and store features We rst introduce a class SF ag A for parametric stacks As we do not allow calls to self for features whose type parameter changes during lifting we do not use the usual delegation mechanism in the above class Hence we use just ST The class SF ST A exports the interface Store Pair List A Void but uses a delegate object with interface Store Void class SF ag A implements Stack A Stack A self SF ag Stack A s self s List A s List Nil void empty class SF ST A implements Stack A Store Pair List A Void SF ag A sf new SF ag this Store Void st new ST Pair List A Void get s return Pair Pair sf s st get s A further detail to observe is that all type variables have to be considered for the translation This means that for the new class introduced all type vari ables which appear as parameters in the desired set of features have to appear as parameters For instance for the combination F A G B we need a class F G A B For inheritance an inner statement is an assumption on the extended class If the parameter changes this amounts to specialization for parameterized classes which is problematic in typed imperative languages as discussed in In Pizza the problem in this example is that subtyping does extend through constructors such as List For instance we cannot translate the above feature combination to the following illegal code illegal Type conflict class ST SF B A extends ST A implements Stack B Store Pair List B A Pair List B A get s Pair Pair s local state super get s inner state If the parameters do not change the translation is straightforward Examples In the following we sketch a few more typical applications for feature based pro gramming Some examples are freely taken from standard literature on design patterns We argue that for many of these typical programming schemata feature based implementations provide high exibility and the desired reusabil ity This is particularly important if several features or design patterns are com bined Adding a Cache Consider implementing some functional entity e g sets where caching of the results of operations is a viable option In the lines of this can be viewed as a Proxy pattern Clearly a cache is an independent feature and there exist many variations of caching For instance considering the data structures used and the replacement strategy And it furthermore may depend on appropriate hash functions which could also be provided via features When writing a reusable set of caching modules the various cache implemen tations just implement the data structures and the access functions Interaction resolution in turn modi es the access operations for the object to be cached and determines the type dependencies Consider writing this with classical object oriented languages for each needed combination of a cached object a cache and a hashing function a new sub class has to be implemented A sketch of such an example is shown below It shows how to add a cache to the parametric features Set A and Dictionary A B The feature implemen tation CacheI A B whose interface Cache is not shown here caches mappings from A to B interface Set A void put A a boolean contains A a interface Dictionary A B Option B get A key void put A key B value feature CacheI A B implements Cache A B void put s A a B b boolean find s A a B get s feature CacheI A B lifts Dictionary A B adapt access functions to cache Option B get A key if find key return Option Some get s else return super get second parameter is just boolean here feature CacheI A boolean lifts Set A Note that the lifters express the type dependencies For instance the set is viewed as a mapping from A to boolean Adaptor Patterns The adaptor design pattern glues two incompatible modules together This design ts nicely in our setting as adaptors should be reusable Typically there is some core adaption functionality e g some data conversion which we model as a feature When adding this to another feature we can just lift the incompatible functions with help of the core functionality An example is converting big endian encoding of data to little endian For instance if we output data on a low level interface which needs big endian...
[...]