Layers
This post is a cross-post from www.ModernesCpp.com.
The layers pattern splits a task into horizontal layers. Each layer has a specific responsibility and provides a service to a higher layer.
The Layers Pattern is an architectural pattern that helps, according to the book "Pattern-Oriented Software Architecture, Volume 1", to bring structure into the mud.
Also Known as
Context
Problem
Solution
Structure
Client
Layer J
Although not specified, most layered architectures consist of three or four layers. Each layer is independent of the other layer. In the pure version, a layer can only access its layer below. A layer can not access its upper layer because it would create additional dependencies and complicates the control structure. Additionally, another application cannot easily use a layer that depends on an upper layer. A layer often provides its functionality by implementing the Facade Pattern. The Facade Pattern provides a simplified interface to a complex system.
Examples
The Layers Pattern is heavily used since the beginning of software development. Consequentially, there are many use cases:
OSI Model and TCP/IP Model
The Open Systems Interconnection model (OSI model) is a conceptual model that 'provides a common basis for the coordination of [ISO] standards development for the purpose of systems interconnection'.[2] In the OSI reference model, the communications between a computing system are split into seven different abstraction layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application. (https://en.wikipedia.org/wiki/OSI_model)
You may also very often hear about the simplified TCP/IP model: The Internet protocol suite, commonly known as TCP/IP, is a framework for organizing the set of communication protocols used in the Internet and similar computer networks according to functional criteria. The foundational protocols in the suite are the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP). (https://en.wikipedia.org/wiki/Internet_protocol_suite)
Modernes C++ Mentoring
Embedded Systems
When developing software for embedded systems, you typically use various layers of abstraction in C++.
Extend/Embed Python in C/C++
Extending Python in C/C++ consists of the following steps:
Embedding does the same reversely. What is happening on the Python and the C layer? Here is the simplified strategy.
Recommended by LinkedIn
When you call a method on a Python type, this call goes to the C struct PyObject, defined in object.c. Inside object.c, the C function Py_TYPE deduces the object type and calls the corresponding function on the C layer. This means if the corresponding method is implemented on the deduced type this one is called. If not, the default implementation on PyObject is called if possible.
Pros and Cons
Pros
Replacement of Layers
Each layer has a specific role and specific responsibilities. It offers its services for the higher layer through an interface. The higher layer depends only on the interface of its lower layer. Consequentially, the lower layer can be easily replaced.
Testability
Each layer encapsulated its services. This makes it straightforward to test the functionality of each subsystem. More fine-granular tests, such as unit tests, must be applied inside the layers.
Development
Each layer can be implemented in isolation thanks to the separation of concern of the various layers. First, the interface of the layers has to be defined.
Cons
Granularity of Layers
It may be challenging to find the appropriate granularity of layers. Too many layers may cause layers that have only minimal responsibility. Additionally, the architecture may be very difficult to understand. Too few layers make it complicated to replace, test, and develop them in isolation.
Performance
A client call triggers a sequence of calls ending in the lowest layer. This sequence of calls may impact the performance of the application. This holds, in particular, true if layers are remote.
What's Next?
The Pipes-and-Filters Pattern is handy when you have a system that processes data in several steps, and each step should be developed independently. Let me write about it in my next post.
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Dominik Vošček, and Rob North.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, and Slavko Radman.
My special thanks to Embarcadero, PVS-Studio, and Tipi.build.
Seminars
I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
Bookable (Online)
German
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
New
Contact Me