We often see the terms “Architectural Style”, “Architectural Pattern”, “Design Pattern” and “Programming Idiom”. What do they mean? What are the differences between them?
Architectural Styles
An architectural style is a high-level conceptual view of how the system will be created, organised and/or operated.
Architectural styles tell us in very broad terms how to organise our code. This is the highest level of granularity. A style describes the high-level modules and layers of the application, and how those modules and layers interact with each other.
Examples of architectural styles include:
- Monolithic
- Client-server
- Component-based
- Layered
- Pipes and filters
- Event-driven
- Publish-subscribe
- Plug-ins
- Service-oriented
- Resource-oriented
- Microservices
An architectural style is abstract and is more of a conceptual solution to a recurrent architectural design. It doesn’t exist to “solve” a problem. For example, client-server and service-oriented don’t solve any specific problems. They just specify a way of organizing the code at a very high level.
Architectural Patterns
A pattern is an elegant solution to a recurring problem. Architectural patterns solve the problems related to the architectural style. An architectural pattern describes a solution for implementing an architectural style at the level of subsystems or modules, and their inter-relationships.
An architectural pattern is a way of solving a recurring architectural problem. For example, MVC solves the problem of separating the UI from the model. The Sensor-Controller-Actuator pattern solves the problem of driving actuators from input sensors. The controller receives a signal from a sensor, decides what action is needed and then sends a signal to the actuator to operate.
Architectural patterns have a significant impact on the code base. They affect the whole application either horizontally (i.e. how to structure the code inside a layer) or vertically (i.e. how a request is processed between outer and inner layers).
An architectural pattern is concrete, i.e. it is an implementation of an architectural style. Examples of architectural patterns include:
- Three-tier
- N-tier
- Microkernel
- Model-View-Controller
- Model-View-Presenter
Design Patterns
Design patterns differ from architectural patterns in their scope. They are more localised, they have less impact on the entire code base, and they only affect a specific section of the code base, sometimes even limited to a single class.
A design pattern is a general reusable solution to a commonly occurring problem in software design. For example:
-
How do we instantiate an object when we only know what type needs to be instantiated at run time? A Factory pattern could be used to do this.
-
How do we make sure that there is only one instance of an object in the system? We would use the Singleton pattern for this.
-
How do we make an object behave differently based on its state? Either the State pattern or the Strategy pattern could help us at this point.
Programming Idioms
Programming idioms are low-level design patterns specific to a particular programming language. An idiom describes how to solve implementation-specific problems using the features of that language, such as memory management in C++. Idioms use particular language features or work around specific language limitations.
This is in contrast to design patterns which address general design principles. Design patterns are not specific to any language, and are ideally language independent.
There isn’t an absolute dividing line between programming idioms and design patterns. Idioms represent low-level solutions specific to a programming language. Design patterns represent high-level language-independent solutions to common programming problems. Idioms often directly address the concrete implementation of a design pattern in a specific language.
Another difference between an idiom and a pattern is size. An idiom is generally small, like “use an interface type for a collection variable”, while patterns tend to represent larger solutions.
Summary
The key difference between an architectural style and an architectural pattern is the scope. A single architecture can contain several architectural styles, and each architectural style can make use of several architectural patterns.
Architectural patterns and design patterns are similar, but differ from each other by the level of granularity at which they are applied. Architectural patterns have broader scope than design patterns.
To repeat, it’s all about the scope:
- An architectural style is how we design the application at the highest level of abstraction.
- An architectural pattern is how we implement the chosen architectural style.
- A design pattern is an elegant way to solve a localised problem.
- A programming idiom is a language specific way to solve an implementation-specific problem using the features of that programming language.
A pattern might even be able to be used both as an architectural pattern or a design pattern. This will depend on the scope in which we use it in a specific project. Remember that a pattern should be used only when absolutely necessary. We must never just use a pattern for the sake of using a pattern.
Architectural styles, architectural patterns, design patterns and programming idioms are not mutually exclusive. They are complementary and they can all teach us something about software design and implementation.
Was this interesting? Please share your comments and as always, stay safe and keep learning!