Information and Software Technology 160 (2023) 107222

Contents lists available at ScienceDirect

Information and Software Technology

journal homepage: www.elsevier.com/locate/infsof

A mapping study of language features improving object-oriented design

patterns
William Flageol a ,∗, Éloi Menaud b , Yann-Gaël Guéhéneuc a , Mourad Badri c , Stefan Monnier d
a Concordia University, 1455 boulevard de Maisonneuve Ouest, Montreal, Québec, Canada, H3G 1M8
b IMT Atlantique, 4 Rue Alfred Kastler, Nantes, 44300, France
c
Université du Québec à Trois-Rivières, 3351 boulevard des Forges, Trois-Rivières, Québec, Canada, G8Z 4M3
d
Université de Montréal, C.P. 6128 Centre-Ville, Montréal, Québec, Canada, H3C 3J7

ARTICLE INFO ABSTRACT

Dataset link: https://www.ptidej.net/download Context: Object-Oriented Programming design patterns are well-known in the industry and taught in universi-
s/replications/ist22/ ties as part of software engineering curricula. Many primary studies exist on the impact of design patterns on
software, in addition to secondary studies summarizing these publications. Some primary studies have proposed
Keywords:
Systematic mapping study
new language features and used them to re-implement design patterns as a way to show improvements. While
Design patterns secondary studies exist, they mainly focus on measuring the impact of design patterns on software.
Object-oriented programming Objectives: We performed a systematic mapping study to catalogue language features in the literature claiming
Language features to improve object-oriented design patterns implementations, as well as how primary studies measure these
Software measures improvements.
Programming paradigms Methods: We performed a search in three databases, yielding a total of 874 papers, from which we obtained
34 relevant papers. We extracted and studied data about the language features claiming to improve design
patterns implementations, the most often cited design patterns, the measures used to assess the improvements,
and the case studies and experiments with which these improvements were studied.
Results: Using the results, we catalogue 18 language features claimed in the literature to improve design
patterns and categorize them into paradigms. We find that some design patterns are more prevalent than
others, such as Observer and Visitor. Measures related to code size, code scattering and understandability are
preferred. Case studies are done in-vitro, and experiments are rare.
Conclusion: This catalogue is useful to identify trends and create a road map for research on language features
to improve object-oriented design patterns. Considering the prevalence of design patterns, improving their
implementation and adding language features to better solve their underlying concerns is an efficient way
to improve object-oriented programming. We intend in the future to use this as a basis to research specific
language features that may help in improving object-oriented programming.

1. Introduction practices are catalogued as design patterns. A design pattern is a generic

way to solve a recurring problem in software programming. Design
Object-Oriented Programming (OOP) is the de-facto general pro- patterns are distilled from coding experience from professionals and
gramming paradigm. In many universities, software engineering is recurring structures in real-world software [1].
taught almost exclusively using OOP concepts. Arguably the most popular design patterns relate to OOP and come
Much of the concepts of OOP are inherited from languages from from the 1994 book by Gamma et al. [1] and describe 23 design
the 60s and 70s, such as Simula and Smalltalk. There have been patterns implemented in real-world software in C++ (with some other
many popular object-oriented languages, such as Java, C# and Python,
examples in Smalltalk). We refer to these 23 design patterns as the Gang
and languages that adopted object-oriented concepts, such as C++,
of Four (GoF) patterns and the implementation examples in the book
Common Lisp, and JavaScript. Some of the concepts are present in some
as the classical implementations of design patterns.
form or another in most modern languages.
The GoF patterns and other such OOP design patterns help solving
Object-Oriented Programming matured over the last few decades
and is at a stage where it has well-defined practices. Some of these problems that would otherwise prove difficult in OOP programming

∗ Corresponding author.
E-mail address: [email protected] (W. Flageol).

https://doi.org/10.1016/j.infsof.2023.107222
Received 9 January 2023; Received in revised form 6 March 2023; Accepted 31 March 2023
Available online 13 April 2023
0950-5849/© 2023 Elsevier B.V. All rights reserved.
W. Flageol et al. Information and Software Technology 160 (2023) 107222

languages. They are also solutions to problems within the paradigm 2. Background
itself: problems that cannot be solved simply using OOP concepts,
such as creating callbacks on particular events (Observer pattern) or We illustrate how a design pattern can be improved by specific lan-
encapsulating code inside data (Command pattern). guage features using the Factory Method design pattern, as discussed in
Design patterns are presented as ‘‘templates’’ that can be adapted to the GoF book [1]. Fig. 1 shows the first example of an implementation
specific problems for which using ‘‘naive’’ OOP solutions would not be of Factory Method in the book. We present this example because of how
optimal. However, they can introduce new problems, such as raising
directly the Factory Method design pattern maps to object instantiation
complexity, requiring that programmers be familiar with these design
language features. The example was designed with the C++ language
patterns to get the most out of their advantages. Overuse of design
in mind, but would be applicable to most other modern OOP languages,
patterns, as well as ‘‘over-engineering’’ [2], should be avoided.
such as C# and Java.
One secondary study by Zhang and Budgen [3] considered empirical
The goal of this pattern is to decouple an application from con-
studies on the effects of applying design patterns in software design.
They showed that there was a lack of empirical studies on most design crete implementations of abstract classes or interfaces. To achieve
patterns and that empirically founded advantages and disadvantages this goal, we must encapsulate object instantiation. Factory Method
are difficult to find in the literature. It also discussed design patterns suggests creating an abstraction of this creation process and using
implementations sometimes being harmful to program understanding, this abstraction throughout the software instead of the normal object
while they do help with maintenance and evolution. creation feature of the language (e.g., the new keyword). In Fig. 1,
Primary studies tried to find other object-oriented patterns for the class Application represents the abstraction of the creation
situations not covered by the initial 23 design patterns. Others tried process of documents. If we wanted the application to instantiate
to use object-oriented approaches to improve the implementations of documents of type MyDocument, we would use an application of type
existing patterns [4]. Yet others tried to leverage language features MyApplication.
from other programming paradigms to improve specific measures of This pattern encapsulates the normal object instantiation mecha-
design patterns [5–9]. Yet, there has not been much focus on the rela- nism provided by the language. The solution of the design pattern is
tionship between programming language features and design patterns to encapsulate this mechanism because the instantiation mechanism
implementations. in C++ (and similar languages) does not allow for decoupling an
To gain a better understanding of this relationship between design abstraction from its concrete implementations (i.e., the new keyword
patterns implementations and language features, we propose to study only allows for the instantiation of concrete objects).
the literature on design pattern improvements. We specifically look for A variant to this solution is given a few pages later [1] with
language features which helps the implementation of design patterns Smalltalk. In Smalltalk, there is no keyword for object creation. Object
by simplifying them (we give an example of this in Section 2) or by
creation is accomplished using a method declared in the meta-class of
improving specific measures (e.g., coupling between objects, cohesion,
the class (also called new). Because classes are also objects in Smalltalk,
etc.).
it is possible to call this method on a variable, effectively the Factory
We perform a systematic mapping study to identify language fea-
Method pattern. Thus, the document example could be implemented
tures claimed to improve design patterns implementations. The goal is
in Smalltalk with a method in Application that returns the class
to identify which language features have been suggested to improve
OOP design patterns implementations, which design patterns imple- to use to create document objects. The MyApplication class could
mentations are being improved upon, which measures are used to implement this method as returning MyDocument, as such:
evaluate these improvements, and what empirical data was collected
to assess these improvements. "In class MyApplication"
We perform a search query in three databases (Ei Compendex, documentClass
Inspec, GEOBASE) using the Elsevier search engine Engineering Village. ^ MyDocument
Our initial query yields 874 papers, which we assess for quality and createDocument
use for snowballing, resulting in a total of 34 primary studies. We then ^ documentClass new
extract relevant data from these 34 studies and discuss and catalogue
our observations and their meaning. In this implementation, there is no need to supersede the normal
We catalogue 18 language features claimed in the primary studies object creation mechanism of the language. We instead use it normally
to improve design patterns implementations and categorize them into on the class returned by documentClass.1 By using Smalltalk’s meta-
paradigms. This catalogue is useful to identify trends and create a road
class and object instantiation language features, the pattern becomes
map for research on language features to improve object-oriented de-
part of the language and is more easily combined with other language
sign patterns. Considering the popularity of design patterns, improving
features.
their implementation and adding language features to better solve their
There are other examples in the GoF book [1] where design pat-
underlying concerns is an efficient way to improve Object-Oriented
Programming. We intend to use this in the future as a basis to research terns have implementations that are simpler in Smalltalk than C++.
specific language features that may help in improving Object-Oriented This discrepancy between implementations suggests that design pat-
Programming. terns implementations depend on what features are supported by the
The rest of this paper is organized as follows: in Section 2, we programming language.
further explain how design patterns can be improved by language In some languages, design patterns can even become obsolete and
features and give a running example. In Section 3, we present an disappear entirely when the concept is fully supported by the lan-
overview of other related secondary studies on the topic. In Section 4, guage [10].
we shortly present the concept of the systematic mapping study, we In this work, we are interested in cataloguing language features that
pose our research questions and present the methodology to perform impact the 23 GoF design patterns, and see what this impact is and how
our mapping study. In Section 5, we lay out the results related to our it was measured.
different research questions. In Section 6, we discuss these results and
their implications. In Section 7, we list notable or interesting findings
and our recommendations for future work. Section 8 lists threats to the 1
Using this, we could restructure the model in different ways. For example,
validity of this study. In Section 9, we conclude with the main findings we could remove the MyApplication class and replace it with a collection
of this paper and further possible research. holding the different concrete classes used to create objects for the application.

2
W. Flageol et al. Information and Software Technology 160 (2023) 107222

Our objective is to find language features in research done to

improve OOP design patterns. In particular, we want to survey the tech-
niques and tools developed to make these improvements, as well as the
measures used to assess them. We are also interested in understanding
the kind of experiments done to evaluate these tools and techniques.
We want to answer the following research questions:

1. RQ1: What language features have been suggested to improve

design patterns implementations?
2. RQ2: Which design patterns have the most associated language
features suggestions?
3. RQ3: What measures have been used to evaluate the impact of
these language features on design patterns implementations?
4. RQ4: What experiments have been done on these language
features?
Fig. 1. Implementation example of Factory Method [1].
To answer these questions, we perform a search to find and select
the papers that will be studied in this study. Then, we ensure that the
3. Related studies identified papers are related and offer answers to the research questions
by performing a quality assessment. Finally, we extract data from the
Multiple secondary studies exist about object-oriented design pat- papers and synthesize it to reach our goal.
terns. To reduce bias as much as possible, we perform the literature search
In 2012, Zhang et al. [3] published a systematic literature review in multiple databases and gather a large number of papers, which
about the effectiveness of software design patterns. They targeted we then systematically study. We also perform a snowballing step to
empirical studies made on the GoF design patterns. They concluded include all papers citing or cited by any paper which is not rejected
that there is a lack of empirical studies about design patterns and in the manual sorting, followed by other snowballing iterations on the
concrete advantages and disadvantages are difficult to find in the resulting set until reaching a fixed point.
literature. They also concluded that design patterns may not help with Consequently, we follow these nine steps (as shown in Fig. 2):
understandability, sometimes decreasing it dramatically.
1. Identify keywords for searching for papers.
In 2013, Ampatzoglou et al. [11] performed a mapping study on
2. Identify databases for searching for papers.
the impact of design patterns on software quality. They focused on the
3. Build a search query and execute it based on the keywords on
GoF design patterns and categorized research into different categories
each database.
(formalization, detection, and application). They found that research
4. Filter the results manually based on the abstract and keywords.
on the detection of design patterns and their impact was the most
5. Perform a forward and backward snowballing step where each
active. In another paper, the same authors proposed a catalogue [12]
paper’s references and papers that reference it are also consid-
of alternative designs for the GoF patterns. These alternative designs
ered (manually).
usually add new functionality to existing patterns, either to make them
6. Create a form for compiling the data provided by the papers.
more flexible [13] or to adapt them to specific situations [14].
7. Read and compile each paper, removing any paper that does not
In 2016, Mayvan et al. [15] published a state of the art on research
provide data for at least one of our research questions.
on design patterns with the goal of presenting an entry-level summary
8. Interpret the compiled data and answer the research questions.
to those who would seek to enter the research field. They perform a
systematic mapping study to identify popular research trends, such as
4.1. Keywords for the search query
commonly used keywords, most active researchers and venues, and the
distribution of publications by topics. They identify Pattern Develop-
Based on our goal, we identify keywords to find papers potentially
ment as the most popular topic, which groups the introduction of new
providing data to answer our research questions. These keywords do
patterns or pattern variants and categorization of design patterns by
not encompass all possible synonyms and are general. For example,
field (e.g., mobile applications, security, etc.).
we include ‘‘object-oriented programming’’ as a keyword, but do not
These studies, and the studies they review, focus mainly on evalu-
add ‘‘OOP’’, ‘‘object-oriented’’, or other synonyms. We add synonyms
ating the impact of design patterns on object-oriented software. Many in Step 4 when we build the database query. We are investigating
of them compare code that was developed without the usage of de- improvements in design patterns, thus we added some keywords related
sign patterns against code that was developed with. Others explore to weaknesses and anti-patterns. While these could be seen as unre-
alternative design patterns to respond to specific problems. Our study lated, there is no disadvantage in having a broader query and unrelated
catalogues language features used in the literature claiming to improve papers will be removed in later steps of the study.
object-oriented design patterns implementations, without modifying We identify the following keywords to use for building the search
their functionality, as well as how these improvements are measured query: object-oriented programming, design patterns, anti-patterns, weak-
and the empirical data available. ness, disadvantage, improvement, enhancement, refinement, better, expand.

4. Methodology 4.2. Databases for the search query

To reach our goal and answer our research questions, we perform To perform as large a search as possible, we use multiple online
a systematic mapping study following similar practices as introduced databases for scientific papers. These databases are part of an online
by Peterson et al. [16] in their systematic mapping studies guidelines tool called Engineering Village, hosted by Elsevier. They contain data
for software engineering and executed by Ampatzoglou et al. [11]. from a large number of scientific journal databases, such as ACM and
Our methodology also draws from general guidelines on systematic IEEE. Given the focus of this study on the GoF design patterns, we
literature reviews [17,18]. consider papers published between 1995 and 2022.

3
W. Flageol et al. Information and Software Technology 160 (2023) 107222

Fig. 2. Flowchart of the steps in our approach.

Table 1
Database query.
Query Comments
((oop OR object)
AND (design pattern OR design patterns Must be linked to design patterns
OR anti-pattern OR anti-patterns OR paradigm) Initially, we intended the scope to be broader, but this should not
impact the final results
AND (weakness* OR disadvantage* OR improve* OR enhance* OR refine* OR help Must be about improving or finding weaknesses
OR better OR expand*)
WN AB) These keywords are located in abstract text
NOT ((teach* OR learn* OR test* OR modeling OR automated OR automation OR These keywords are excluded to avoid papers about learning,
tool* OR mobile OR optimiz* OR simulation OR mining OR medical OR bio* OR automating, optimizing tools, or other non-related subjects
hardware OR hdl OR parallel* OR api OR find* OR sql) encountered during the first passes of the query.
WN KY) Excluded keywords must not appear in the keyword field.
NOT ((pattern recognition OR pattern identification OR pattern detection OR object Finally, a large list of expressions was excluded from the keywords
recognition OR object detection OR feature extraction OR computer vision OR because they tended to be attached to papers about concepts
pattern clustering OR learning (artificial intelligence) OR image segmentation OR unrelated to this research.
pattern classification OR data mining OR computer aided design OR formal
specification OR image classification OR user interfaces OR computer simulation OR
internet OR image processing OR codes (symbols) OR image enhancement OR
embedded systems OR image reconstruction OR cameras OR distributed computer
systems OR product design OR artificial intelligence OR iterative methods OR neural
nets OR neural networks OR object tracking OR genetic algorithms OR classification
(of information) OR learning systems OR mathematical models OR middleware OR
internet of things OR cloud computing OR decision making OR
electroencephalography OR virtual reality OR risk management OR health care OR
distributed object management OR query processing OR knowledge based systems)
WN KY)

4.3. Query building and execution Table 2

Query results by database.
Database Results
We are using only one search engine, thus only one query is needed. Compendex 316
All three of the databases are accessed from Elsevier Engineering Inspec 371
Geobase 13
Village Web site [19]. We restrict the scope of the query to the title, All databases 700
abstract, and keywords of the papers. We opt to use the more general After de-duplication 625
term ‘‘object’’ (and then filter manually) instead of the various ways of
writing ’’object-oriented programming’’ to avoid accidentally excluding
relevant studies that used a slightly different expression (e.g., object 4.4. Filtering
oriented software).
Through several iterations, we add a large number of keyword ex- We manually read the title and abstract of each of these studies and
clusions (‘‘NOT’’ keywords) to increase the relevance of the studies and determine whether the study has potential to provide data to answer
reduce the number of unrelated studies. We exclude these keywords one of our four research questions. We choose to be conservative in this
specifically from the ‘‘keywords’’ field in the database (meaning the step and include any study that could provide data for a research ques-
paper should be about these topics), and not from the abstract (e.g., we tion, even if remotely. Following quality assessment guidelines [16],
are not excluding a paper because ‘‘test’’ is found in its abstract). The inclusion criteria were applied to the titles and abstracts:
final query is shown in Table 1. This query yields 874 studies.
1. Study is in the field of software engineering.
The final query results are shown in Table 2. Removing duplicates 2. Study is related to the improvement of design patterns and must
is done via a script, as we found the Engineering Village search engine propose a language feature to do so. (Studies relating exclusively
functionality to remove duplicates was not accurate. After removing to measuring the impact of existing design patterns against
duplicates, we retain 625 studies for manual filtering. non-pattern code are not kept.)

4
W. Flageol et al. Information and Software Technology 160 (2023) 107222

3. Study was published between 1995 and 2022. Table 3

Publication venues.
Similarly, criteria were used to exclude papers: Publication venue [# Papers]
Conference on Pattern Languages of Programs (PLoP) [4 papers]
1. Study is not related to one or more specific design patterns. European Conference on Object-Oriented Programming (ECOOP) [2 papers]
2. Study is not peer-reviewed. Special Interest Group on Programming Languages (SIGPLAN) [2 papers]
3. Study is not written in English. Symposium on Applied Computing (SAC) [2 papers]
Computer Languages, Systems & Structures [1 paper]
4. Study has no accessible full-text online. International Conference on Advanced Communication Control and Computing
5. Documents that are books or gray literature. Technologies (ICACCCT) [1 paper]
6. Study is a duplicate. (We kept the longer version.) International Conference on Computer Science and Information Technology (CSIT)
[1 paper]
After this filtering step, 144 papers remain. International Conference on Informatics and Systems (INFOS) [1 paper]
International Conference on Objects, Components, Models and Patterns [1 paper]
International Conference on Software Engineering Advances (ICSEA) [1 paper]
4.5. Snowballing International Conference on Software Technology and Engineering (ICSE) [1 paper]
International Conference on Systems, Programming, Languages and Applications:
We consider both the references of each study and any study refer- Software for Humanity [1 paper]
encing the said study for each of the 144 studies yielded by the previous International Journal of Software Engineering and Knowledge Engineering [1
paper]
step.
International Journal of Software Innovation [1 paper]
To search for forward references, we use the Scopus search engine. International Symposium on Foundations of Software Engineering (FSE) [1 paper]
We apply the same year restriction (1995–2022) and the same criteria International Workshop on Context-Oriented Programming [1 paper]
for filtering. After the third iteration of snowballing, we notice that all Journal of Object Technology [1 paper]
of the results are duplicates of already included studies, so we stop the Journal of Software [1 paper]
Journal of Systems and Software [1 paper]
snowballing process. Both the first and second authors of this study Journal of the Brazilian Computer Society [1 paper]
independently perform this step. The second author was not privy to Lecture Notes in Computer Science [1 paper]
the research questions being assessed until the process was done. We Second Eastern European Regional Conference on the Engineering of Computer
consolidate the results afterwards and address any discrepancies. After Based Systems [1 paper]
Software Engineering and Knowledge Engineering (SEKE) [1 paper]
eliminating all duplicates, we obtain a total of 157 studies that could
Software Technology and Engineering Practice (STEP) [1 paper]
provide data to answer our research questions. Software: Practice and Experience [1 paper]
Workshop on Aspects, components, and patterns for infrastructure software
4.6. Compilation form (ACP4IS) [1 paper]
Workshop on Generic Programming (WGP) [1 paper]
Workshop on Reuse in Object-Oriented Information Systems Design [1 paper]
To compile the information from the obtained studies systematically
and consistently, we build a form that we fill out for each study. Our
form has the following information:

1. The title of the study.

2. The type of the study (experiment, case study, conceptual anal-
ysis, literature review, or survey).
3. The study publication venue.
4. The study publisher (or digital source).
5. A list of all design patterns mentioned by the study.
6. A list of all language features proposed by the study to improve
the specified design patterns.
7. A list of all measures used by the study to evaluate the suggested
improvements. Fig. 3. Papers distribution by year.
8. In the case of experiments, information about the participants
(number and expertise).
9. In the case of case studies, information about the studied cases
venues show up multiple times, such as PLoP,2 ECOOP, OOPSLA and
(number and whether or not they are in-vivo or in-vitro).
SAC, but the rest of the papers all come from different venues. The
After using the form to extract data from the 157 compiled studies, large variety of publication venues could indicate that the subject of
we remove 123 as they did not provide an answer to any of our research using language features to improve object-oriented design patterns is
questions. Many of the studies were evaluating the impact of existing rather niche and that there is no specific venue for this.
design patterns, rather than any improvements, and this does not fit Fig. 3 shows the distribution of publication years of the studies.
the goal of this study. (Thus, we remove 123 of the obtained studies, Interest in the subject seems to have peaked between 2010 and 2016.
confirming that we were conservative in our process and likely did not Out of the 34 papers, there are 18 conference papers, 11 journal
miss any relevant paper.) We finally obtain 34 studies. papers, and 5 workshop papers. The full data collected on each paper,
including publishers, is available in our replication package.3
5. Results We extract from each paper any language feature used to improve
object-oriented design patterns. We use a broad definition of language
We classify the 34 remaining studies in various ways to answer our features. The extracted data is, as expected, very diverse. Some features
research questions. We first perform a general analysis of the sources are closely related to specific programming paradigms (e.g., aspect-
(publication venues and publishers) the papers came from. Finally, we oriented pointcuts). Other features are more general and could be
categorize each study into a type and take a more detailed look at the
experiments and case studies.
Table 3 shows the number of papers for each publication venue. As 2
PLoP entries include EuroPLoP (3 papers) and VikingPLoP (1 paper).
3
we can see, there are a large variety of venues in our dataset. Some https://www.ptidej.net/downloads/replications/ist22/.

5
W. Flageol et al. Information and Software Technology 160 (2023) 107222

Table 4
Summary of papers on language features for improving design patterns implementations.
Paradigm Language feature Papers # papers Language
Functional Programming Case Classes [S1] 1 Scala
Functional Programming Closures [S2,S3] 2 Haskell
Functional Programming Immutability [S4] 1 Scala
Meta-Programming AOP Annotations [S5,S6] 2 Java
Meta-Programming AOP Mixins [S7,S8] 2 Java
Meta-Programming AOP Join-point [S9,S10,S11,S12,S13,S14,S15,S16,S17,S18,S19,S20,S21,S22,S23,S24,S25] 17 Java
Meta-Programming Layer Objects [S26] 1 Pseudo-Java
Meta-Programming Pattern Keywords [S27,S28] 2 Java
Meta-programming Reflection [S29,S30,S31] 3 Java
Object-Oriented Programming Chameleon Objects [S3] 1 N/A
Object-Oriented Programming Class Extension [S12] 1 Java
Object-Oriented Programming Default Implementation [S3] 1 N/A
Object-Oriented Programming Extended Initialization [S3] 1 N/A
Object-Oriented Programming Mixins [S32,S4,S3] 3 Java, Scala
Object-Oriented Programming Multiple Inheritance [S4] 1 C++
Object-Oriented Programming Object Interaction Styles [S3] 1 N/A
Object-Oriented Programming Subclassing members in a subclass [S3] 1 N/A
Reactive Programming Signals [S33] 1 Scala

applied in many ways (e.g., mixins). To make sense of this data and
obtain a global view, we create a mind map of these improvements
that can be seen in Fig. 4.
In this figure, nodes represent paradigms, paradigm applications
and language features. Colours represent the type of node. This mind
map helps navigate and make sense of the data. We classified language
features into the paradigms to which they relate the most. However,
some features could fit into multiple categories. When this happened,
we classified the feature according to how it was presented in the
study where it appeared. For example, we found different studies per-
taining to Mixins in the context of both Aspect-Oriented Programming
and Object-Oriented Programming, thus we added the feature to both
paradigms. We explain our categorization in the following.
Purple nodes represent programming paradigms. We define a pro-
gramming paradigm as a set of cohesive features for linking domain
concepts with programming concepts and for organizing these pro-
gramming concepts. We identified in our dataset four main paradigms:
Object-oriented Programming, Functional Programming, Meta-progra-
mming and Reactive Programming.
Green nodes in the mind map represent language features. We
define a language feature as an element of the syntax or grammar
of a programming language that can be used to express a solution
to a problem. For example, classes are a language feature of object-
oriented languages used to represent real-life categorization of objects
and create and manipulate instances of those objects. In our mind map,
we assigned each language feature found in the studies to its underlying
paradigm.
Table 4 offers a detailed view of the information discussed in this
section. The table contains references to every paper in the study and
can be used to find papers on a particular language feature or paradigm.
We also specify the implementation languages presented in the papers
for each of the features where available.

5.1. Meta-programming

Meta-programming is a paradigm allowing programs to generate

or modify their structure (either at compile, load-time, or run-time).
It is possible to effectively implement new paradigms using Meta-
programming, its classification is slightly different from that of the
other paradigms. Directly under Meta-programming, we classify ap- Fig. 4. Mind map of paradigms, languages, and features for improving design patterns.
plications of Meta-Programming (as yellow nodes). These applications
are specific usage of Meta-programming to create new languages. For
example, we classify Aspect-Oriented Programming as an application of For example, Krishnamurthi et al. [S34] use the MzScheme language’s
Meta-programming because it modifies the structure of the target pro- meta-programming capabilities to implement Zodiac, an extension to
gram at compile-time. Meta-programming applications are paradigm the language combining features from Object-Oriented Programming
extensions to a target language, rather than stand-alone paradigms. and Functional Programming to implement the Visitor pattern.

6
W. Flageol et al. Information and Software Technology 160 (2023) 107222

5.1.1. Aspect-Oriented Programming Yet another implementation of AOP uses mixins or an equivalent
Aspect-Oriented Programming (AOP) is a paradigm extension to feature. Kuhlemann et al. [S7] use Jak, a Java language extension
procedural programming that was introduced in 1997 by Kiczales et that combines classes and mixins, to achieve similar functionality to
al. [6]. The goal of AOP is to increase modularity by encapsulating AspectJ. They implement every design pattern in Jak and compare their
cross-cutting concerns into code units called Aspects. Aspects are a lan- implementations to AspectJ implementations [S12]. They conclude that
guage construct similar to classes in OOP. OOP/AOP implementations, Jak has better support for modularizing cross-cutting concerns, but
like AspectJ [20], are the most popular in the literature, even though that the extension should be complementary to AspectJ. Axelsen et
the original study did not associate AOP directly to OOP. al. [S8] propose the concept of Package Templates to implement the
AOP works by making changes to the structure of the program at Observer pattern and compare it to an AspectJ implementation. Package
specific points. For example, it is possible to create an aspect which Templates function like module mixins (at the package level) in that
adds logging functionality to every method of a given class. Thus, with they can introduce (generate) new classes, methods and attributes when
AOP, it is possible to extract recurring functionality to encapsulate them used. They showed that their approach provides a sufficiently powerful
in aspects and avoid cluttering classes with unrelated, or cross-cutting,
framework to implement design patterns with minimal AOP mechanism
concerns.
compared to the join-point approach.
Among the primary studies, we found three main implementa-
tions of AOP within OOP. The most common implementation [S9,S10,
S11,S12,S13,S14,S15,S16,S17,S18,S19,S21,S22,S20,S23,S24,S25] uses 5.1.2. Layer Objects
pointcuts and advices (also called the join-point model) to modify Springer et al. [S26] present the concept of Layer Objects to imple-
existing classes. Consider the following pointcut4 : ment the Decorator, Observer, and Visitor design patterns using Context-
Oriented Programming, which allows changing the behaviour of objects
pointcut setter(): target(Point) && based on scope (or context). A Layer Object can be activated (e.g., with
(call(void setX(int)) || the with keyword) within a specific scope, and will override the
call(void setY(int))); behaviour of specified classes within that scope. They present examples
implemented in a Java-like pseudo-code.
This pointcut designates every location where a method named With this feature, it is possible to add behaviour to an existing
setX or setY, with a single argument of type int and a return value object (as per the Decorator pattern). For example, if we had a Field
of void, is called on an instance of the class Point.
class, representing a tile in a game and wanted to add a ‘‘burn-
The second part of this model is the advice, which designates the
ing’’ by which a player takes damage when entering the field, the
code inserted at every location referenced by the pointcut. Advices
BurningFieldDecorator could be implemented as such:
typically take the form of a regular method of the extended language,
with the exception that it is usually decorated with a keyword such as
after, before, or around, which dictates where the advice should class Field {
be inserted relative to the pointcut. def enter(player) {
The example shown is unrelated to design patterns implementa- // Do something when a player enters the field.
tions, since using AOP to implement design patterns typically involve }
multiple files and many lines of code, which would make it more }
difficult to see the important features of the paradigm.
Hannemann and Kiczales [S12] present a full implementation of ev- class BurningFieldDecorator {
ery design patterns using AspectJ and compare them to Java implemen- def damage = 15;
tations. They reported that they could remove many code duplications.
For example, in the case of Observer, they extract the record-keeping def Field.enter(player) {
of the observer list, as well as the add and detach methods, into an player.health -= thisLayer.damage;
abstract aspect named ObserverProtocol. proceed(player);
AOP can be implemented in a different way using code annota- }
tions [S5,S6]. This approach is similar to the join-point model, replac- }
ing the pointcuts with annotations. This approach is used by the C#
framework PostSharp [21]. Using this framework, one could implement // Usage example
Microsoft WPF INotifyPropertyChanged interface, which is an def decorator = new BurningFieldDecorator();
implementation of the Observer pattern, with the following annotation5 :
field.activate(decorator);
[NotifyPropertyChanged]
public class Person 5.1.3. Pattern Keywords
{ Some studies opted for introducing design patterns directly. Ghaleb
public string FirstName { get; set; } et al. [S27] propose integrating Decorator, Observer, and Singleton as
public string LastName { get; set; } keywords. For example, a Singleton could be declared like this:
public Address Address { get; set; }
} public singleton class A
{
Using this approach, Giunta et al. [S5] and Jicheng et al. [S6] create
instantiate A as s1;
annotations to represent the Factory Method, Observer, and Singleton
design patterns.
public static void main(String[] args)
{
4
https://www.eclipse.org/aspectj/doc/released/progguide/language- instantiate A as s2, s3;
joinPoints.html. }
5
https://www.postsharp.net/postsharp. }

7
W. Flageol et al. Information and Software Technology 160 (2023) 107222

The singleton keyword marks the class A as a Singleton, of which 5.3. Functional Programming
its unique instance can be obtained using the instantiate keyword.
Zhang and Oliveira [S28] do something similar with the Visitor Functional Programming is a paradigm that uses pure functions
pattern by introducing EVF. EVF is a framework to implement Visitors to assemble higher-order functions (i.e., functions that receive other
in Java. It introduces new keywords in the form of annotations (such as functions as arguments, such as map, reduce, etc.) to create programs.
@Visitor) to create data structures with internal or external visitors. We classified studies that used features related to this paradigm: case
Adding keywords to a language to directly support design patterns classes [S1] (also called pattern matching), closures [S2,S3], and im-
requires either the use of Meta-programming or the creation of lan- mutability [S34]. We admit that immutability is less of a feature and
guage extensions or domain-specific language. Unlike the approach more of a property, but it is a property of pure function and functional
presented by Krishnamurthi et al. [S34], where they used the macro languages usually support and sometimes enforce immutability. Im-
feature of MzScheme to implement Zodiac, an extension to the language mutability can also affect how design patterns are implemented [S34],
for implementing Visitor, the studies presented under this feature used which is why we chose to include it here.
third-party tools to add keywords to Java. The effect, however, is the
same as if they had used macros to create these keywords (which Java 5.3.1. Case Classes
does not support). Whether design patterns should be language features Case Classes, also known as pattern matching, are a feature of
is however debatable [22]. functional programming languages. In Scala, Case Classes are used
to create sets of classes that can be distinguished using the match
5.1.4. Reflection keyword. Oliveira et al. [S1] use Scala to present many variations of the
Reflection is an application of meta-programming. It allows devel- Visitor design patterns, as well as a library to use them. They use Case
opers to manipulate the data structures at run-time. For example, one Classes to implement the accepting mechanism of this design pattern.
They then use pattern matching to distinguish the different types to
could add a new method to an existing class, change the type of an at-
visit. Using their library, it is possible to implement the Visitor design
tribute, etc. Unlike macros or Aspect-Oriented Programming, Reflection
pattern:
typically does not allow modifying code directly (e.g., inserting lines of
code in the middle of a method). Reflection is available in mainstream // Visitor structure for a Binary Tree.
programming languages like Java and C#. trait Tree {
Fortuin [S29] uses Reflection to implement the Abstract Factory def accept[R] (v :TreeVisitor[R]):R
pattern in Java. They use a static method that, based on the given argu- }
ments, constructs an object by accessing the proper class constructors case class Empty extends Tree {
and passing the arguments using a hashtable. def accept[R] (v :TreeVisitor[R]):R = v.empty
Mai and Champlain [S30] and Hussein et al. [S31] use Reflection to }
implement the Visitor pattern to overcome the limitation of Java of only case class Fork (x :int,l : Tree,r: Tree) extends Tree {
supporting single dispatch (as discussed in Section 5.3.1 about Case def accept[R] (v :TreeVisitor[R]):R =
Classes). Mai and Champlain [S30] defined a findMethod method v.fork (x,l,r)
that gets the correct Visit method on the visitor object. Reflection }
could also be used to automatically implement accept methods on the
target, removing the cross-cutting concern from the visitable object. trait TreeVisitor[R] {
def empty :R
5.2. Reactive Programming def fork (x : int,l :Tree,r: Tree):R
}
Reactive Programming [S33] is a design paradigm which addresses
asynchronous programming logic, especially concerning value updating // Concrete implementation of visitor to calculate
and change propagation. It can be combined with Functional and // the depth of the Tree.
Object-Oriented Programming to facilitate dealing with problems re- def depth = new CaseTree [External,int] {
lated to data updating (the same kind of problems targeted by the def Empty = 0
Observer design pattern). Scala offers libraries such as REScala [23] and def Fork (x : int,l :R[TreeVisitor],r:R[TreeVisitor]) =
Scala.react [24] to enable reactive programming in the language. 1+max (l.accept (this),r.accept (this))
}
5.2.1. Signals
Signals are a feature of Reactive Programming that allows express- This implementation does not require both accept and visit
ing dependencies among values [S33]. When a dependency of a signal methods usually present in the Visitor implementation. They only im-
changes, the expression defined by the signal is automatically recom- plement an accept method.
puted from the new values of the dependencies. This functionality is
similar to the Observer pattern. For example, take the following Scala 5.3.2. Closures
code: Closures are the main feature of the Functional Programming
paradigm. A Closure is an encapsulation of behaviour and data, much
val a = Var(1) like Classes are in OOP. Unlike Classes, a Closure only encapsulates
val b = Var(2) one function and its data cannot be directly accessed from outside
val s = Signal{ a() + b() } the closure (with some exceptions). Closures are supported by most
modern languages, such as Java, C#, C++, Python (with some caveats),
println(s.getVal()) // 3 JavaScript, Kotlin, etc. In most languages, Closures are created using
a() = 4 some kind of lambda syntax such as :
println(s.getVal()) // 6
var i = 42
When the value of variable a changes, so does the value of signal var closure = (argument) => {
s. Thus, support of Signals and Reactive Programming in a language // Some code which can use the i variable.
renders the Observer pattern obsolete. }

8
W. Flageol et al. Information and Software Technology 160 (2023) 107222

Gibbons [S2] present advanced uses of the map, fold, and other 5.4.2. Class extension
standard FP methods in Haskell. They discuss functional implementa- Hanneman and Kiczales [S12] use AOP to implement design pat-
tions of the Composite (using recursive data structures), Iterator (us- terns using different features of AspectJ for different patterns. For
ing map), Visitor (using fold), and Builder (using unfold) design Adapter, Bridge, Builder, Factory Method, Template Method, and Visitor,
patterns. they specifically use the open class feature of AspectJ, which allows
Compared to Closures, the Command design pattern has the advan- classes to be extended with new methods and attributes outside of their
tage of being able to expose its data to the outside world if needed, declaration (at compile-time).
allowing some degree of control over the behaviour of the object. With class extensions, it becomes possible to encapsulate duplicated
Batdalov and Nikiforova [S3] propose to replace conventional functions code from a design pattern implementation into an extension. For
with a generalization of the Command design pattern. Every function example, we could extract the accept method of the Visitor pattern
or method would become a Functor (an object with a single public into a class extension, effectively allowing a Visitor-free implementation
method) and would make usage of the Command pattern obsolete. to exist independently of its pattern implementation.

5.3.3. Immutability 5.4.3. Default Implementation

Immutability is a property of many Functional Programming lan- Default Implementation is a feature proposed by Batdalov and
guages. The Haskell language enforces immutability, which in turn Nikiforova [S3]. It allows abstract classes to specify a default concrete
makes the use of certain functional design patterns, such as monads, implementation. This feature is similar to how the Abstract Factory
ubiquitous in the language. pattern is implemented in Dependency Injection frameworks, such as
Spring.7 Beyond Abstract Factory, the authors argue this feature would
Immutability has an effect on design patterns implementations.
help implementations of the Builder, Bridge, Command, and Strategy
For example, we stated above that the Command design pattern is
patterns.
similar to Closures, with the exception that it can expose its internal
data and mutators. In an immutable context, this advantage becomes
unconsequential as the exposed data could not be interacted with in any 5.4.4. Extended Initialization
significant way. In an immutable context, Closures make the Command Extended Initialization is a feature proposed by Batdalov and Niki-
pattern obsolete. forova [S3] to help with the implementation of the Builder and Factory
Sakamoto et al. [S4] present two variations on the State design Method patterns. This feature would allow object creation to be divided
pattern implemented using Scala. One of these is the Deeply Im- into multiple steps (effectively achieving the same functionality as the
mutable State pattern, which makes use of the immutability features Builder pattern and rendering it obsolete).
of Scala (such as the ability to easily clone Type Classes while modi-
fying certain attributes, similar to Record Updating in OCaml6 ) for its 5.4.5. Mixins
implementation. While we already introduced Mixins in the context of Aspect-
Oriented Programming in Section 5.1.1, this feature can be used
separately from AOP. Mixins are an extension of the OOP paradigm
5.4. Object-Oriented Programming
to combine classes together. Unlike inheritance, Mixins do not enforce
an ‘‘is-a’’ relationship between the individual classes.
Object-Oriented Programming is a paradigm that uses four general Burton and Sekirinski [S32] present implementations of the Deco-
features to organize code: encapsulation, abstraction, inheritance, and rator, Proxy, Chain of Responsibility, and Strategy design patterns using
polymorphism. Features classified under this paradigm directly affect Mixins in Java. For example, a Decorator may be implemented by
OOP or require it to function. For example, the Chameleon Objects [S3] combining the Decorator with the target class, as such:
feature allows objects to dynamically change class. This requires and
affects classes and objects, features which are directly related to OOP. class Component { Operation(); }

5.4.1. Chameleon Objects class ConcreteComponent implements Component { ... };

Chameleon Objects is a feature proposed by Batdalov and Niki-
forova [S3] to help with the implementation of the State and Factory class DecoratorMixA implements Component
Method design patterns. The feature allows an object to change class at needs Component
runtime. While no language was presented in Batdalov and Nikiforova’s Operation() { ... Component.Operation() };
paper, some languages allow such change already (e.g., Common Lisp,
Perl). With this feature, it is possible to implement the State pattern by class DecoratorMixB implements Component
changing the class of an object when it changes state. The same feature needs Component
could be used to allow a class constructor to change the instantiated Operation() { ... Component.Operation() };
object class depending on its arguments, effectively implementing a
Factory Method. // Usage
In Common Lisp, a class can be changed using the following simple class Client {
line: main() {
ConcreteComponent cc =
(change-class target-object target-class) new ConcreteComponent with DecoratorMixA;
extend cc with DecoratorMixB;
The same can be achieved in Perl with the bless keyword:
cc.Operation();
}
bless $targetObject, ’Package::TargetClass’; }

6 7
https://dev.realworldocaml.org/records.html. https://spring.io/.

9
W. Flageol et al. Information and Software Technology 160 (2023) 107222

The authors declared that both decorators are of type Component the change, as the interface of the parent class Fragment requires this
but also require a concrete instance of Component as a Mixin. In the method to return the type Activity.
usage section, they mix the concrete instance ConcreteComponent The proposed feature would allow us to make that change. The
with the DecoratorMixA class, and then extend it with Decorator feature does not violate covariance or contravariance but could be
MixB, effectively creating an object which is a combination of all three considered unsafe in some cases [25].
classes.
Sakamoto et al. also use Mixins in their implementation of the State
5.5. Design patterns
pattern in Scala. Batdalov and Nikiforova [S3] propose a concept of
Responsibility Delegation, which would allow a class to delegate a
part or all of its responsibility to another class (perhaps similar to the For each primary study, we extracted the design patterns for which
DoesNotUnderstand method in Smalltalk), achieving a behaviour improvements were suggested. Fig. 5 shows the distribution of the
similar to Mixins. number of studies by design pattern. As discussed in Section 4, we only
considered patterns from the GoF book [1].
5.4.6. Multiple Inheritance Fig. 5 shows researchers’ interest in design patterns. We notice
that some patterns are more prevalent than others in our dataset. In
Many OOP languages only support single inheritance. This led to
particular, Observer, Visitor, and Decorator receive the most attention
the introduction of interfaces to circumvent the limitation of an object
from researchers.
only being able to be part of one hierarchy. Interfaces, however, do not
typically allow reuse. If we look at the number of features associated with each pattern,
Some design patterns have duplicated code that we could factor into Observer and Visitor also come on top, but there is an interesting
another class, to reduce code duplication and cross-cutting concerns. relationship at play here. While Observer has received overwhelmingly
For example, one could extract the bookkeeping logic of the Observer more attention from papers (20 papers against Visitor 13), they have the
pattern into another class and have observable objects inherit that class. same number of associated features. Also, they have a similar amount of
However, in a single-inheritance context, this would ‘‘hijack’’ the only papers focusing solely on them ([S9,S13,S14,S8,S33,S17] for Observer
inheritance possibility for the observable object. and [S28,S30,S1,S34,S23,S31] for Visitor). Other patterns have very
Sakamoto et al. [S4] present an implementation of the State design few papers that address only them. The only other two are Abstract
pattern in Java (using single inheritance) and C++ (using multiple Factory [S29] and State [S4].
inheritance). They evaluated that the Java implementation has code
duplication, while the C++ implementation does not. 5.6. Measures

5.4.7. Object Interaction Styles We extracted the different measures used in the studies to com-
Object Interaction Styles is a feature proposed by Batdalov and pare the suggested improvements to design patterns to the classical
Nikiforova [S3] to help with the implementation of the Proxy, Observer, implementations. Some studies did not measure or compare their im-
and Facade patterns. They would allow different ways of interacting plementation and were demonstrations of new language features or of
with objects through method calls. The default interaction style is a language extension. We observed 39 different measure names.
synchronous calls, where a caller awaits the result of the method before Some measures are more prevalent than others to measure improve-
continuing to the next instruction. Other interaction styles include ments. The top ten measures are related to the usage of inheritance
asynchronous request/response, broadcast, and publish/subscribe. An (DIT), coupling and cohesion (CBC, LCOO), concern diffusion (CDC,
example of this would be the async syntax in C# and JavaScript. CDLOC, CDO), code size (LOC, NOA, WOC), and reusability. This
matches the stated goal of design patterns [1].
5.4.8. Subclassing members in a subclass Most of these measures (DIT, CBC, LCOO, LOC, WOC) come from
Batdalov and Nikiforova [S3] propose that OOP languages allow the Chidamber and Kemerer suite of measures [26]. Concern diffu-
subclassing a member in a subclass to help with the implementation sion measures relate to measuring improvements from Aspect-Oriented
of the Template Method and Visitor patterns. A subclass may redefine Programming regarding cross-cutting concerns [S11].
one of its members by restricting its class. Many of the other measures are unique to only one paper. For
To understand this feature, let us take the example from [S3] about example, Teebiga and Velan [S10] use a measure they call lines of class
Android development. Take the following pseudocode: code (LOCC), which they attribute to Ceccato and Tonella [27]. LOCC
measures the number of lines of code within classes (as opposed to
class Activity { ... } within aspects). The measure is similar to the number of lines of code
class Fragment { (LOC), but the context in which it is used (i.e., to differentiate between
... aspect and class code) is different enough that we opted to classify it
Activity getActivity() { ... } as its own entry.
} Most of the measures extracted are used in AOP studies. The results
presented by the studies were mixed. In general, AOP implementations
If we wanted to subclass Activity into a new class MyActivity of design patterns show smaller code size (LOC and NOA), a decrease
and Fragment into MyFragment, we would end with the following in concern diffusion (CDC, CDO, CDLOC) and an increase in cohesion
subclasses: (LCOO) [S10,S11,S12,S24,S25,S21,S20]. However, some studies report
AOP pattern implementations with increased code size and higher
class MyActivity extends Activity { ... } complexity (WOC) [S24,S11]. One study by Giunta et al. [S15] com-
class MyFragment extends Fragment { pared the execution time of AOP design patterns implementations to
... classical implementations and found that AOP implementations tend
Activity getActivity() { ... } to be slightly slower. Note that despite DIT being the most popular
} measure, results in most studies showed no difference between the AOP
implementations and the classical implementations.
However, if we knew the getActivity method of MyFragment Only three non-AOP papers make use of any measure at all [S28,
could ever only return instances of MyActivity, we could not make S33,S4].

10
W. Flageol et al. Information and Software Technology 160 (2023) 107222

Fig. 5. Number of papers by design pattern.

Zhang and Oliveira [S28] use lines of code to compare various comprehension of design patterns using reactive programming with 38
Visitor implementations. They unsurprisingly find that the version using undergraduate students (which we discuss in Section 5.6).
a Pattern Keyword, via annotations, has a smaller code size. These findings mean that there was no study involving practitioners
Salvaneschi et al. [S33] ask participants to answer specific ques- (e.g., professional developers). The only experiment used students and
tions to test their comprehension of Reactive Programming. They then every case study used a project developed in-vitro. We interpret this
measure their correctness in answering the questions (score of the par- fact to mean that most of the new features proposed have not been
ticipants on the task), their comprehension of the code (time required to extensively tested.
complete the task) and the skill floor (a correlation between measured
programming skill and performance during the task). They find no
significant relationship with regards to comprehension and skill floor 6. Discussion
but find that the correctness of the participants is increased in the group
analysing code programmed using Reactive Programming.
6.1. Language features
Sakamoto et al. [S4] compare the amount of duplicated code and the
number of classes and coupling between implementations of the State
patterns. They find that using Multiple Inheritance to implement the Our first research question is: What language features have been
pattern reduced the amount of code duplication and that using mixins suggested to improve design patterns implementations?
reduced both code duplication and the number of classes and relations. We extracted 18 features from 34 selected papers. These features
The other non-AOP papers were descriptive studies presenting a range across a variety of programming paradigms and improve design
new feature without any comparison. They argued improvements in an patterns implementations in various ways.
informal way. Many of these features (7 out of 18) were implemented as extensions
to Java. In general, Java seems to be the most popular language
5.7. Experiments and participation to discuss improvements in design patterns. The next most popular
language seems to be Scala, which is another JVM language, most
We extracted out of the papers those that were case studies and often used to discuss functional programming features. Even when
experiments to answer our fourth research question: What experiments using dynamically-typed pseudo-code, Springer et al. [S26] describe
have been done on these language features? it as ‘‘Java-like’’, even though to us it looks more like Python with
We found 10 case studies and only one experiment out of the 34 brackets. There seems to be a prevalence of Java in design patterns
studies in our data. The case studies compare a new feature against and OOP research, which may be a concern because Java does not
established OOP implementations. Case studies can be divided based represent every OOP language, and many features available in other
on the source of their subjects: either in-vivo or in-vitro. In-vivo case OOP languages, such as C#, Common Lisp, Kotlin, and Smalltalk, are
studies are done on already-existing software, often available online not available in Java.
as open-source projects. In-vitro case studies are done on software Most features stem from Meta-programming applications, which
made specifically for the case study. Every case study in our analysed modify or insert code into OOP software. Features like Reflection
studies was in-vitro because there are not many (if any) opportunities and Pattern Keywords are used to reduce the amount of code du-
to find projects developed by third parties using new tools or methods plication and code size of design patterns. It is not surprising that
proposed by a paper. Meta-programming is a popular tool to address code duplication and
We found only one study that performed a controlled experiment. size, as one of its main strengths is the ability to factor out code and
Salvaneschi et al. [S33] performed an empirical experiment on program remove duplication.

11
W. Flageol et al. Information and Software Technology 160 (2023) 107222

Aspect-Oriented Programming is a major part of the Meta-program- Our data indicate that some design patterns are more prevalent than
ming features. AOP and Layer Objects, while also reducing code dupli- others as targets for improvement. Some papers include every 23 GoF
cation, focus on reducing cross-cutting concerns in design patterns [S12]. design patterns in their study (3 papers), but most analyse specific
Despite AOP being a language and paradigm-agnostic feature (the patterns.
original paper was presented using Common Lisp [6]), every paper We observe that the most prevalent patterns to improve are the
in our dataset discusses it using various Java extensions. While there Observer, Visitor, and Decorator design patterns. We could interpret
are solutions which borrows from AOP in other languages, such as the pattern prevalence in different ways. Perhaps these patterns are those
PostSharp library in C#, the paradigm itself does not seem to have that have the most obvious flaws, and that is why many papers propose
gained much traction in other languages. features to improve them. We thought perhaps the most prevalent
Some studies also presented domain-specific languages added on top patterns in research would also be the most used in practice, but that
of an existing language, such as Zodiac, an extension of MzScheme used does not seem to be the case. Observer may well be the most used
to implement the Visitor pattern [S34]. pattern of all, but it would be difficult to argue that Visitor is.
Many features were also suggested to extend OOP. Chameleon The fact that Observer and Visitor are the most prevalent patterns,
Objects allow changing the class of an object at runtime. Mixins allow that they have the most associated language features, and that they
combining multiple classes together to facilitate reuse through compo- have the most papers focusing solely on them would indicate that the
sition. Multiple Inheritance solves some issues with code duplication by underlying problems these patterns are solving are of great interest to
allowing multiple sources of reuse. Code reuse in pure OOP is usually OOP.
limited to inheritance and subtyping mechanisms, so naturally, the In the case of Observer, there is a need in software systems for
features suggested interact with these mechanisms. controlling data flow and change propagation. The Observer pattern as
Some features come from Functional Programming. Case Classes in described in the GoF book [1], however, comes with some limitations.
Scala are an implementation of pattern matching, which can be used As discussed in Section 5.4.6 about Multiple Inheritance, the Observer
to circumvent the issues of single dispatch languages and facilitate the implies duplication that cannot be easily abstracted using inheritance.
implementation of the Visitor pattern. The feature has been gaining It also has cross-cutting concerns [6], [S12] because it requires the
popularity of late, being added to existing languages such as C# and observed object to know and manage its observers. The proposed
Java in the form of Records. language features improve on these aspects.
Closures are another functional feature that has been implemented
In the case of Visitor, modern programming languages (such as
in many OOP languages, such as Java, C++, and C#, but also part of
Java, C++, and C#) lack support for dynamic dispatch on function
older languages, such as Smalltalk (code blocks) and Common Lisp.
parameters. In OOP, dynamic dispatch is only supported on the object
They can make the implementation of many design patterns easier by
on which a method is invoked (allowing the use of polymorphism).
storing behaviour as values. It is interesting, and telling, that the feature
Some languages, such as the Common Lisp Object System (CLOS),
was already included in Smalltalk, one of the originators of OOP, but
support both OOP and dynamic dispatch on function arguments, effec-
was then excluded from later implementations of the paradigm in Java
tively allowing multiple dispatch. In such languages, the visitor pattern
and C++, only to be added back to these languages later.
becomes trivial as there is no longer any need for the accept/visit
Immutability, when combined with other features such as Closures, mechanism.
can render certain patterns obsolete (e.g., Command) and simplify the
Most of the solutions proposed a way to circumvent the lack of
implementation of others (e.g., State). Patterns that are built around
dynamic dispatch on function arguments through the use of Reflection,
the idea of encapsulating changing state are made much simpler when
Case Classes (pattern matching), or Aspects. Many studies propose
state changes are eliminated entirely.
ways to make the implementation of the Visitor easier by integrating
Finally, Signals and Reactive Programming have been created to
it into the language using aspects [S12], factoring its complexity using
solve the same underlying problem as the Observer pattern. Managing
reflection [S30,S31], or simplifying it using pattern matching [S1].
events and changes in a program is a common concern. Especially in
GUI development, many platforms propose different approaches to this
Research Question #2
concern. Some, like Java Swing, make use of the Observer pattern.
Others, like Microsoft WPF, propose a system based on the Command
pattern. Reactive Programming incorporates change management at the Which design patterns have the most associated language features
language level. suggestions?
Research done to improve design patterns seems to favour
Research Question #1 specific patterns. Observer, Visitor, and Decorator (in order of
appearances) are most often studied. In particular, Observer
What language features have been suggested to improve design and Visitor appear to stem from a lack of language support of
patterns implementations? certain features (such as propagation of change and dynamic
We catalogued 18 language features used to improve de- argument dispatch).
sign patterns implementations. Meta-programming features are
the most suggested, with many studies have written about
Aspect-oriented Programming. However, our timeline analy-
sis suggests that AOP is not as prevalent nowadays and that 6.3. Measures
Functional Programming features are becoming more and more
popular.
For the third research question, RQ3: What measures have been
used to evaluate the impact of these language features on design patterns
implementations?, we extracted the measures used by each paper and
6.2. Design patterns looked at their distribution.
The measures most often used were those related to reusability. In
The second research question is RQ2: Which design patterns have the particular, two sets of measures were prevalent: the CK measures [26]
most associated language features suggestions? and AOP-related measures [S11].

12
W. Flageol et al. Information and Software Technology 160 (2023) 107222

Most of the papers with measurements and comparisons were re-

lated to AOP. Most non-AOP papers were descriptive studies and of- of studies done on professional projects developed indepen-
fered no measurement or comparison of the performance of their dently. We found only one experiment, which used student
proposed features. participants.
For AOP papers, measure results were mixed. While many AOP
implementations showed improvements with regard to concern diffu-
sion, cohesion, and code size, some studies reported increased code
size and higher complexity. Non-AOP papers showed more straightfor- 7. Recommendations
ward results, with reduced code size for Pattern Keywords, reduced
code duplication for Multiple Inheritance and Mixins, and improved
understandability for Reactive Programming. We list below notable or interesting findings and add our recom-
The measures most used indicate that design patterns may be a mendations for future work.
source of complexity and that maintainability and understandability Meta-programming features seem the most prevalent to implement
could be improved by making their implementation simpler using cer- new features to potentially improve OOP design patterns implementa-
tain language features. There is also a concern about concern diffusion tions. The past prevalence of the AOP paradigm indicates that it had
in design patterns. For example, the objects involved in the Visitor good potential for improving OOP design patterns. Perhaps the intro-
pattern have the added concern of being part of the pattern (i.e., having duction of another layer of complexity (i.e., aspects and the popular
Visit or Accept methods). Some studies propose to extract this concern join-point mechanism used by AspectJ) on top of the OOP rebuked
from the involved objects and abstract it into its own unit (e.g., an developers from adopting the paradigm. While AOP popularity has
aspect). faded in recent years, it may still be of some use as a comparison point
for new methods or improvements.
Research Question #3 Meta-programming in general offers the possibility to extend lan-
guages by adding new features without the need for external tools.
What measures have been used to evaluate the impact of these While some features have been prevalent in mainstream languages,
language features on design patterns implementations? such as Reflection in Java and C#, many Meta-programming features
The measures most often used in the literature to evaluate are absent in mainstream languages. For example, Lisp-style macros,
improvements to object-oriented design patterns are measures allowing the effective addition of new keywords within a language, are
related to maintainability and understandability, especially seldom seen in modern languages.
those proposed by Chidamber and Kemerer [26]. AOP-related While we found few works that used Functional Programming to im-
papers also add measures related to concern diffusion, or prove OOP design patterns, the popularity of functional programming
cross-cutting concerns. appears to be on the rise. As more functional programming features
are added to OOP languages, it would be interesting to study how we
can use those features to improve OOP design patterns. There certainly
seems to be a trend in recent years to try to fuse OOP and FP together.
6.4. Empirical studies We believe the impact of this is worth studying.
Most existing research seems to favour specific design patterns.
Observer, Visitor, and Decorator were studied much more often than
Our final research question concerns empirical studies: RQ4: What others. Thus, we have more data on approaches to improve the imple-
experiments have been done on these language features? mentation of these specific patterns. Some design patterns only appear
Most of the studies in our dataset are descriptive studies (23 papers) in studies concerned with all 23 GoF patterns (most likely for the sake
proposing or explaining a new feature or language extension. These of completeness). It would be interesting to study the less prevalent
typically do not offer concrete data to compare the new features with patterns to understand what kind of approaches would specifically
existing approaches. improve those. Each design pattern solves a recurring design problem,
There are also 10 case studies in our dataset. Every case study on the so the community should strive to study these problems and, perhaps
subject is done in-vitro, with the studied subjects created specifically ideally, find features to solve them.
for the case study. It would be difficult to find software ‘‘in the wild’’ For reproducibility and comparability with existing research, when
using new features just proposed by a scientific paper. Because in-vivo evaluating or comparing improvement to OOP design patterns, it would
case studies are impractical, controlled experiments are important to be beneficial to include measures pertaining to maintainability and
evaluate the effectiveness of new technology. understandability. In particular, the CK measures [26] are particularly
We only found one experiment done on evaluating improvement to prevalent in this kind of research. These include depth of inheritance
design patterns implementations with 38 undergraduate students. As tree, lack of cohesion in operations, coupling between components,
mentioned above and in Section 5.7, there is a clear need for more em- number of lines of code, and weighted operations per component. AOP-
pirical experiments to evaluate the effects of proposed new features on related measures might be interesting to use also, for comparison with
design patterns implementations and on object-oriented development the many papers published proposing improvement using AOP. AOP
in general. In general, practitioners’ participation was lacking. While measures are mainly focused on cross-cutting concerns.
experiments on students have their advantages, experiments should However, these measures do not cover every possible improvement.
also be done on professional developers to gain better insight into the Some improvements are difficult to measure using quantitative data.
impact that the proposed features have on development. It would be important to explore less prevalent measures, or survey
developers’ opinions on code complexity and reusability and perform
Research Question #4 qualitative reviews.
Most papers we found were descriptive studies. More empirical
What experiments have been done on these language features? studies on real-world case studies and experiments using professional
Most of the studies are descriptive studies without comparison developers would yield a deeper understanding of the techniques, tools
data. There are also many in-vitro case studies, with a lack and features that can be used to improve OOP design patterns, and OOP
in general.

13
W. Flageol et al. Information and Software Technology 160 (2023) 107222

8. Threats to validity 1. What language features have been suggested to improve design
patterns implementations?
In this section, we discuss potential threats to the validity of this 2. Which design patterns have the most associated language fea-
study. While we tried to keep the study and its results as objective as tures suggestions?
possible, there are some threats that need to be addressed. We divided 3. What measures have been used to evaluate the impact of these
the threats into Internal, External, Construct, and Conclusion Validity. language features on design patterns implementations?
4. What experiments have been done on these language features?
8.1. Interval validity
We devised and followed a methodology (which we describe in
Section 4) that would yield the data needed to answer these ques-
The manual sorting, filtering, and compilation steps of the review
tions and the main objective of the mapping study and create a cat-
were done by the first author, which increases the consistency of the
alogue of 18 language features claiming to improve design patterns
results. Yet, it also introduces a threat to reliability and trustworthiness,
implementations.
so we added a second reviewer to help with the snowballing step and
We performed a search query in three databases which yielded 874
add some redundancy and a second viewpoint.
papers, which we then assessed for quality and used for snowballing, re-
sulting in a total of 34 primary studies. We then extracted relevant data
8.2. External validity
from these 34 studies and discussed and catalogued our observations
and their meaning.
Our results come from papers from a very diverse set of publication We categorized the language features found in the papers into
venues. The papers are not concentrated in popular venues concerning categories based on programming paradigms. We presented a summary
programming languages and design patterns, such as TOPLAS and of this map with every paper in our study, as well as a catalogue
POPL. We attribute this to the fact that this particular subject, propos- describing every feature extracted. We found that most of the research
ing language features to improve OOP design patterns implementation, on the topic suggested approaches related to Meta-programming, with
is more of a niche subject and less popular in prominent publica- Aspect-oriented Programming often considered, although interest in it
tions, and pertains more to software engineering than programming seems to have faded in recent years. The design patterns most often
languages. Most of the results in our query that were from major cited in papers on the topic were the Observer, Visitor, and Decorator.
publication venues tended to be about measuring the impact of design We also extracted every measure used in each paper into a table to
patterns, which was not within the scope of this study (and already has find the most frequently used. We found that measures related to
a mapping study [11] discussed in our related studies section). maintainability and understandability were most often used, with the
Chidamber and Kemerer [26] measures being particularly prevalent.
8.3. Construct validity With these findings, we contribute a catalogue of 18 language
features proposed in the literature to improve Object-Oriented
We defined our methodology as precisely as possible to make our design patterns. These features mostly aim to improve maintain-
results reproducible. The dataset used for this study is available online.8 ability and understandability by reducing concern diffusion and
We took some decisions that could affect the results of our study. The code duplication.
query used has many exclusion keywords to obtain more precise results. Our goal in finding language features that improve the implementa-
We tried queries with fewer exclusion keywords, but they did not add tion of design patterns in OOP is to improve the OOP paradigm itself. As
more relevant results which made the manual filtering more difficult. design patterns are solutions to recurring problems, including features
We believe any missing relevant results that were lost because of this in an OOP language that makes it easier to solve these problems makes
decision would have been caught during the snowballing step. the paradigm and languages themselves easier to use for practical
The manual sorting, filtering, and compilation steps of the review purposes.
were done by the first author, which increases the consistency of the This study can be used as a road map of existing literature that
results. Yet, it also introduces a threat to reliability and trustworthiness, we intend to use to research improvement to the Object-Oriented
so we added a second reviewer to help with the snowballing step and Programming paradigm. We will look at what features are needed in a
add some redundancy and a second viewpoint. language to improve maintainability and understandability and reduce
code size, coupling, and concern diffusion. We will use the identified
8.4. Conclusion validity measures to compare alternatives. We also intend to perform empirical
studies, in particular experiments.
We believe that the previous threats are acceptable and that differ- It may also be interesting to replicate this study on gray literature,
ent choices would not significantly alter the results of this mapping with a similar systematic approach adapted to general public search
study, whose goal is to identify trends in research on the subject engines (i.e., Google, Bing, DuckDuckGo, etc.). This would likely yield
of language features to improve OOP design patterns implementa- even more language features to improve design patterns, and perhaps
tions. As such, we limit our conclusions to that goal and propose different approaches to measuring improvements.
recommendations based on our findings.
Declaration of competing interest
9. Conclusion
The authors declare that they have no known competing finan-
In this paper, we presented a mapping study of the primary studies cial interests or personal relationships that could have appeared to
on language features to improve Object-Oriented Programming design influence the work reported in this paper.
patterns implementations. Our objective was to catalogue the lan-
guage features that were used in the literature to improve OOP design
patterns. We asked the four following research questions: Data availability

The data used in this research is available in our replication package

8
https://www.ptidej.net/downloads/replications/ist22/. at https://www.ptidej.net/downloads/replications/ist22/

14
W. Flageol et al. Information and Software Technology 160 (2023) 107222

Table 5
Language features per design patterns.
Design pattern # Features Papers # Papers
Abstract Factory 4 [S29,S11,S12,S7,S21,S20,S3] 7
Adapter 4 [S10,S12,S7,S21,S3] 5
Bridge 5 [S12,S7,S21,S3,S3] 4
Builder 6 [S12,S2,S21,S3] 4
Chain of Responsibility 4 [S12,S32,S7,S16,S21,S22,S3] 7
Command 4 [S12,S7,S21,S22,S3] 5
Composite 4 [S12,S7,S15,S2,S18,S21,S3] 7
Decorator 6 [S27,S26,S12,S32,S7,S18,S19,S21,S3] 9
Facade 4 [S12,S21,S3] 3
Factory Method 6 [S12,S7,S15,S21,S3,S5] 6
Flyweight 3 [S12,S7,S15,S21,S20,S3] 6
Interpreter 2 [S12,S7,S21] 3
Iterator 3 [S12,S7,S2,S21] 4
Mediator 3 [S11,S12,S7,S21,S3] 5
Memento 2 [S12,S7,S21] 3
Observer 9 [S9,S27,S26,S10,S11,S12,S13,S14,S7,S8,S33,S15,S17,S18,S19,S21,S22,S3,S5,S6] 20
Prototype 2 [S11,S12,S7,S21] 4
Proxy 7 [S12,S32,S7,S15,S21,S20,S3,S5] 8
Singleton 4 [S27,S12,S7,S19,S21,S22,S20,S5] 8
State 6 [S11,S12,S7,S4,S21,S22,S3] 7
Strategy 4 [S10,S11,S12,S32,S7,S16,S21,S3] 8
Template Method 4 [S12,S7,S21,S3] 4
Visitor 9 [S26,S12,S28,S30,S1,S7,S2,S18,S21,S34,S3,S23,S31] 13

Table 6
Measures by usage in papers.
Measures Type # Papers Language feature
Depth of Inheritance Tree (DIT) Quantitative 6 AOP≈
Coupling Between Components (CBC) Quantitative 5 AOP⇕
Lack of Cohesion in Operations (LCOO) Quantitative 5 AOP⇕
Lines of Code (LOC) Quantitative 5 AOP⇕, Pattern Keywords⇓
Concern Diffusion over Components (CDC) Quantitative 4 AOP⇕
Concern Diffusion over LOC (CDLOC) Quantitative 4 AOP⇕
Concern Diffusion over Operations (CDO) Quantitative 4 AOP⇕
Number of Attributes (NOA) Quantitative 4 AOP⇕
Weighted Operations per Component (WOC) Quantitative 4 AOP⇕
Reusability Qualitative 3 AOP
Composition Transparency Qualitative 2 AOP
Coupling on Intercepted Modules (CIM) Quantitative 2 AOP⊠
Duplicated Code (DC) Quantitative 2 Mixins⇓, Multiple Inheritance⇓.
AOP (qualitative)
Locality Qualitative 2 AOP
Modularity Qualitative 2 AOP
Unpluggability Qualitative 2 AOP
Weighted Operations in Module (WOM) Quantitative 2 AOP⇕
Abstract-Pattern-Reusability Qualitative 1 AOP
Binding-Reusability Qualitative 1 AOP
Cohesion Qualitative 1 AOP
Comprehension Quantitative 1 Reactive Programming≈
Correctness Quantitative 1 Reactive Programming⇑
Coupling Between Modules (CBM) Quantitative 1 AOP⊠
Coupling on Advice Execution (CAE) Quantitative 1 AOP⊠
Coupling on Field Access (CFA) Quantitative 1 AOP⊠
Coupling on Method Call (CMC) Quantitative 1 AOP⊠
Cross-cutting concerns Qualitative 1 AOP
Crosscutting Degree of an Aspect (CDA) Quantitative 1 AOP⊠
Encapsulation Qualitative 1 AOP
Execution time Quantitative 1 AOP⇑
Generalization (Inheritance) Qualitative 1 AOP
Indirection Qualitative 1 AOP
Lines of Class Code (LOCC) Quantitative 1 AOP⇓
Number of Children (NoC) Quantitative 1 AOP≈
Number of classes and relations (NOCR) Quantitative 1 Mixins⇓
Response For a Module (RFM) Quantitative 1 AOP⊠
Separation of concerns Qualitative 1 AOP
Skill floor Quantitative 1 Reactive Programming≈

Acknowledgement Appendix. Tables

Table 5 contains the reference to every study based on the design

This work was supported by the Fonds de Recherche du Québec en patterns they discuss and the number of features associated with these
Nature et Technologies (Grant No: 273582). design patterns.

15
W. Flageol et al. Information and Software Technology 160 (2023) 107222

Table 6 shows the usage of these measures by number of papers. The [23] Guido Salvaneschi, Gerold Hintz, Mira Mezini, REScala: Bridging between object-
last column cross-references which language features were measured oriented and functional style in reactive applications, in: Proceedings of the
13th International Conference on Modularity, MODULARITY ’14, Association
using the metric. For quantitative metric, a symbol follows the name
for Computing Machinery, New York, NY, USA, ISBN: 9781450327725, 2014,
of the language feature showing the presented results in the studies. pp. 25–36, http://dx.doi.org/10.1145/2577080.2577083, URL: https://doi.org/
An arrow pointing up (⇑) signifies the results showed the measure 10.1145/2577080.2577083.
increasing with usage of the language feature. An arrow pointing down [24] Ingo Maier, Martin Odersky, Higher-order reactive programming with incremen-
tal lists, in: Giuseppe Castagna (Ed.), ECOOP 2013 – Object-Oriented Program-
(⇓) shows the opposite. An approximation (≈) signifies there was no
ming, Springer Berlin Heidelberg, Berlin, Heidelberg, ISBN: 978-3-642-39038-8,
significant difference found for the measure. Finally, a crossed box (⊠) 2013, pp. 707–731.
signifies no comparison was done with a classical implementation of the [25] F.S. Løkke, Scala & Design Patterns (Master’s Thesis), University of Aarhus, 2009.
design patterns. This may be because the measure cannot be applied to [26] S. Chidamber, C. Kemerer, A metrics suite for object oriented design, IEEE Trans.
Softw. Eng. 20 (1994).
the classical implementation (e.g., Crosscutting Degree of an Aspect)
[27] M. Ceccato, P. Tonella, Measuring the effects of software aspectization, in: 1st
or because the paper used the measure to compare two non-classical Workshop on Aspect Reverse Engineering, 2004.
implementations.
Primary Studies
References
[S1] Bruno C.d.S. Oliveira, Meng Wang, Jeremy Gibbons, The visitor pattern as
a reusable, generic, type-safe component, ACM SIGPLAN Not. (ISSN: 0362-
[1] Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides, Design Patterns: 1340) 43 (10) (2008) 439–456, http://dx.doi.org/10.1145/1449955.1449799,
Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, 1558-1160. URL: https://dl.acm.org/doi/10.1145/1449955.1449799.
1994. [S2] Jeremy Gibbons, Design patterns as higher-order datatype-generic programs,
[2] Joshua Kerievsky, Refactoring to Patterns, Addison-Wesley Professional, 2004. in: Proceedings of the 2006 ACM SIGPLAN Workshop on Generic Programming
[3] Cheng Zhang, David Budgen, What do we know about the effectiveness of - WGP ’06, ACM Press, 2006, p. 1, http://dx.doi.org/10.1145/1159861.
software design patterns, IEEE Trans. Softw. Eng. 38 (2012) 1213–1231. 1159863, URL: http://portal.acm.org/citation.cfm?doid=1159861.1159863.
[4] Daniel von Dincklage, Iterators and encapsulation, in: Proceedings 33rd Inter- [S3] Ruslan Batdalov, Oksana Nikiforova, Towards easier implementation of design
national Conference on Technology of Object-Oriented Languages and Systems, patterns, in: The Eleventh International Conference on Software Engineering
2000. Advances, International Academy, Research, and Industry Association, 2016.
[S4] Kazunori Sakamoto, Hironori Washizaki, Yoshiaki Fukukaza, Extended design
[5] H. Masuhara, R. Hirschfeld, Classes as layers: Rewriting design patterns with
patterns in new object-oriented programming languages, in: Proceedings of the
COP: Alternative implementations of decorator, observer, and visitor, in: Pro-
International Conference on Software Engineering and Knowledge Engineering,
ceedings of the 8th International Workshop on Context-Oriented Programming,
Eslevier, 2013, pp. 600–605.
2016, pp. 21–26.
[S5] Rosario Giunta, Giuseppe Pappalardo, Emiliano Tramontana, Using aspects and
[6] G. Kiczales, et al., Aspect-oriented programming, in: Proceedings of the European annotations to separate application code from design patterns, in: Proceedings
Conference on Object-Oriented Programming, 1997, pp. 220–242. of the 2010 ACM Symposium on Applied Computing - SAC ’10, ACM Press,
[7] Tobias Dürschmid, Design pattern builder: a concept for refinable reusable ISBN: 978-1-60558-639-7, 2010, p. 2183, http://dx.doi.org/10.1145/1774088.
design pattern libraries, in: Companion Proceedings of the 2016 ACM SIGPLAN 1774548, URL: http://portal.acm.org/citation.cfm?doid=1774088.1774548.
International Conference on Systems, Programming, Languages and Applications: [S6] Liu Jicheng, Yin Hui, Wang Yabo, A novel implementation of observer pattern
Software for Humanity, 2016, pp. 45–46. by aspect based on Java annotation, in: 2010 3rd International Conference on
[8] Jan Hannemann, Gregor Kiczales, Design pattern implementation in Java and As- Computer Science and Information Technology, IEEE, ISBN: 978-1-4244-5537-
pectJ, in: Proceedings of the 17th ACM SIGPLAN Conference on Object-Oriented 9, 2010, pp. 284–288, http://dx.doi.org/10.1109/ICCSIT.2010.5564893, URL:
Programming, 2002, pp. 161–173. http://ieeexplore.ieee.org/document/5564893/.
[9] Khalid Aljasser, Implementing design patterns as parametric aspects using [S7] Martin Kuhlemann, Sven Apel, Marko Rosenmüller, Roberto Lopez-Herrejon,
ParaAJ, Comput. Lang. Syst. Struct. 45 (2016) 1–15. A multiparadigm study of crosscutting modularity in design patterns, in:
[10] Peter Norvig, Design patterns in dynamic programming, 1996, URL: https:// Richard F. Paige, Bertrand Meyer (Eds.), Objects, Components, Models and Pat-
norvig.com/design-patterns/design-patterns.pdf. terns, in: Lecture Notes in Business Information Processing, vol. 11, Springer
[11] Apostolos Ampatzoglou, Sofia Charalampidou, Ioannis Stamelos, Research state Berlin Heidelberg, 2008, pp. 121–140, http://dx.doi.org/10.1007/978-3-540-
of the art on GoF design patterns: A mapping study, J. Syst. Softw. (ISSN: 0164- 69824-1_8, URL: http://link.springer.com/10.1007/978-3-540-69824-1_8.
[S8] Eyvind W. Axelsen, Fredrik Sørensen, Stein Krogdahl, A reusable observer
1212) 86 (7) (2013) 1945–1964, http://dx.doi.org/10.1016/j.jss.2013.03.063,
pattern implementation using package templates, in: Proceedings of the 8th
URL: https://www.sciencedirect.com/science/article/pii/S0164121213000757.
Workshop on Aspects, Components, and Patterns for Infrastructure Software
[12] Apostolos Ampatzoglou, Sofia Charalampidou, Ioannis Stamelos, Design pattern
- ACP4IS ’09, ACM Press, ISBN: 978-1-60558-450-8, 2009, p. 37, http://dx.
alternatives: what to do when a GoF pattern fails, in: Proceedings of the
doi.org/10.1145/1509276.1509286, URL: http://portal.acm.org/citation.cfm?
17th Panhellenic Conference on Informatics - PCI ’13, ACM Press, Thessaloniki,
doid=1509276.1509286.
Greece, ISBN: 978-1-4503-1969-0, 2013, p. 122, http://dx.doi.org/10.1145/
[S9] Matthew F. Tennyson, A study of the data synchronization concern in the
2491845.2491857, URL: http://dl.acm.org/citation.cfm?doid=2491845.2491857.
Observer design pattern, in: 2010 2nd International Conference on Software
[13] L. Ferreira, C.M.F. Rubira, The reflective state pattern, in: Proceedings of the 5th Technology and Engineering, IEEE, ISBN: 978-1-4244-8667-0, 2010, 5608911,
Conference on Pattern Languages of Programs (PLOT ’98), 1998. http://dx.doi.org/10.1109/ICSTE.2010.5608911, URL: http://ieeexplore.ieee.
[14] M.E. Nordberg III, The reflective state pattern, in: Proceedings of the 3rd org/document/5608911/.
Conference on Pattern Languages of Programs (PLOT ’96), 1996. [S10] R. Teebiga, S. Senthil Velan, Comparison of applying design patterns for
[15] B. Bafandeh Mayvan, A. Rasoolzadegan, Z. Ghavidel Yazdi, The state of the art functional and non-functional design elements in Java and AspectJ programs,
on design patterns: A systematic mapping of the literature, J. Syst. Softw. (ISSN: in: 2016 International Conference on Advanced Communication Control and
01641212) 125 (2017) 93–118, http://dx.doi.org/10.1016/j.jss.2016.11.030. Computing Technologies (ICACCCT), IEEE, ISBN: 978-1-4673-9545-8, 2016,
[16] K. Peterson, S. Vakkalanka, L. Kuzniarz, Guidelines for conducting systematic pp. 751–757, http://dx.doi.org/10.1109/ICACCCT.2016.7831740, URL: http:
mapping studies in software engineering: An update, Inf. Softw. Technol. 64 //ieeexplore.ieee.org/document/7831740/.
(2015) 1–18. [S11] Cláudio Sant’Anna, Alessandro Garcia, Uirá Kulesza, Carlos Lucena, Arndt von
[17] B.A. Kitchenham, Procedures for Undertaking Systematic Reviews, Joint Techni- Staa, Design patterns as aspects: a quantitative assessment, J. Braz. Comput.
cal Report, Computer Science Department, 2004, Keele University (TR/SE-0401) Soc. (ISSN: 0104-6500) 10 (2) (2004) 42–55, http://dx.doi.org/10.1590/
and National ICT Australia Ltd. ( 0400011T.1). S0104-65002004000300004, URL: http://www.scielo.br/scielo.php?script=sci_
arttext&pid=S0104-65002004000300004&lng=en&nrm=iso&tlng=en.
[18] B. Kitchenham, S. Charters, Guidelines for Performing Systematic Literature
[S12] Jan Hannemann, Gregor Kiczales, Design pattern implementation in Java
Review in Software Engineering, Technical Report EBSE 2007-001, Keele Univ.
and aspectJ, ACM SIGPLAN Not. (ISSN: 0362-1340, 1558-1160) 37 (11)
and Durham Univ. Joint Report, 2007.
(2002) 161–173, http://dx.doi.org/10.1145/583854.582436, URL: https://dl.
[19] Elsevier, Engineering Village. URL: https://www.engineeringvillage.com/.
acm.org/doi/10.1145/583854.582436.
[20] The AspectJ Project. URL: https://www.eclipse.org/aspectj/. [S13] Tobias Dürschmid, Design pattern builder: a concept for refinable reusable
[21] PostSharp: C♯ design patterns without boilerplate. URL: https://www.postsharp. design pattern libraries, in: Companion Proceedings of the 2016 ACM SIG-
net/. PLAN International Conference on Systems, Programming, Languages and
[22] C. Chambers, B. Harrison, J. Vlissides, A debate on language and tool support for Applications: Software for Humanity, ACM, ISBN: 978-1-4503-4437-1, 2016,
design patterns, in: Proceedings of the 27th ACM SIGPLAN-SIGACT Symposium pp. 45–46, http://dx.doi.org/10.1145/2984043.2998537, URL: https://dl.acm.
on Principles of Programming Languages, 2000. org/doi/10.1145/2984043.2998537.

16
W. Flageol et al. Information and Software Technology 160 (2023) 107222

[S14] J. Borella, The observer pattern using aspect oriented programming, in: [S25] Nelio Cacho, Claudio Sant’anna, Eduardo Figueiredo, Francisco Dantas,
Proceedings of the Viking Pattern Languages of Programs, 2003. Alessandro Garcia, Thais Batista, Blending design patterns with aspects: A
[S15] Rosario Giunta, Giuseppe Pappalardo, Emiliano Tramontana, AODP: refac- quantitative study, J. Syst. Softw. (ISSN: 01641212) 98 (2014) 117–139,
toring code to provide advanced aspect-oriented modularization of design http://dx.doi.org/10.1016/j.jss.2014.08.041.
patterns, in: Proceedings of the 27th Annual ACM Symposium on Ap- [S26] Matthias Springer, Hidehiko Masuhara, Robert Hirschfeld, Classes as layers:
plied Computing - SAC ’12, ACM Press, ISBN: 978-1-4503-0857-1, 2012, p. Rewriting design patterns with COP: Alternative implementations of decorator,
1243, http://dx.doi.org/10.1145/2245276.2231971, URL: http://dl.acm.org/ observer, and visitor, in: Proceedings of the 8th International Workshop
citation.cfm?doid=2245276.2231971. on Context-Oriented Programming, ACM, ISBN: 978-1-4503-4440-1, 2016,
[S16] N. El Maghawry, A.R. Dawood, Aspect oriented GoF design patterns, in: The pp. 21–26, http://dx.doi.org/10.1145/2951965.2951968, URL: https://dl.acm.
7th International Conference on Informatics and Systems, 2010, pp. 1–7. org/doi/10.1145/2951965.2951968.
[S17] Jose M. Felix, Francisco Ortin, Aspect-oriented programming to improve [S27] Taher Ahmed Ghaleb, Khalid Aljasser, Musab A. Alturki, An extensible com-
modularity of object-oriented applications, J. Softw. (ISSN: 1796-217X) 9 (9) piler for implementing software design patterns as concise language constructs,
(2014) 2454–2460, http://dx.doi.org/10.4304/jsw.9.9.2454-2460, URL: http: Int. J. Softw. Eng. Knowl. Eng. (ISSN: 0218-1940) 31 (7) (2021) 1043–1067,
//ojs.academypublisher.com/index.php/jsw/article/view/13246. http://dx.doi.org/10.1142/S0218194021500327, 1793-6403. URL: https://
[S18] Marc Bartsch, Rachel Harrison, Design patterns with aspects: A case study, www.worldscientific.com/doi/abs/10.1142/S0218194021500327.
in: Proceedings of the 12th European Conference on Pattern Languages of [S28] Weixin Zhang, Bruno C.D.S. Oliveira, EVF: An extensible and expressive
Programs, ACM, 2007, pp. 797–810. visitor framework for programming language reuse, 2017, p. 32, http://dx.doi.
[S19] Khalid Aljasser, Implementing design patterns as parametric aspects using org/10.4230/LIPICS.ECOOP.2017.29, In collab. with Marc Herbstritt. Artwork
ParaAJ: The case of the singleton, observer, and decorator design patterns, Size: 32 pages Medium: application/pdf Publisher: Schloss Dagstuhl - Leibniz-
Comput. Lang. Syst. Struct. (ISSN: 14778424) 45 (2016) 1–15, http://dx.doi. Zentrum fuer Informatik GmbH, Wadern/Saarbruecken, Germany. URL: http:
org/10.1016/j.cl.2015.11.002. //drops.dagstuhl.de/opus/volltexte/2017/7274/. (visited on 11/01/2022).
[S20] Pavol Baca, Valentino Vranic, Replacing object-oriented design patterns with [S29] Harold Fortuin, A modern, compact implementation of the parameterized
intrinsic aspect-oriented design patterns, in: 2011 Second Eastern European factory design pattern, J. Object Technol. (ISSN: 1660-1769) 9 (1) (2010) 57,
Regional Conference on the Engineering of Computer Based Systems, IEEE, http://dx.doi.org/10.5381/jot.2010.9.1.c5, URL: http://www.jot.fm/contents/
ISBN: 978-1-4577-0683-7, 2011, pp. 19–26, http://dx.doi.org/10.1109/ECBS- issue_2010_01/column5.html.
EERC.2011.13, URL: http://ieeexplore.ieee.org/document/6037510/. [S30] Yun Mai, Michel Champlain, Reflective visitor pattern, in: European
[S21] João L. Gomes, Miguel P. Monteiro, Design pattern implementation in object Conference on Pattern Languages of Programs, ACM, 2001, pp. 299–316.
teams, in: Proceedings of the 2010 ACM Symposium on Applied Computing [S31] Bilal Hussein, Aref Mehanna, Yahia Rabih, Visitor design pattern us-
- SAC ’10, ACM Press, ISBN: 978-1-60558-639-7, 2010, p. 2119, http://dx. ing reflection mechanism, Int. J. Softw. Innov. (ISSN: 2166-7160)
doi.org/10.1145/1774088.1774534, URL: http://portal.acm.org/citation.cfm? 8 (1) (2020) 92–107, http://dx.doi.org/10.4018/IJSI.2020010106, 2166-
doid=1774088.1774534. 7179. URL: https://services.igi-global.com/resolvedoi/resolve.aspx?doi=10.
[S22] M.L. Bernardi, G.A. Di Lucca, Improving design pattern quality using aspect 4018/IJSI.2020010106.
orientation, in: 13th IEEE International Workshop on Software Technology [S32] Eden Burton, Emil Sekerinski, Using dynamic mixins to implement design
and Engineering Practice (STEP’05), IEEE, ISBN: 978-0-7695-2639-3, 2005, pp. patterns, in: Proceedings of the 19th European Conference on Pattern Lan-
206–218, http://dx.doi.org/10.1109/STEP.2005.14, URL: http://ieeexplore. guages of Programs - EuroPLoP ’14, ACM Press, ISBN: 978-1-4503-3416-7,
ieee.org/document/1691649/. 2014, pp. 1–19, http://dx.doi.org/10.1145/2721956.2721991, URL: http://dl.
[S23] Q. Hachani, D. Bardou, Using aspect-oriented programming for design pat- acm.org/citation.cfm?doid=2721956.2721991.
terns implementation, in: Workshop on Reuse in Object-Oriented Information [S33] Guido Salvaneschi, Sven Amann, Sebastian Proksch, Mira Mezini, An empirical
Systems Design, 2002. study on program comprehension with reactive programming, in: Proceed-
[S24] Alessandro Garcia, Cláudio Sant’Anna, Eduardo Figueiredo, Uirá Kulesza, ings of the 22nd ACM SIGSOFT International Symposium on Foundations
Carlos Lucena, Arndt von Staa, Modularizing design patterns with aspects: of Software Engineering, ACM, ISBN: 978-1-4503-3056-5, 2014, pp. 564–
A quantitative study, in: Awais Rashid, Mehmet Aksit (Eds.), Transactions 575, http://dx.doi.org/10.1145/2635868.2635895, URL: https://dl.acm.org/
on Aspect-Oriented Software Development I, in: Lecture Notes in Computer doi/10.1145/2635868.2635895.
Science, vol. 3880, Springer Berlin Heidelberg, 2006, pp. 36–74, http://dx.doi. [S34] Shriram Krishnamurthi, Matthias Felleisen, Daniel P. Friedman, Synthesizing
org/10.1007/11687061_2, URL: http://link.springer.com/10.1007/11687061_ object-oriented and functional design to promote re-use, in: Proceedings of the
2. 12th European Conference on Object-Oriented Programming, ACM, 1998, pp.
91–113.

17