2019 IEEE/ACM 41st International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-

NIER)

Current Challenges in
Practical Object-Oriented Software Design
Maurı́cio Aniche Joseph W. Yoder Fabio Kon
Delft University of Technology The Refactory, Inc. University of São Paulo
Delft, The Netherlands Urbana, USA São Paulo, Brazil
m.f.aniche@tudelft.nl joe@refactory.com kon@ime.usp.br

Abstract—According to the extensive 50-year-old body of From the beginning, modeling meant that the actions and
knowledge in object-oriented programming and design, good interactions of the objects that the program created (imple-
software designs are, among other characteristics, lowly coupled, mented in an object-oriented language) represent the actions
highly cohesive, extensible, comprehensible, and not fragile.
However, with the increased complexity and heterogeneity of and interactions of the corresponding real-world physical (or
contemporary software, this might not be enough. virtual) objects [4]. The goal is to model the real-world
This paper discusses the practical challenges of object-oriented scenario through objects and interactions to represent the
design in modern software development. We focus on three main domain as best as possible. Clearly, more complex real-world
challenges: (1) how technologies, frameworks, and architectures scenarios are more challenging to be modeled into a set of
pressure developers to make design decisions that they would
not take in an ideal scenario, (2) the complexity of current real- classes.
world problems require developers to devise not only a single, Parnas introduced the concept of information hiding in
but several models for the same problem that live and interact modular programming in his 1972 seminal paper “On the
together, and (3) how existing quality assessment techniques for Criteria to Be Used in Decomposing Systems into Modules”
object-oriented design should go beyond high-level metrics. [31]; a concept related to what later was referred to as high
Finally, we propose an agenda for future research that should
be tackled by both scientists and practitioners soon. This paper is
cohesion and loose coupling. In his “The Mythical Man-
a call for arms for more reality-oriented research on the object- Month: Essays on Software Engineering” from 1975, Brooks
oriented software design field. brought the attention to the importance of conceptual integrity
Index Terms—software design, class design, object-oriented in software design with the idea that there should be one mind
design, domain modeling, software engineering, software archi- (or a small, cohesive team) that designs the architecture of the
tecture, object-oriented programming.
system in a consistent and well-thought way [7].
Meyer [27], in his canonical “Object-Oriented Software
I. I NTRODUCTION
Construction” book, discussed several techniques to make
The term “object” in programming dates back from the early reusable, extensible, and maintainable object-oriented design.
1960s, appearing in several MIT projects at that time, such as The Gang of Four [18] proposed a large set of design patterns
Sketchpad [34]. The first programming language to introduce that help developers when looking for elegant solutions to
the concept as a core element was Simula, which introduced recurrent (creational, structural, and behavioral) and reusable
concepts such as classes, objects, inheritance, polymorphism, object-oriented design systems. Rumbaugh, Booch, and Jacob-
and dynamic binding in the late 1960s [11]. son [32] proposed the Unified Modeling Language (UML),
Since then, we have seen the birth of several languages who which the goal was to provide a general-purpose language to
followed OOP ideas in one way or another, such as Smalltalk, aid software developers and business stakeholders throughout
C++, Java, C#, JavaScript, Ruby, and Scala. 50 years later, the modeling process. Martin collected the five most crucial
OOP languages became prevalent in the software development object-oriented design principles, according to his experience,
field, as 7 out of the 10 most popular programming languages in his renowned paper “Design Principles and Design Patterns”
can be considered an object-oriented language (TIOBE index, [24], which later were known as the SOLID principles.
September 2018, https://www.tiobe.com/tiobe-index). Freeman and Pryce [17] presented their views on how test
One might see an object as something that has identity, state, code and, more specifically, mock objects, can help developers
and behavior [29]. In other words, objects can be distinguished in understanding and better defining their class contracts,
from one another based on its unique identity. Also every and how they should collaborate. Evans [13] suggested that
object holds a set of mutable variables that, together, represent developers should work together with domain experts putting
its current state. Finally objects communicate and trigger all their emphasis on modeling the system core domain and
different behaviors, one to another by sending messages or the associated domain problems, and proposed several patterns
functions. to help developers on such activity which he called Domain
The OOP movement made it clear for software engineers Driven Design (DDD).
that modeling is an integral part of software development. Due to the joint effort and complementary work of industry

978-1-7281-1758-4/19/$31.00 ©2019 IEEE 113

DOI 10.1109/ICSE-NIER.2019.00037
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY ROORKEE. Downloaded on August 07,2023 at 17:49:57 UTC from IEEE Xplore. Restrictions apply.
 and research, our community believes it has a clear vision Sun proposed the Core Java EE catalogue [1], a set of patterns
about what an object-oriented software design that is main- that developers would have to follow to make better use of
tainable, evolvable, and comprehensible should look like. its technology. Thus, to better use EJB, developers often had
Or so we think. Although our body of knowledge on to mix their object-oriented models with patterns like the
software design is already extensive and significant, modern “Transfer Object” pattern (an object that groups many objects)
software brings modern challenges. In the following sections, or the “Business Object” pattern (to separate business logic
we describe three timely challenges we see in modern software from data), even though they may not have wanted to.
design. We summarize the challenges below: We see the influence of the technology stack in most modern
1) The strong influence of libraries and frameworks on the web and mobile software systems. In mobile development,
design decisions. Developers never start software from the Android architecture imposes several restrictions to de-
scratch. Instead, they reuse several libraries, frameworks, velopers, e.g., to implement Activities for each of the user
and out-of-the-box architectures not only to speed up their interfaces (screens) of the app, or to create Listeners for
development, but also to support their different functional background tasks. This means that developers should find a
and non-functional requirements. These libraries, frame- way to plug their models into the constraints that are imposed
works, and architectures often force developers to change by the architecture. Modern web systems are often designed
the way they implement their models in object-oriented in a stateless manner. This means that developers, whenever
languages. implementing their models in web systems should consider
2) The plethora of stakeholders and their different represen- the fact that objects will have a very short life cycle, and that
tations of the same problem. Software becomes more and retrieving and storing them will be a common task.
more complex as our businesses become more and more Even deciding how to persist data might pressure developers
complex. The same software has multiple stakeholders in taking certain design decisions that otherwise would not be
whom all have their perspectives on the business flow. needed. As a concrete example, the simple usage of an Object-
Software supports multiple final users, which also have Relation Mapping (ORM) framework (a framework that takes
their specific requirements. In practice, this means that a care of database access by mapping objects to tables such as
single model representation of the real-world problem is Hibernate) forces developers to re-think about modeling bi-
not enough anymore. directional relationships in entities (e.g., an Invoice class has
3) The need for contextual quality measurements. Measuring a list of Items, and each Item class has a pointer to the Invoice
the quality of a class design is fundamental in supporting they belong).
developers to decide where to improve. Currently, de- Finally, software systems are now highly heterogeneous and
velopers often do not trust on existing automated design possibly distributed over several microservices. This means
analysis tools as they generate too many false positives. that the domain could be implemented by means of several
We argue that a plausible cause for this problem is that different programming languages and technologies, deployed
our approaches currently do not take the context of the in different places, and changes in part of the domain that
system into account. is implemented in language (and/or) service A needs to be
propagated to the part of the domain that is implemented
II. T HE IMPACT OF SOFTWARE ARCHITECTURE AND in language/service B. Although using the microservices ar-
TECHNOLOGY STACKS ON SOFTWARE DESIGN chitectural style with continuous delivery and DevOps [20]
Context: Today, no software development team starts de- can help with coupling and other related issues, tracing and
veloping software from scratch. Different libraries and frame- evolving the model that is spread across different technologies
works are chosen for different parts of the system. A software and services can be challenging.
development team might choose to follow the MVC pattern for Current solutions: To address the challenges above, practi-
the back-end server, use Hibernate as a framework for database tioners have been extensively proposing developers to separate
persistence, and AngularJS for the front-end development. Ad- as much as possible the implementation of the domain itself
ditionally, programming languages provide many libraries to from requirements of the application (e.g., databases, Android
be used during development. However, the underlying software APIs). Several patterns and approaches follow this idea, such
architecture and technology stacks a software development as Ports and Adapters (Hexagonal Architecture) architectural
team chooses as the basis for their implementation plays a pattern [10], layered architectures and bounded contexts [13],
fundamental role in the way developers design and implement and interface discovery [17].
their object-oriented models. In other words, these technology Vision for the future: We need software design imple-
decisions will influence developers to follow a series of design mentation theories that acknowledge the fact that modern
decisions. In fact, in this paper, we argue that they often exert software is often heterogeneous, distributed, and composed
such a strong influence that developers currently cannot model by a large set of different frameworks and libraries. Each
without keeping them in mind. common architecture needs to be carefully studied, and their
A clear example of how technology impacts design decision positive and negative impact on design explored. Our extensive
relies on the history of Java Enterprise Edition (JavaEE) itself. background on modularization and separation of concerns
Together with the EJB technology (Enterprise Java Beans), should serve as a basis.

114

Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY ROORKEE. Downloaded on August 07,2023 at 17:49:57 UTC from IEEE Xplore. Restrictions apply.
 III. M ULTIPLE MODELS IN LARGE COMPLEX DOMAINS the same aspect is now represented over multiple classes?1
Theories explaining such questions are a fundamental step
Context: Complex real-world domains often involve com-
towards building guidelines and approaches that can help
plex business flow operations related to several stakeholders.
developers in coping with such complexity. We see it as a call
Different stakeholders might see the same business process
for collaboration between software engineers and requirements
differently from another, and both are probably correct. As
engineering researchers.
an example, an Invoice might represent something simple for
the Sales department, but may play a significant role for the IV. C ONTEXTUALLY MEASURING THE QUALITY OF
Payment department. An Address might be a simple detail for OBJECT- ORIENTED SOFTWARE DESIGN
the Payment department, but might play a major role in the
Delivery department. Context: In a large model, it is fundamentally important
to be able to detect pieces that are (not) well designed or
Time also plays a vital role in complex models. Often,
implemented. However, an important (and hard) question is:
we observe businesses being “event-driven”, meaning that
what constitutes a “good model”? So far, our community
the next state of the system is based on events that happen
has been relying on proxies, such as coupling, cohesion,
asynchronously. A large payment system should wait for a
and complexity [9], i.e., classes that are highly coupled or
credit card company to confirm the payment before proceeding
not cohesive are normally considered poorly designed OO
to the next steps. The shipping of a product only starts after the
classes. Code smells are also a common way to point to
inventory system processes it properly and allows the system
bad implementations, e.g., a God Class is a poorly designed
to continue with the delivery.
class. The simplicity of Code Smells make them both easily
These different “views” on the same problem forces de-
understood by developers and automatically detectable by
velopers to develop several different representations of the
tools.
model. In practice, this means that developers should not only
While multiple studies have shown the negative impact
model the main entities and their actions through different
of such code smells in software systems (e.g., [6], [28])
perspectives, but they should also model business events and
and developers have been using quality measurement tools
how these events change the current state of the model.
(e.g., Sonar), our current metrics fail to capture the context
Current solutions: Evans’ Domain-Driven Design ap-
(architectural-wise or domain-wise) of that software system.
proach [13] proposes a set of strategic design patterns that help
There are no single truths in software design. A class might
developers in dividing large models into different “Bounded
have a high coupling, and still be considered a well-designed
Contexts”, and to build a “Context Map” that explicitly shows
class. As a concrete example, developers already expect their
the relationships between the different contexts. We also
Controller classes in an MVC system to be more coupled than
observe the rise of Event-Driven Architectures [16], [5], where
the rest; after all, Controllers are the bridge between the user
developers explicitly deal with domain events.
interface and the model.
Researchers are also aware that modeling real-world do-
Understanding in which context a measurement makes sense
mains is a fundamental activity in requirements engineer-
and, more importantly, in which context a measurement does
ing [30] and that modeling large complex systems are, in-
not make sense is fundamental in our quest for high-quality
deed, an open challenge [8]. Empiricists have been studying
object-oriented software design. In this paper, we conjecture
how developers perform requirements engineering in prac-
that an important cause for the large number of false posi-
tice (e.g., [14]), the advantages and disadvantages of using
tives that static analysis and code quality measurement tools
modeling languages such as UML (e.g., [15], [33]), and how
currently generate [21] is their lack of context.
different modeling tools (e.g., [12]) and techniques (e.g., [25])
Current solutions: Taking into consideration the domain
perform.
and the architecture of the system under study has been gaining
More recently, developers have been proposing microser- attention from the community in the last years. Although lin-
vices as a possible alternative to reduce the complexity and ters are widely used [35], [36], and quality monitoring strate-
the coupling between their systems and specific technologies. gies such as Continuous Inspection have been proposed [26],
In essence, we see the idea of modularization [31] being researchers have shown that the domain of the application
discussed by developers from different perspectives. matters when it comes to the presence of code smells [22],
Vision for the future: We lack a clear understanding of that code metric distributions are statistically different among
how complex real-world business processes are and should be the different architectural roles of classes in a system [3], [23],
modeled. Moreover, we lack an understanding of how multiple and that specific architectures may have their own specific
models interact, evolve, and are maintained together, not only smells [2], [19].
from an abstract level, but also from the implementation point Besides, recent research on Technical Debt has shown that
of view. awareness of technical debt influences team behavior. De-
How (and how much) can developers reuse the implementa-
1 Not to mention that object-orientation might not be the best tool to model
tion from one model to the other? How much can one model
certain types of systems and processes. For example, functions might be
(or should) be coupled with another model without causing a better fit in some cases. The recent rise of functional programming and
any harm? How to interpret the notion of cohesion when serverless architectures demonstrates the power of such paradigms.

115

Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY ROORKEE. Downloaded on August 07,2023 at 17:49:57 UTC from IEEE Xplore. Restrictions apply.
 veloping better ways of identifying, monitoring, categorizing, [13] E. Evans. Domain-driven design: tackling complexity in the heart of
software. Addison-Wesley Professional, 2004.
measuring, prioritizing, and paying off the technical debt can
[14] D. M. Fernández and S. Wagner. Naming the pain in requirements
significantly improve software development practices [37]. engineering: A design for a global family of surveys and first results
Vision for the future: We need empirically derived theories from germany. Information and Software Technology, 57:616–643, 2015.
on what are the characteristics of complex models that should [15] A. M. Fernández-Sáez, M. Genero, D. Caivano, and M. R. Chaudron.
Does the level of detail of uml diagrams affect the maintainability of
be considered of high quality and in which context, as well source code?: a family of experiments. Empirical Software Engineering,
as numeric ways to measure such characteristics. Machine 21(1):212–259, 2016.
learning and data science may play an essential role in the [16] M. Fowler. Martin fowler bliki. https://martinfowler.com/bliki, 2003.
Entries: AnemicDomainModel, DomainEvent.
field, given the fact that many design characteristics might be [17] S. Freeman and N. Pryce. Growing object-oriented software, guided by
determined only by complex combinations of different quality tests. Pearson Education, 2009.
attributes. We conjecture that such theories and approaches [18] E. Gamma. Design patterns: elements of reusable object-oriented
software. Pearson Education India, 1995.
will support, once and for all, the development of quality
[19] G. Hecht, R. Rouvoy, N. Moha, and L. Duchien. Detecting antipatterns
assessment tools that produce less false positives. in android apps. In 2015 2nd ACM International Conference on Mobile
Software Engineering and Systems, pages 148–149, May 2015.
V. C ONCLUSIONS [20] J. Humble and D. Farley. Continuous delivery: reliable software
Software becomes more and more complex as the real releases through build, test, and deployment automation. Addison-
Wesley Boston, 2011.
world gets more and more complex. To cope with it, software [21] B. Johnson, Y. Song, E. Murphy-Hill, and R. Bowdidge. Why don’t
engineers require better modeling techniques. In this paper, software developers use static analysis tools to find bugs? In 2013 35th
we highlighted several challenges faced by contemporary International Conference on Software Engineering (ICSE), pages 672–
681. IEEE, 2013.
developers when modeling object-oriented systems. [22] M. Linares-Vásquez, S. Klock, C. McMillan, A. Sabané, D. Poshyvanyk,
We hope this paper serves as a reminder to the software and Y.-G. Guéhéneuc. Domain matters: bringing further evidence of
engineering community about the importance of good object- the relationships among anti-patterns, application domains, and quality-
related metrics in java mobile apps. In Proceedings of the 22nd
oriented software design in the daily life of a software en- International Conference on Program Comprehension, pages 232–243.
gineer. Although a vast amount of knowledge on the topic ACM, 2014.
has already been produced, there is still a long road ahead. [23] B. d. S. Marcos Dosea, Claudio Sant’Anna. How do design decisions
influence the distribution of software metrics? In Proceedings of the
It is fundamental that the real-life experience of practitioners 2018 International Conference on Program Comprehension, 2018.
influences the work of researchers in the field. The software [24] R. C. Martin. Design Principles and Design Patterns. Technical report,
engineering research community must still bring context into Object Mentor, 2000.
the picture, providing more comprehensive theories and better [25] J. Mendling, H. A. Reijers, and J. Recker. Activity labeling in
process modeling: Empirical insights and recommendations. Information
tools for developers to model and assess their models. Systems, 35(4):467–482, 2010.
[26] P. Merson, A. Aguiar, E. Guerra, and J. Yoder. Continuous inspection:
R EFERENCES a pattern for keeping your code healthy and aligned to the architecture.
[1] D. Alur, D. Malks, J. Crupi, G. Booch, and M. Fowler. Core J2EE In 3rd Asian Conf. on Pattern Languages of Programs, 2014.
Patterns (Core Design Series): Best Practices and Design Strategies. [27] B. Meyer. Object-oriented software construction, volume 2. Prentice
Sun Microsystems, Inc., 2003. hall New York, 1988.
[2] M. Aniche, G. Bavota, C. Treude, M. A. Gerosa, and A. van Deursen. [28] N. Moha, Y.-G. Gueheneuc, L. Duchien, and A.-F. Le Meur. Decor: A
Code smells for model-view-controller architectures. Empirical Software method for the specification and detection of code and design smells.
Engineering, pages 1–37, 9 2017. IEEE Transactions on Software Engineering, 36(1):20–36, 2010.
[3] M. Aniche, C. Treude, A. Zaidman, A. van Deursen, and M. A. [29] J. Noble. The myths of object-orientation. In European Conference on
Gerosa. SATT: Tailoring code metric thresholds for different software Object-Oriented Programming, pages 619–629. Springer, 2009.
architectures. In Source Code Analysis and Manipulation (SCAM), 2016 [30] B. Nuseibeh and S. Easterbrook. Requirements engineering: a roadmap.
IEEE 16th International Working Conference on, 2016. In Proceedings of the Conference on the Future of Software Engineering,
[4] A. P. Black. Object-oriented programming: Some history, and challenges pages 35–46. ACM, 2000.
for the next fifty years. Information and Computation, 231:3–20, 2013. [31] D. L. Parnas. On the criteria to be used in decomposing systems into
[5] A. Brandolini. Event storming. http://eventstorming.com/, 2018. modules. Communications of the ACM, 15(12):1053–1058, Dec. 1972.
[6] L. C. Briand, J. Daly, V. Porter, and J. Wüst. Predicting fault-prone [32] J. Rumbaugh, G. Booch, and I. Jacobson. The unified modeling language
classes with design measures in object-oriented systems. In Software reference manual. Addison Wesley, 1999.
Reliability Engineering. Proceedings. The Ninth Intl. Symposium on. [33] G. Scanniello, C. Gravino, M. Genero, J. A. Cruz-Lemus, G. Tortora,
IEEE, 1998. M. Risi, and G. Dodero. Do software models based on the uml aid in
[7] F. P. Brooks, Jr. The Mythical Man-month. Addison-Wesley, Boston, source-code comprehensibility? aggregating evidence from 12 controlled
MA, USA, 1975. experiments. Empirical Software Engineering, pages 1–39, 2018.
[8] B. H. Cheng and J. M. Atlee. Research directions in requirements [34] I. E. Sutherland. Sketchpad: A man-machine graphical communication
engineering. In 2007 Future of Software Engineering, pages 285–303. system. In Proceedings of the AFIPS Spring Joint Computer Conference,
IEEE Computer Society, 2007. pages 329–346. ACM, 1963.
[9] S. R. Chidamber and C. F. Kemerer. A metrics suite for object oriented [35] K. F. Tómasdóttir, M. Aniche, and A. van Deursen. Why and how
design. Software Engineering, IEEE Transactions on, 20(6), 1994. javascript developers use linters. In Automated Software Engineering
[10] A. Cockburn. Ports and adapters architecture. (ASE), 2017 32nd IEEE/ACM International Conference on, 2017.
http://alistair.cockburn.us/Hexagonal+architecture, 2009. [36] K. F. Tómasdóttir, M. Aniche, and A. Van Deursen. The adoption of
[11] O.-J. Dahl. The birth of object orientation: the simula languages. In javascript linters in practice: A case study on eslint. IEEE Transactions
From Object-Orientation to Formal Methods, pages 15–25. Springer, on Software Engineering, 2018.
2004. [37] G. S. Tonin. Technical Debt Management in the Context of Agile
[12] J. M. C. de Gea, J. Nicolás, J. L. F. Alemán, A. Toval, C. Ebert, and Methods in Software Development. PhD thesis, University of São Paulo,
A. Vizcaı́no. Requirements engineering tools. IEEE software, 28(4):86– 2018.
91, 2011.

116

Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY ROORKEE. Downloaded on August 07,2023 at 17:49:57 UTC from IEEE Xplore. Restrictions apply.