Skip to main content

Posts

Showing posts with the label software arhitecture

Design Patterns: Decorator

The Decorator Pattern is a structural design pattern that allows behavior to be dynamically added to individual objects, without modifying their code. It is often used to extend the functionalities of classes in a flexible and reusable way. When To Use It? You Need to Add Behavior Dynamically at Runtime.  Example: A coffee shop app where users can customize their drinks with add-ons like Milk, Sugar, Whipped Cream, etc. You Want to Avoid a Large Inheritance Tree.  If you use inheritance, each combination of behaviors would require a new subclass (e.g., CoffeeWithMilk , CoffeeWithSugar , CoffeeWithMilkAndSugar , etc.). You Want More Flexible and Reusable Code.  Different decorators can be reused independently . Example: A LoggingDecorator , CompressionDecorator , and EncryptionDecorator can be used separately or in different orders. You Follow the Open-Closed Principle.  Instead of modifying an existing class, you can extend behavior using decorators . This mak...

Design Patterns: Factory Method

Let’s continue our series on design patterns with the Factory Method. Like the  Builder  or  Singleton  patterns we covered in previous posts, the Factory Method is also one of the creational patterns. It introduces a slightly more complex approach, offering a higher level of abstraction for object creation. Additionally, it helps decouple the object creation process from the rest of the application. It can be represented through the following components: Abstract object , which represents the base class for the objects that we want to create Concreate objects , classes that inherit the given base class Creator , abstraction of the classes resposible for the object creation Concreate creators, classes that inherit and implement given creator class Client or Consumer side , parts of the application where we call objects creation Bellow, we will show all these parts in one simple example. using System; // abstract object abstract class Engine { public abstract v...

Dapper On Steroids: SqlKata

Dapper is a lightweight, high-performance ORM for .NET. It is widely used because of its simplicity and speed. Dapper in its essence provides simple mapping to POCO and works with raw queries minimizing the overhead. On the other hand it lacks of flexibility in terms of query writing, because we need to write queries like static strings. One simple example is shown in the code snippet below. using System; using System.Data.SqlClient; using Dapper; class Program { static void Main(string[] args) { using (var connection = new SqlConnection("connection_string")) { connection.Open(); string sql = "SELECT * FROM Companies"; var companies = connection.Query<Company>(sql); } } } With the lack of flexibility in query construction, we would be in temptation to go for Entity Framework or some other heavy weight ORM, but there is also a simple library ( SqlKata ) which provides a decent flexibil...

Design Patterns: Builder

This is also, like a Singleton , one of the creational design patterns. It provides the way of creating complex objects step by step by simple chaining and every particular step is independent of other steps. Let us dive into the real example of usage. For showing purpose we have created an example in C# which creates simple SQL queries using described pattern.  using System; using System.Text; namespace BuilderPatternExample { public interface ISqlQueryBuilder { ISqlQueryBuilder Select(string columns); ISqlQueryBuilder From(string table); ISqlQueryBuilder Where(string condition); ISqlQueryBuilder OrderBy(string columns); string Build(); } public class SelectQueryBuilder : ISqlQueryBuilder { private readonly StringBuilder _queryBuilder; public SelectQueryBuilder() { _queryBuilder = new StringBuilder(); } public ISqlQueryBuilder Select(string columns) { ...

Design Patterns: Singleton

Tyipically the first design pattern most people learn, often wrongly ☺ To give an introduction, we can say that singleton is one of the creational design patterns which ensures only one class instance with single point of access thru entire application.  Because it is relatively simple to implement, the Singleton pattern is sometimes misapplied in situations where it is not the most suitable choice. When to use it? Here are the few examples of corrent usage of singleton: Configuration Management  Centralized configuration settings for consistent use thru entire application Caching Maintaning  Single istance of cached objects for easy and fast acces Logging  Ensure unified mechanism to avoid duplication of log files, formats, etc Global State Management  Centralized management of the state which is needed to be shared accross the application Resource sharing  Thread pools, database connection, I/O operations When not to use it? On the other hand, here are fe...