.NET Framework .NET C# VB.NET LINQ ASP.NET Web API REST SignalR Windows Forms WPF WCF RabbitMQ PHP SQL Server MySQL PostgreSQL MariaDB SQLite MongoDB ADO.NET ORM Entity Framework Dapper XML JSON HTML5 CSS3 Bootstrap JavaScript jQuery Angular React TypeScript NPM Blazor UI/UX Responsive Web Design Redis Elasticsearch GraphQL Grafana Agile Scrum Kanban Windows Server IIS PowerShell Active Directory TFS Azure Automation Software Reverse Engineering Performance Optimization Git Jira/Confluence CI/CD TeamCity SOLID KISS DRY YAGNI
Always will be ready notify the world about expectations as easy as possible: job change page

Design Patterns VS Design Principles

Добавлено: Jul 23, 2023
Автор: Kenji Elzerman
Источник: источник
Просмотров: 262

Design Patterns VS Design Principles

I wrote a few articles about design patterns. A few examples are the Repository Pattern (or the generic version) and the Strategy Pattern. Both are very effective when writing software. But I have also mentioned SOLID, which is a collection of design principles. But what is the difference between design patterns and design principles? When do we talk about a design pattern and when about a design principle?

Design patterns and principles are here to help us make better code. Where one focuses more on the architecture and guidelines, the other focuses more on solutions in code. It’s important to know that we — developers — have some sort of guidelines and solutions as you go. But remember we are working with software: Expect the unexpected and not all environments are the same.

In my years as a developer, I have come across a lot of principles and patterns. Some are thought of by a team member and it works for that solution and some are defined by great minds, still maintained, and are used to this day. This article is about the latter.

The Definitions

Both have different definition that already shows the big difference between them. A design pattern is a solution to a particular problem. Most definitions can be shown in code. Because it can be translated to code, the solution is usually reusable and helps to solve recurring design issues.

A design principle is a guide that explains certain solutions or guidelines to developers, making it easier to solve problems that might occur in code. These guidelines are here to help us prevent problems. Design problems help us create robust, maintainable, and flexible software. A design principle is not code, only theory.

Design Patterns

One of the most well-known design patterns is the Singleton Pattern. This pattern states and shows that a class should be initiated only once and this instance should be used throughout the application’s lifecycle. This pattern can be used in all programming languages that use classes and initiates classes.

Another example is the Strategy Pattern. This pattern is a behavioral pattern that enables dynamic selection and interchangeability of algorithms or strategies at runtime. You can simplify complex if-statements or make dynamic choices at runtime.

Other examples are the Observer pattern and the Factory pattern. But there are way more. You can divide them into 3 categories: Creational design, structural design, and behavioral design. The image below gives you a good idea of which patterns belongs in what category.

Design Patterns

It is (almost) impossible to know and learn them all. My advice: Learn the basic idea of them, know when you can use them, and figure out how they work when you are in a situation where you might think “Oh, I know a pattern for that!”

Design Principles

If you look at the design principles, we see other names coming up. Names like SOLID, DRY, KISS, and other funny-looking abbreviations.

DRY stands for Don’t Repeat Yourself, which states that you should not write duplicate code. Duplicate code can cause a lot of problems when you have to change something. Avoid issues and write your code once and reuse it in other parts of your application.

KISS stands for Keep It Simple Stupid, although the last ‘s’ is removed in this day and age. This one states that code should be simple and understandable for others. The more complex you make it, the harder it becomes to understand.

SOLID is a collection of different principles: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, I could give examples for all of them, but then it would be a lot of reading for you (and writing for me). If you follow Wikipedia on SOLID, you will get a lot of information.


The moment you use a principle or pattern is different too. There is no one-size-fits-all solution and you might not use them at all. It goes without saying that design patterns are used during coding since they give solutions to certain code issues. Patterns can be added or removed along the way.

While creating software, your views might change (or those of a manager). This makes you decide differently and you might want to add or remove a pattern. This is okay. For example, a simple if-statement suddenly becomes this monster of if-elseif-elseif-elseif-elseif-etc. Then maybe it’s time to implement the strategy pattern.

Design principles are usually applied in the early stages of development. They are mostly about architectural design and planning. But also high-level designs. These are things you can’t change when you are halfway through coding your application.

The Single Responsibility Principle (SRP) is pretty important. If you lose control of this one and classes and methods get multiple responsibilities, you might end up refactoring your code and breaking a lot of methods because the responsibility might be scattered across multiple methods and classes.


Design patterns are proven solutions that can help solve reoccurring problems. Design principles are guidelines that can help you give structure and architecture to your software. That’s it, that’s all.

You don’t need to use all patterns and principles that exist. In fact, using all SOLID principles in a single software application is nearly impossible. I managed it once, and that was a fairly small project.

It’s a good practice to look at the differences between design principles and design patterns and know when to use which one. Again, it is almost impossible to know all patterns and principles by heart, but know the names and the basic idea behind them.

Dec 26, 2022
Author: Mahesh Chand
IntroductionDo you find yourself not having enough time in a day? Why isn't the work getting done? And why is it taking so long? If these questions sound familiar, you're not alone. Productivity is very important also while working from home....
Jul 9, 2023
Author: Kenji Elzerman
When you have multiple applications and they need to communicate with each other to exchange data you might want to use a protocol that makes something like that happen. In C#, the HTTPClient class provides a powerful and flexible way...
Jul 8, 2021
Author: Christophe Nasarre
In the context of helping the teams at Criteo to clean up our code base, I gathered and documented a few C# anti-patterns similar to Kevin’s publication about performance code smell. Here is an extract related to good/bad memory patterns.Even...
Mar 15, 2023
Author: Alex Maher
1. JustDecompileJustDecompile is a free decompiler tool that allows you to easily decompile .NET assemblies into readable code. With this tool, you can quickly and easily analyze the code of any .NET application, even if you don’t have the original...
Написать сообщение

© 1999–2023 WebDynamics
1980–... Sergey Drozdov
Area of interests: .NET | .NET Core | C# | ASP.NET | Windows Forms | WPF | Windows Phone | HTML5 | CSS3 | jQuery | AJAX | MS SQL Server | Transact-SQL | ADO.NET | Entity Framework | IIS | OOP | OOA | OOD | WCF | WPF | MSMQ | MVC | MVP | MVVM | Design Patterns | Enterprise Architecture | Scrum | Kanban
GitHub profile