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
- N-tier architecture pattern
- Large systems requiring disassembly
- A system that performs operations at different levels
- Higher levels use lower levels
- Structure the system in layers
- Services of a higher layer are based on the services of the lower layers
- Accesses the top level
- Encapsulates the specific role and responsibility of layer J
- Offers its services with the help of layer J -1
- Can only access layer J – 1
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.
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’. 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)
Chunte7, CC BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0>, via Wikimedia Commons
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)
When developing software for embedded systems, you typically use various layers of abstraction in C++.
- You typically start with the board support package (BSP). The BSP contains board-specific configurations, such as boot firmware and device drivers, so the embedded operating system can work.
- The hardware abstraction layer (HAL) sits on top of the BSP. The HAL is an abstraction layer between the hardware and the software that runs on the embedded system. Its function is to hide differences in hardware from the operating system.
Extend/Embed Python in C/C++
Extending Python in C/C++ consists of the following steps:
- Convert the values from Python to C/C++.
- Use the converted values to execute the C/C++ functionality.
- Convert the results from C/C++ to Python.
Embedding does the same reversely. What is happening on the Python and the C layer? Here is the simplified strategy.
- All Python types, such as
int, inherit from
- The C pendant to the data type object is the C struct
PyObject. C is not object-oriented.
PyObjectis a kind of the starting point of the Python object’s memory. You can study its implementation on GitHub:
PyObjectessentially has a reference counter and a pointer to the corresponding type.
When you call a method on a Python type, this call goes to the C struct
PyObject, defined in
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
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.
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.
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.
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.
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.
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, 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, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, and Philipp Lenk.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.
|My special thanks to Embarcadero|
|My special thanks to PVS-Studio|
|My special thanks to Tipi.build|
|My special thanks to Take Up Code|
|My special thanks to SHAVEDYAKS|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ – The Core Language
- C++ – The Standard Library
- C++ – Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,