152x Filetype PDF File size 0.59 MB Source: www.inf.ovgu.de
Design Patterns Revisited Martin Kuhlemann School of Computer Science, University of Magdeburg, Germany kuhlemann@iti.cs.uni-magdeburg.de Abstract Label includes <> _b:ButtonInterface ButtonInterface Design patterns are general solutions for recurring problems and setText() click() used to develop flexible, reusable and modular software with getText() Object-Oriented Programming (OOP). Prior studies have shown a lack of modularity in object-oriented design patterns. Aspect- FramedLabel Button OrientedProgramming(AOP)aimsatimprovingflexibility,reusabil- getText() click() ity, and modularity in object-oriented designs. In a case study Han- nemann and Kiczales have argued that AOP improves the imple- Figure 1. UMLnotation of OOP classes and interfaces. mentation of GoF design patterns. Feature-Oriented Programming (FOP) is a new programming technique that also aims to improve 2. Background the modularity in object-oriented designs. In this paper we com- pare OOP, AOP, and FOP in a quantiative case study of design 2.1 Object-Oriented Design Patterns pattern implementations. We evaluate the OOP, AOP, and FOP de- In OOP methods and variables are merged into classes. For com- sign pattern implementations with respect to modularity and show posingclassesOOPprovidesmechanismsofinheritanceandobject that FOP performs best compared to OOP and AOP. composition [28]. Variability of software is achieved through poly- morphismofclasses [7]. Object-oriented design patterns propose advantageous class ar- rangements for frequently recurring requirements [13]. The re- quirements are described by roles of interacting objects, e.g., if one kind of object has to observe changes of another object. If a class 1. Introduction should play a role in one of these design patterns it is assigned to Design patterns are accepted and well known approaches to imple- implement interfaces or to inherit classes specific to its role. ment variable and reusable software using Object-Oriented Pro- Figure 1 depicts the UML notion for OOP mechanisms [22]. gramming (OOP) [13]. Although widely accepted, design patterns The figure depicts the classes FramedLabel and Button, the ab- lack in separating software into modules and cause crosscutting stract class Label, and the interface ButtonInterface. The class concerns [15]. LabeldeclaresthemethodgetText,theclassButtondefinesthis Crosscutting concerns imply tangling, scattering and replication method. Equivalently, the method click is declared in the inter- of source code which results in complex software [16]. Classes face ButtonInterface and is defined in the class Button. Inher- that include code of a crosscutting concern are closely coupled to itance and interface implementations are denoted by arrows while this concern (tangling) and to the other classes that also implement inheritance implies solid arrows and interface implementations im- this crosscutting concern. To exchange the crosscutting concern ply dashed arrows. Associations between classes are denoted by the classes that include this concern have to be replicated. Thus, simple lines, e.g., the class Label includes one member of type software including crosscutting concerns is monolithic, hard to ButtonInterface. maintain and reuse and thus development effort increases. Cross- 2.2 Aspect-Oriented Programming cutting concerns are studied in ongoing research [4, 23, 27], and The purpose of AOP is to modularize crosscutting concerns into numerous approaches aim to tackle them on different levels of aspects [16]. software development, e.g., during requirement engineering and WenowexplaintheAOPmechanismsofAspectJ1,apopularAOP others [1, 25, 8, 20]. Recently, advanced programming techniques, language extension for Java, that are used in our case study [15]. e.g., Aspect-Oriented Programming (AOP) and Feature-Oriented Programming (FOP), gain momentum to overcome crosscutting Pointcut and Advice. The mechanism of AOP is the extension concerns [16, 24]. of code implementing events that occur at runtime (so-called join Several studies have shown the strengths of AOP and FOP [15, 14, points) [18]. The static representation of a runtime event in the 2]. These studies concentrated on single techniques or compared source code is called join point shadow. Join point shadows are AOPandFOPqualitatively. for example method calls, constructor calls, or member access. A In this paper we compare OOP, AOP, and FOP in a quantitative pointcut defines a set of join points to be extended. The extension case study using the Gang-of-Four (GoF) design patterns [13]. We to be invoked at the join points is called advice. did so to achieve a broader perspective of problems that occur fre- Anexampleforpointcut and advice (PCA) is given in Figure 2. quently in software development. We show that FOP outperforms TheaspectMyAspect(Lines12–26)extendstheclassesLabeland OOPandAOPwithrespect to modularity but also includes draw- Button. The pointcut LabelChangeCall (Line 13) refers to all backs. 1http://www.eclipse.org/aspectj/ 1 public class Label { < > < > 2 public void setText(){/∗ ... ∗/} ButtonInterface declare MyAspect 3 } parents Label.Name Button pc:LabelChangeCall before:LabelChangeCall() 4 public class Button { HashMap before:LabelChangeExec() 5 ButtonInterface _b; put() uses Label.PrintName() 6 public void click(){ get() getPrinter() 7 /∗ . . . ∗/ set() declare precedence 8 myLabel.setText("Button clicked") Figure 3. Graphical notation of an aspect. 9 /∗ . . . ∗/ 10 } 11 } the same singleton instance of the aspect. In this case the aspect is 12 public aspect MyAspect { instantiated once. 13 protected pointcut LabelChangeCall(): Parent Declaration. Aspects can make a class to implement an call (*´ ´Label.*(..)); interface. Furthermore, aspects can declare a class to inherit from 14 protected pointcut LabelChangeExec(): execution(*´´Label.*(..)); another class. 15 before():LabelChangeCall(){/*...*/} In Figure 2 (Line 24), the aspect MyAspect assigns the class 16 before():LabelChangeExec(){/*...*/} Buttontoimplementtheinterface ButtonInterface. 17 18 public String Label.Name; OtherAOP. ThecategoryOtherAOPincludescompilerwarnings 19 public void Label.printName(){/*...*/} 20 and errors and includes the declaration of advice precedence. 21 public HashMap printer; If a user defined constraint is violated by the classes, the aspect 22 public void getPrinter(){/*...*/} weaver can be instructed to invoke compiler warnings or compiler 23 errors. 24 declare parents:Button implements ButtonInterface; 25 declare precedence:PriorAspect,MyAspect; Precedence declarations define the ordering of advice if join point 26 } shadowsareadvised by more than one aspect, e.g., Fig. 2, Line 25, states that the advice of the aspect PriorAspect has to be applied Figure 2. Application of call and execution advice in AOP. before the advice of the aspect MyAspect is applied. We depict our extended UML notion for aspects in Figure 3. statements that invoke methods of the class Label (call pointcut), The shaded element depicts the aspect MyAspect of Figure 2 and e.g., call statements for the method setText. The corresponding includes the PCA, ITD, and AFM. Pointcuts are abbreviated using piece of advice (Line 15) is woven into the method click of the pc while advice is abbreviated by the type of advice (e.g., before class Button before (before advice) the call of the labels method advice). We depict subclass declarations assigned by an aspect by setTextis invoked (Line 8). Advice also can be applied after (af- associating the aspect to the inheritance relationship of the classes ter advice) or around (around advice) join points. (association declare parents, Fig. 3). The advice of the pointcut LabelChangeExec (Line 16) refers to 2.3 Feature-Oriented Programming the body of the method setText (execution advice), i.e., the ad- FOP aims at feature modularity in software product lines where vice is woven into the method setText of class Label (Line 2). features are increments in program functionality, e.g., feature trac- While pieces of call advice, e.g., advice assigned to the point- ing [24, 6]. Typically, features are not implemented through one cut LabelChangeCall, intercept the method caller, i.e., call ad- single class [26, 5] but through different collaborating classes and vice only augments specific join points that perform the method adding a feature subsequently means to introduce code, e.g., new setText, execution advice, e.g., advice assigned to the pointcut methods, into different existing classes [24, 26]. This code of dif- LabelChangeExec,intercepts the called object, i.e., execution ad- ferent classes associated to one feature is merged into one feature vice augments all join points performing the method setText. module.Inthefollowingselectingfeaturesofthesoftwareisequiv- Inter Type Declaration. Inter type declarations (ITD) are meth- alent to selecting feature modules. Assigning a feature to a config- ods or variables that are inserted into classes and interfaces by an uration causes the new feature module to superimpose (refine) the aspect and thus become members of these classes and interfaces old feature modules [6], i.e., methods and classes are added or get respectively. Contrary to Java conventions, AspectJ allows to intro- refined. duce methods including a method body into interfaces [15]. WesystematizethemechanismsoftheAHEADToolSuite2,apop- In our example of Figure 2 the aspect MyAspect defines two ITD ular FOPlanguageextensionforJava,intothecategoriesofMixins, i.e., to insert the member variable Name (Line 18) and method Method Extensions, and Other FOP. Additionally, we describe the printName(Line19)into the class Label. OOP technique of Singleton classes as a category since we used Aspect Fields and Methods. Aspects can contain members simi- singleton classes to transform AFM into FOP. lar to members of an OOP class, i.e., aspects can contain methods, Method Extension. FOPallows to extend methods of classes by fields, or inner classes and interfaces. These aspect members can overriding. be invoked like methods of a class from inside the aspect, e.g., by An example is depicted in Figure 4. The feature module BASE advice, or from outside the aspect, i.e., from the classes (using the (Lines 1–4) includes a class Label that is superimposed by the aspect method aspectOf). The aspect MyAspect includes one as- refinement EXTENSION (Lines 5–12), i.e., the refinement EXTEN- pect field and one aspect method (Fig. 2, Lines 21–22). SION superimposes the method setText of the class Label. The If aspect fields and methods (AFM) are invoked through aspectOf method setText of the feature module EXTENSION extends the and no extra pointcut mechanisms are declared (e.g., percflow), then every reference to the aspect members of one aspect refers to 2http://www.cs.utexas.edu/users/schwartz/ATS.html 1 // feature module BASE FOP where each refinement is figured by one class of an OOP 2 public class Label { inheritance hierarchy. 3 public void setText(){/∗ ... ∗/} 4 } 3. GoalStatement 5 // feature module EXTENSION 3.1 WhatDoWeAdress? 6 refines class Label { AOPandFOPprovidebenefitscomparedtoOOPbuthavedifficul- 7 public void setText(){ ties and strengths [3]. In this paper we aim to compare OOP, AOP, 8 Super().setText(); and FOPimplementations with respect to modularity. 9 } 10 public String Name; 3.2 Experimentation Methodology 11 public void printName(){/∗ ... ∗/} 12 } 3.2.1 Criteria Figure 4. Refinement of a method by a FOP refinement. Wecomparethedesignpatternimplementationswithrespecttothe properties of modularity, i.e., cohesion and variability, and thus we follow existing studies of OOP and AOP [15, 14]. We define these properties as follows: Base Label includes Button Cohesion. An aggregate definition, e.g., a package, of different setText() click() programchanges,e.g.,theintroductionofdifferentclassesormeth- Label name ods into the software, can be referred to by a name and is there- Extension Name: String String fore cohesive [17]. The named module, e.g., a package, can be ex- setText() changed and reused and thus development effort decreases. printName() Cohesive modules rarely reference to other modules and are thus Figure 5. Refinements and classes in FOP. loosely coupled to other modules. Ourdefinition of cohesion is similar to the definition of Locality of Hannemannetal.andCohesionofGarciaetal. [15, 14]. setText method of the feature module BASE by invoking this su- Variability. If features of a modularized software shall be able to perimposed method using Super (Line 8) and defining additional change flexibly, the modules of the software have to be composed statements. in many different ways. Modules that are loosely coupled are pre- Mixins. Feature modulesincludemixinclasses,thatsuperimpose required [17]. Consequently, modules can be exchanged easily. andrefineotherclasses. Mixins are members of mixin classes, e.g., Tangling of code of different concerns of the software causes close methodsandmembervariables,thatareintroducedintoanexisting couplingofmodulesresultingininvariant,complexandmonolithic class and extend the set of members of this refined class. software [16]. In Figure 4 the new method printName and the new member Name Our definition of variability corresponds to the criteria Compo- is introduced by the feature module EXTENSION, i.e., by the mixin sition Transperency of Hannemann et al. [15] class Label (Lines 10–11). In addition, Hannemann et al. used the criteria Reusability and We define that a subtype declaration of a mixin class is a mixin (Un)pluggability to evaluate the aspect-oriented design pattern im- too since this property is added to a class. Thus, mixin classes can plementations [15]. We do not use these criteria because we argue introduce additional base classes for a refined class. themtobeimprecise and not significant. Singleton. Asingleton class is an idiom to limit the number of 3.2.2 Schedule of Comparison instances of a class. The singleton class is usually instantiated once and all subsequent requests to this class are forwarded to this Weadopt the methodology of Hannemann et al. and Garcia et al. unique instance [13]. to evaluate programming paradigms [15, 14]. Both studies com- Other FOP. This category include idioms of the arrangement of pared OOP and AOP on the base of a case study of design pattern classes, the ordering of feature modules and the qualification of implementations. To analyze many diverse applications we reim- membervariables. plemented the 23 GoF design patterns in FOP and adopt the OOP All classes, that are not nested in other classes are encapsulated in and AOP implementations. For different design patterns we im- feature modules.Theorderingoffeaturemodulesdefinestheorder- plemented alternative FOP implementations (up to 7 per design ing of extensions for one single method. Class members qualified pattern) resulting in 50 different FOP implementations. For com- as limited visible, e.g., qualified as protected, cannot be accessed parison we choose the implementation that is close to the AOP from classes others than the class itself and its subclasses. counterpart. Figure 5 depicts our graphical notion of FOP mechanisms that We compare the different implementations of the design pat- are used in Figure 4. The feature modules BASE and EXTENSION terns by repeating the following schedule: are shaded and encapsulate the classes Label and Button and a 1. We review the aim of the pattern. mixinclassrefiningtheclassLabel.(TheStringclassoftheJava- 2. We give an explanation of the OOP, AOP, and FOP implemen- API is not implemented inside the layer but is depicted to depict tations each followed by a discussion of the specific pros and special properties of the Label class.) cons. Werefer to classes and mixin classes inside feature modules by 3. We compare the OOP, AOP, and FOP implementations based ([X.]*)Y, where Y is a (nested) feature module and Y is the single onthe criteria given in Section 3.2.1. mixin class. We used mixin layers to implement the GoF design patterns 4. We give a short summary of specific difficulties and strengths in FOP [26]. Mixin layers is one implementation technique for of the OOP, AOP, and FOP implementations that were captured 1 public interface ComponentFactory { < > 2 public JLabel createLabel(); ComponentFactory 3 ... createLable() 4 } createButton() getName() Figure6. TypelimitationthroughmethoddeclarationsintheOOP RegularFactory FramedFactory Abstract Factory implementation. createLable() createLable() createButton() createButton() during the evaluation but are not relevant for the analyzed crite- getName() getName() ria. Figure 7. Abstract Factory through OOP. As a summary we give a table that aggregates and balace the results of the evaluation. A ”+” depicts that the technique performs well with respect to the criterium while ”-” depicts the lack of < > the technique regarding that criterium compared to the other tech- ComponentFactoryImplementation ComponentFactory.createLable() niques. ”0” depicts the neutral evaluation regarding the criterium ComponentFactory.createButton() and compared to the other techniques. < > ComponentFactory createLable() 4. CaseStudy createButton() InthissectionweevaluatethedesignpatternsimplementedinOOP, getName() AOP,andFOPindetail. RegularFactory FramedFactory Hannemann et al. use Java3 to implement design patterns in createLable() OOP and use AspectJ to implement the aspect-oriented counter- createButton() parts. We use the AHEADToolSuiteforimplementingthepatterns getName() getName() in FOP. Figure 8. Abstract Factory through AOP. 4.1 TheAbstractFactoryDesignPattern 4.1.1 Intention factory. Consequently, all GUI elements that should be created Provide an interface for creating families of related or de- by the factory have to be of the type that is referred to by the pendentobjectswithoutspecifyingtheirconcreteclasses[13]. factory class for the according kind of GUI elements, e.g., the 4.1.2 Implementation method createLabelofthefactory ComponentFactory lim- its the type of possibly created label objects to be subtype of OOP solution. Hannemann et al. applied the pattern to create the class JLabel (Fig. 6, Line 2). different kinds of one graphical user interface (GUI) [15]. Different factories may create the same GUI element classes Each factory class creates GUI elements of different kinds, and thus introducing code replication. e.g., buttons or labels, and of different properties for each kind If the implementationofthemethodscreateLabelorcreate- of GUI element, e.g., one factory object creates framed or regu- Button should vary for all factory classes in the same way ei- lar elements of different kind (e.g., Button). All GUI elements ther all classes or the common superclass has to change. This (e.g., of type Button or Label), that are created by one factory introduces code replication if both variants of the implementa- class (e.g., FramedFactory or RegularFactory), have compat- tion should be available. ible properties, e.g., all elements are framed or all elements are regular. The properties of GUI elements created by different fac- AOPsolution. In the AOP implementation the factory class can tories differ and may be incompatible. Each GUI is created using create GUI elements, e.g., of type Button, differently without con- onefactoryandthusallelementsofoneGUIhavecompatibleprop- ditional statements or subclasses of the factory class. The meth- erties, the elements of different GUI may have different properties ods that create the GUI elements are detached into the aspect because they were created by different factories. Hence, the choice ComponentFactoryImplementation(Fig.8)andareintroduced of the factory class implies the properties of the graphical elements ondemand. that are created. Different factory classes, i.e., FramedFactory and RegularFactory, can be exchanged with respect to the common Advantages The advantages of the OOP implementation hold for interface ComponentFactory. If a referenced FramedFactory the AOP implementation. The interface ComponentFactory object is replaced by a RegularFactory object the GUI elements can be extended by methods without code replication of the created subsequently are framed instead of regular and vice versa class or its subclasses. Thus, variant implementations of the without affecting a client that creates GUI. methods createLabel or createButton can be varied for Advantages Exchanging factory objects of different type (e.g., all classes, e.g., FramedFactory, homogenously without in- RegularFactory and FramedFactory) does not affect the troducing code replication. client that refers to the interface ComponentFactory. A com- Disadvantages The AOP implementation does not work with- patible configuration of properties for different GUI elements out the aspect ComponentFactoryImpl because the methods to be built, e.g., whether all should be framed, is encapsulated createLabelandcreateButtonaredeclaredintheinterface inside one graphical factory (e.g., FramedFactory). ComponentFactory but never implemented by its subclasses. Disadvantages The factory classes determine the type for each This arises the cognitive distance. kind of GUI element, e.g., a button, that can be created by the Thevariablecompositionofthefactoryclassmayhampercom- patibility of GUI elements applied to that factory class. 3http://java.sun.com/
no reviews yet
Please Login to review.