Filetype PDF | Posted on 01 Feb 2023 | 2 years ago
Authentication
digital resources
156x 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.
