Optimal Coder

In the previous post, we gave an introduction and explained the basic concept of the  Strategy Pattern . Now, we want to go a bit further and demonstrate how it works in practice alongside a dependency injection in .NET Core. Instead of manually instantiating strategies, we let the ASP.NET Core DI container inject the correct implementation at runtime. Example For the showing purposes, let us asume that we are implementing some payment service, and we want to use one service at the time, depending on user input. For our strategy pattern, we would need following components: Interface public interface IPaymentStrategy { void Pay ( decimal amount ) ; } Concrete Strategies public class CreditCardPayment : IPaymentStrategy { public void Pay(decimal amount) { Console.WriteLine($"Paid ${amount} using Credit Card."); } } public class PayPalPayment : IPaymentStrategy { public void Pay(decimal amount) { Console.WriteLine($"Paid ${amoun...

The Strategy Pattern is a behavioral design pattern that defines a family of algorithms, encapsulates each one, and makes them interchangeable. This pattern allows the algorithm to be selected at runtime, providing flexibility in designing software. It’s particularly useful when you have multiple ways of performing a task, and you want to choose the implementation dynamically without altering the client code. When To Use It? You Have Multiple Algorithms or Behaviors. Use it when you have a need for muplitple ways of performing a task, and you want to make these implementations interchangeable. Examples: Different sorting algorithms, payment methods, discount calculations... You Want to Eliminate Conditional Logic.  If you find yourself writing large if-else or switch statements to decide which algorithm to use, this pattern can simplify and clean up your code. Examples: A game character with different attack styles  You Need Runtime Flexibility.  Use this pattern if the ...

Inheritence is often misused or overused or even forced for several reasons, and they are mostly due to education, misunderstanding or habit. Many developers who studied OOP are introduced with inheritence in early stage and then it stays with them as a default way how to build relationships between objects. Escaping this matrix can be quite challenging, as lacking alternative perspectives often leads to the trap of believing that inheritance is the solution to everything. Here, we will try to find the reasoning behind this way of thinking. Historical Influence Early OOP examples often revolved around "is-a" relationships like Car -> Vehicle, Dog -> Animal , reinforcing inheritance as the primary method of code reuse. We can see this in early OOP literature, such as the influential "Gang of Four Design Patterns",  where inheritance is prominently discussed. And then, as a result, developers internalized it as the default design approach. Inheritance = Code Reu...

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

In this post, we continue to explore ways to free your application from being tightly bound to the Entity Framework environment. The primary goal is to offer an alternative solution that is not only more flexible and robust but also gives you, as a developer, greater control over database manipulation with less abstraction and complexity. Here, we introduce a library for database migrations, which serves as a natural extension to tools like Dapper and SqlKata . Fluent Migrator Fluent Migrator  is a library designed for managing database migrations, giving you complete control over the execution and how migrations are written. It offers greater flexibility compared to standard EF migrations, which are closely tied to EF entities and generated automatically, often accompanied by additional overhead, including extra snapshot files. In the code snippet below, you’ll find a simple migration class. This class includes two methods that override the base Migration class, allowing you to d...

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

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) { ...