Layers

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

Context

Large systems requiring disassembly

Problem

A system that performs operations at different levels
Higher levels use lower levels

Solution

Structure the system in layers
Services of a higher layer are based on the services of the lower layers

Structure

Client

Accesses the top level

Layer J

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.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

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)

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)

Embedded Systems

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 object.

The C pendant to the data type object is the C struct PyObject. C is not object-oriented. PyObject is a kind of the starting point of the Python object’s memory. You can study its implementation on GitHub: object.c. PyObject essentially 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. 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.

Post Views: 3,352

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, 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, Stephen Kelley, Kyle Dean, Tusar Palauri, 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, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery,and Matt Godbolt.

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