Design or Architecture Pattern?
The difference of design and architectural pattern in Software Engineering.
This is a steep learning curve. Before you read this article, if you don’t know about design patterns or architecture patterns (in software engineering), I suggest you search some basic references in advance from the Internet, such as Wikipedia.
TL DR;
The design pattern is a term referring to common solutions that be used to solving common problems that occur in certain contexts. Concerned with the (further small) components of a subsystem with their relationships and collaborations with each other. For example, this will help you to solve the problem that you get while creating an algorithm. And you just apply the design pattern that only suitable for your problem.
While architecture pattern in software development is a term for reusable solutions to commonly occurring problems in software architecture. Concerned with the subsystems of an application with their relationships and collaborations with each other. For example, this will help you do decide what structure is fit for your application or create an optimal workflow for your application project.
The Confusion
Many programmers nowadays still confused about the difference between design patterns and architecture patterns, or don’t even know much about it. Like a few hours ago before I decided to write this post, my friend debating with me about the famous MVC (Model View Controller) is a design pattern in his opinion. I’ve tried to explain to him as clear as possible and refer him to some site reference that explains MVC is more like to be an architectural pattern. Then, he replied to me with a link from GeeksforGeeks that states MVC is a design pattern.
In the first paragraph, GeeksforGeeks’s article said that
The Model View Controller (MVC) design pattern specifies that an application consist of a data model, presentation information, and control information. The pattern requires that each of these be separated into different objects.
But in the second paragraph,
MVC is more of an architectural pattern, but not for complete application. MVC mostly relates to the UI or interaction layer of an application. You’re still going to need business logic layer, maybe some service layer and data access layer.
Later then, I asked my friend,
“did you know the differences of them, the design and architecture pattern?”,
“of course no, please explain to me”
Ah sh*t, here we go again…
The Pattern of Design
Let me start with the definition. Design patterns are typical solutions to commonly occurring problems in software design, or in another word, is to help you solve a problem that sometimes you meet when you do programming. They are like pre-made blueprints that you can customize to solve a recurring design problem in your code.
Design patterns are distilled commonality that you find in programs. It allows us to deconstruct a large complex structure and build using simple parts. It provides a general solution for a class of problems — pyfunc
This kind of pattern is like your cooking recipe to let you know how to cook some food. But in reality, people’s tastes vary so to use the recipe you must be adapted to the needs of ingredients and the situation.
The patterns that have been built are formulated in such a way as to find the best way to solve the problem, but still, the programmer must apply the patterns with an approach that is appropriate to the context of the problem being experienced, by adjusting to the needs.
There are 3 classifications of design patterns.
- Creational patterns
to provide object creation mechanisms that increase flexibility and reuse of existing code. Types: Abstract Factory, Builder, Factory Method, Object Pool, Prototype, Singleton. - Structural patterns
to explain how to assemble objects and classes into larger structures, while keeping the structures flexible and efficient. Types: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Private Class Data, Proxy. - Behavioral patterns
to take care of effective communication and the assignment of responsibilities between objects. Types: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Strategy, Template Method, Visitor.
The total amount of design patterns that now existed is 26.
“Oh crap, that’s too many for complex things like this..”
Yup. that’s true. But the point is, you don’t need to know all these crappy things. This pattern of design is only applied based on your use case.
“Okay, I got the theory. But why these complex design patterns have ever existed?. What the point of this all?. And do I need to learn this?.”
The truth is that you might manage to work as a programmer for many years without knowing about a single design pattern. A lot of people do just that. Even in that case, though, you might be implementing some patterns without even knowing it. So why would you spend time learning them?.
- Design patterns are a toolkit of tried and tested solutions to common problems in software design. Even if you never encounter these problems, knowing patterns is still useful because it teaches you how to solve all sorts of problems using principles of object-oriented design.
- Design patterns define a common language that you and your teammates can use to communicate more efficiently. You can say, “Oh, just use a Singleton for that.” and everyone will understand the idea behind your suggestion. No need to explain what a singleton is if you know the pattern and its name.
Design patterns say how to write code effectively, easy maintainable, high re-usability, and of course readable because of abstraction — vrluckyin
“Oh I see.., but can you give me some example please?.”
I’ll give you some basic example with one of my favorite pattern,
The Observer Pattern
The observer is one of the design patterns in behavioral classification. To simplify, this pattern has 2 main components, the observer and observable. An observer is an object that observes an observable, while observable is responsible to send information (notify) the observer.
The action that the observer do to connect to the observable is called subscription. And observable only can send information to observer that already been subscribed to him.
This is a type of one-to-many relationship. Why? because one observable can have many observers and can send information (notify) to them.
The observer pattern is a perfect solution if you need an algorithm or service that can fetch data in real-time or listen to a data change from your server. Take an example of the Weather App that needs to monitor weather in Jakarta, Indonesia.
You will need a WeatherObservable to fetch data from a server in some of the time intervals, and notify the data to WeatherObserver that already been subscribed.
Talk is cheap, show me the code
Take a look at the example below, I’ve written it in Kotlin language.
First of all, we declare the interface for observable and observer. BaseObservable is implemented with 2 functions, subscribe for the observer to get subscribed, and the update to broadcast data change to the observer. While BaseObserver has only 1 notify function to get data (notification) from observable.
Then we create the observable object that implements the BaseObservable interface. We also declare an array list to save the observer that already subscribed.
Finally, we declare the observer.
This code is ready, and when the function:
WeatherObservable.refresh()is called somewhere in the code, our observable will broadcast the data change from server to all observer that already subscribed. Simple right?
Enough for design, let’s start the architecture.
The Pattern of Architecture
Architecture pattern is like an abstract explanation about how you structure your application. According to Wikipedia,
An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context. Architectural patterns are similar to software design patterns but have a broader scope.
These are patterns for the overall layout of your application or applications. They all have advantages and disadvantages.
Many architectural patterns exist out there, you can see the list on Wikipedia. But, I’ll mention the 10 of common architectures:
- Layered pattern
- Client-server pattern
- Master-slave pattern
- Pipe-filter pattern
- Broker pattern
- Peer-to-peer pattern
- Event-bus pattern
- Model-view-controller pattern
- Blackboard pattern
- Interpreter pattern
These patterns are already explained in detail here:
Design vs Architecture
In general (switch off your inner programmer for some time) the architecture and design both explains the “idea” but Architecture focuses on the abstract view of the idea while Design focuses on the implementation view of the idea. Design is much more detailed than architecture.
Architecture pictures the abstract view of the whole system while Design pictures the implementation of some specific concerned domain.
Suppose the government wants to build a new city. First, they will create a high-level abstract diagram explaining where will be the housing area, there will be factory areas, where parks should be located, where to locate grid systems, hospitals, schools, markets and so on. This is Architecture. Now after that, they will create diagrams explaining how houses are built, how much maximum area a single house can have. How to build houses side by side. How much wider the school front would be. How many beds and rooms the hospital would have, etc. This is Design.
Now come back to programming, an Architecture explains components and their interaction while a design explains how each component is built or would be built. So there are architecture patterns and there are design patterns and both of them are different.
From here, I hope you can see the difference between design and architectural patterns.
References
- https://wikipedia.org
- https://refactoring.guru
- https://sourcemaking.com
- https://stackoverflow.com
- https://towardsdatascience.com
- https://www.linkedin.com
- https://www.swview.org
- https://blog.ndepend.com
Special thanks to Panditya, the one who let me know the basics of this stuff and Dhevan for debating about the pattern.
Do you want me to explain each single design pattern or explain more detail about this topic in the next post? please leave a comment below :)
Any criticism or suggestion is welcomed.
