DEV Community: Abdullah Al Mahmud

Useful Math Symbols to Understand Equations Better

Abdullah Al Mahmud — Mon, 09 Feb 2026 12:44:22 +0000

As a postgrad student and AI enthusiast, often I have to read research papers on AI/ML topics. But there are times when I find it difficult to understand complex equations in those papers due to unknown mathematical symbols. So, I decided to make a list of all necessary mathematical symbols. I took help from chatGPT and claude to make the list. Here are few symbols from the document I created.

The list has following categories

Greek letters
Set theory and logic
Calculus and analysis
Linear algebra
Probability and statistics
Optimization and functions
Neural network specific symbols
Special symbols and operators.

You can download the document from my linkedin post 😊.

Math Symbols for ML/AI Research | Abdullah Al Mahmud posted on the topic | LinkedIn

While reading research papers on ML/AI, sometimes I find it difficult to read equations because of different unknown symbols. So asked chatGPT and Claude to give me a comprehensive list of mathematical symbols. I thought it's worth sharing. 😀 Do let me know if you find any mistakes!

linkedin.com

🔎Exploring Design Patterns: Strategy Pattern

Abdullah Al Mahmud — Thu, 24 Apr 2025 15:20:14 +0000

Introduction

The Strategy Design Pattern is a behavioral design pattern that enables selecting an algorithm's behavior at runtime. Rather than implementing a single algorithm directly, code receives run-time instructions as to which algorithm to use.

Think of it like choosing different routes to get to work: walking, driving, or taking public transport. Each "strategy" achieves the same goal (getting to work) but uses a different approach. Instead of hardcoding your commute method, you can switch between strategies based on weather, time constraints, or other factors.

Pattern Classification

Type: Behavioral
Scope: Object

Problem Statement

Software often needs to support multiple ways of performing the same task. Without a proper pattern, this leads to:

Conditional logic (if/else or switch statements) scattered throughout the code
Difficulty adding new algorithms without modifying existing code
Code that violates the Open/Closed Principle
Tight coupling between the client code and the specific algorithms
Challenges in unit testing individual algorithms separately

For example, consider a payment processing system that must support multiple payment methods. Traditional approaches might use complex conditional branches that become increasingly difficult to maintain as more payment options are added.

Anti-Pattern Case Study

Here's an example of code that doesn't use the Strategy pattern but should:

public class ShippingCalculator
{
    public decimal CalculateShipping(Order order, string shippingMethod)
    {
        decimal shippingCost = 0;

        switch (shippingMethod)
        {
            case "Standard":
                // Standard shipping calculation
                shippingCost = order.Weight * 1.5m;
                if (order.Weight > 10)
                {
                    shippingCost *= 0.9m; // 10% discount for heavy items
                }
                break;

            case "Express":
                // Express shipping calculation
                shippingCost = order.Weight * 3.0m;
                if (order.TotalAmount > 100)
                {
                    shippingCost -= 5; // $5 off for orders over $100
                }
                break;

            case "NextDay":
                // Next day shipping calculation
                shippingCost = order.Weight * 4.5m;
                if (order.Distance > 100)
                {
                    shippingCost += 10; // $10 surcharge for long distances
                }
                break;

            default:
                throw new ArgumentException("Unsupported shipping method");
        }

        return shippingCost;
    }
}

// Supporting class for the example
public class Order
{
    public decimal Weight { get; set; }
    public decimal TotalAmount { get; set; }
    public int Distance { get; set; }
}

This implementation has several problems:

Adding a new shipping method requires modifying existing code
The class violates the Single Responsibility Principle by handling multiple algorithms
If the calculation logic needs to be reused elsewhere, it cannot be easily extracted
As more shipping methods are added, the switch statement grows unwieldy

Over time, these issues compound. When business requirements change (e.g., adding regional shipping rules or promotional discounts), the code becomes increasingly complex and error-prone. Refactoring might require changes throughout the application, leading to potential regressions.

Solution

The Strategy pattern addresses these issues by:

Defining a family of algorithms (strategies)
Encapsulating each algorithm in separate classes
Making the algorithms interchangeable within that family

The pattern consists of:

Strategy Interface: Defines the common interface for all concrete strategies
Concrete Strategies: Implement the algorithm using the strategy interface
Context: Maintains a reference to a strategy object and delegates to it

Implementation in `C#`

// Step 1: Define the strategy interface
public interface IShippingStrategy
{
    decimal CalculateShipping(Order order);
}

// Step 2: Implement concrete strategies
public class StandardShippingStrategy : IShippingStrategy
{
    public decimal CalculateShipping(Order order)
    {
        decimal cost = order.Weight * 1.5m;
        if (order.Weight > 10)
            cost *= 0.9m; // 10% discount for heavy items
        return cost;
    }
}

public class ExpressShippingStrategy : IShippingStrategy
{
    public decimal CalculateShipping(Order order)
    {
        decimal cost = order.Weight * 3.0m;
        if (order.TotalAmount > 100)
            cost -= 5; // $5 off for orders over $100
        return cost;
    }
}

public class NextDayShippingStrategy : IShippingStrategy
{
    public decimal CalculateShipping(Order order)
    {
        decimal cost = order.Weight * 4.5m;
        if (order.Distance > 100)
            cost += 10; // $10 surcharge for long distances
        return cost;
    }
}

// Step 3: Create the context class
public class ShippingCalculator
{
    private IShippingStrategy _strategy;

    public ShippingCalculator(IShippingStrategy strategy)
    {
        _strategy = strategy;
    }

    public void SetStrategy(IShippingStrategy strategy)
    {
        _strategy = strategy;
    }

    public decimal CalculateShipping(Order order)
    {
        return _strategy.CalculateShipping(order);
    }
}

Step-by-Step Breakdown

We define the IShippingStrategy interface with a single method CalculateShipping that takes an order and returns the shipping cost.
We implement three concrete strategies (StandardShippingStrategy, ExpressShippingStrategy, and NextDayShippingStrategy), each with its own algorithm for calculating shipping costs.
We create a ShippingCalculator context class that:
- Takes a strategy in its constructor
- Provides a method to change the strategy at runtime
- Delegates the actual calculation to the current strategy
This approach separates the calculation algorithms from the context that uses them, making the system much more flexible and maintainable.

Usage Examples

// Create an order
var order = new Order
{
    Weight = 15,
    TotalAmount = 150,
    Distance = 120
};

var standardShipping = new StandardShippingStrategy();
var expressShipping = new ExpressShippingStrategy();
var nextDayShipping = new NextDayShippingStrategy();

var calculator = new ShippingCalculator(standardShipping);

decimal standardCost = calculator.CalculateShipping(order);
Console.WriteLine($"Standard shipping cost: ${standardCost}");

calculator.SetStrategy(expressShipping);
decimal expressCost = calculator.CalculateShipping(order);
Console.WriteLine($"Express shipping cost: ${expressCost}");

calculator.SetStrategy(nextDayShipping);
decimal nextDayCost = calculator.CalculateShipping(order);
Console.WriteLine($"Next day shipping cost: ${nextDayCost}");

// we can also create a factory to get the appropriate strategy:
public static IShippingStrategy GetShippingStrategy(string method)
{
    return method switch
    {
        "Standard" => new StandardShippingStrategy(),
        "Express" => new ExpressShippingStrategy(),
        "NextDay" => new NextDayShippingStrategy(),
        _ => throw new ArgumentException("Unsupported shipping method")
    };
}

// And use it like this:
calculator.SetStrategy(GetShippingStrategy("Express"));

Advantages

Open/Closed Principle: You can add new strategies without modifying existing code
Single Responsibility Principle: Each strategy encapsulates its own algorithm
Improved Testability: Strategies can be tested independently
Runtime Flexibility: Algorithms can be switched during runtime
Elimination of Conditional Logic: Reduces or eliminates complex if/else or switch statements
Code Reuse: Strategies can be reused across different contexts
Maintainability: Easier to understand and maintain multiple simple classes than one complex class

Disadvantages and Limitations

Increased Number of Classes: Creates more classes, which can add complexity
Client Must Be Aware of Strategies: The client must know which strategy to select
Communication Overhead: Strategies might need data from the context, requiring parameter passing
Overkill for Simple Cases: May be unnecessary for applications with only one or two simple algorithms
Memory Usage: Additional objects are created, which might impact performance in memory-constrained environments

Related Patterns

Factory Method: Often used with Strategy to instantiate the appropriate strategy

Best Practices and Tips

Use dependency injection to provide strategies to the context
Consider using a factory method to create strategies
Keep the strategy interface focused and cohesive
Ensure strategies have access to all the data they need to function
Use default strategies when appropriate
Document the behavior of each strategy clearly
Consider making strategies stateless to improve reusability

Conclusion

The Strategy Design Pattern is a powerful tool for managing algorithms, behaviors, or processes that need to vary independently from clients that use them. By encapsulating different algorithms in separate classes with a common interface, it promotes code that is more maintainable, extensible, and adheres to SOLID principles.

When you find yourself writing complex conditional logic to choose between different algorithms or behaviors, consider the Strategy pattern. It's particularly valuable in systems that need to support multiple ways of performing the same task, especially when those algorithms need to be selected at runtime or are likely to change over time.

🌟Find design pattern examples here

C# & .NET Insights: AsEnumerable in LINQ

Abdullah Al Mahmud — Fri, 18 Apr 2025 11:59:41 +0000

The AsEnumerable LINQ function might seem redundant at first glance since it simply returns the source collection as an IEnumerable. However, it serves some important purposes in LINQ operations.

Here are some practical examples:
✔️ Deferring query execution from LINQ to SQL/Entity Framework

✔️ Change LINQ provider/context

✔️ Using custom implementation

🔎Exploring Design Patterns: Adapter Pattern

Abdullah Al Mahmud — Sat, 16 Nov 2024 10:42:07 +0000

General Structure:

Target (IJsonAdapter): The interface that clients expect to use

Adaptee (LegacyXmlSystem): The existing class that needs to be adapted

Adapter (XmlToJsonAdapter): The class that bridges between Target and Adaptee

Client: The code that works with the Target interface

public interface IJsonAdapter
{
    string GetJsonData();
}

// Adaptee: Legacy system that needs to be adapted
public class LegacyXmlSystem
{
    public string GetXmlData()
    {
        return "<data> some XML data </data>";
    }
}

// Adapter: Adapter implementation
public class  XmlToJsonAdapter : IJsonAdapter
{
    private LegacyXmlSystem _xmlSystem;

    public XmlToJsonAdapter(LegacyXmlSystem xmlSystem)
    {
        _xmlSystem = xmlSystem;
    }

    public string GetJsonData()
    {
        string xmlData = _xmlSystem.GetXmlData();
        // converting xml to json
        return "{ data: some XML data converted to JSON }";
    }
}

When to Use:

Integrating legacy code with new systems
Making incompatible interfaces work together
Reusing existing classes with incompatible interfaces
Converting data formats between systems
Maintaining backward compatibility

Benefits:

Promotes reusability of existing code
Provides clean separation of concerns
Makes incompatible code work together without modifying source
Follows Single Responsibility Principle
Enhances maintainability

Limitations:

Can add complexity to the codebase
May require creating multiple adapters for different interfaces
Could impact performance due to additional layer
Might make debugging more challenging
Not suitable when extensive interface modifications are needed

The real-world example in the code shows adapting XML data to JSON format. The pattern is particularly useful in scenarios like:

Database interface adaptations
Third-party library integration
API versioning
File format conversions
Payment gateway integrations

✨ You can find design pattern codes in this repository

✨ Exploring Design Patterns Other Posts

🔎Exploring Design Patterns: Factory Method

Abdullah Al Mahmud — Fri, 08 Nov 2024 00:52:30 +0000

Factory Method

Let's say we need to create two types of documents in your application.

PDF
Word

So we can simply write the following codes.
First we create a document creator class that creates required document
type based on the parameter passed.

public class DocumentCreator
{
    public IDocument CreateDocument(string type)
    {
        IDocument doc = null!;
        if (type == "pdf")
        {
            doc = new Pdf();
        }
        else if (type == "word")
        {
            doc = new Word();
        }
        return doc;
    }
}

Here as we can see CreateDocument return a IDocument object. because
we are dealing with different return type here.
So, this is how we will have to define our concrete classes.

public interface IDocument
{
    void Open();
    void Close();
    void Save();
}

public class Pdf : IDocument
{
    public void Open()
    {
        //logic
    }

    public void Close()
    {
        //logic
    }
    public void Save()
    {
        //logic
    }
}

public class Word : IDocument
{
    public void Open()
    {
        //logic
    }

    public void Close()
    {
        //logic
    }
    public void Save()
    {
        //logic
    }
}

And finally we have our client code.

public class Client
{
    public static void ClientMain()
    {
        DocumentCreator creator = new DocumentCreator();
        Document pdf = creator.CreateDocument("pdf");
        Document word = creator.CreateDocument("word");
    }
}

This looks good. But what if our client wants to add a new document type. Let's say
Excel. We will have to add a new class Excel and modify CreateDocument function in the DocumentCreator class like following

public class DocumentCreator
    {
        public IDocument CreateDocument(string type)
        {
            IDocument doc = null!;
            if (type == "pdf")
            {
                doc = new Pdf();
            }
            else if (type == "word")
            {
                doc = new Word();
            }
            else if (type == "excel") 
            {
                doc = new Excel();
            }
            return doc;
        }
    }

But this breaks the Open Closed principle. The class DocumentCreator is not
closed for modification.

This is where Factory Method pattern comes in to save the day!
First, let's see how we implement this pattern for two types of documents.

We will define the Document interface, Pdf and Word class just like previous example. No
change here.

But this time along with concrete classes we will define some concrete factory classes and a common abstract factory class like below.

public abstract class DocumentFactory
{
    public abstract IDocument CreateDocument();
}

public class PdfFactory : DocumentFactory
{
    public override IDocument CreateDocument()
    {
        return new PdfDocument();
    }
}

public class WordFactory : DocumentFactory
{
    public override IDocument CreateDocument()
    {
        return new PdfDocument();
    }
}

And this is how the client code will use the factories

public class Client
{
    public static void ClientMain()
    {
        DocumentFactory pdfFactory = new PdfFactory();
        DocumentFactory wordFactory = new WordFactory();

        IDocument pdf = pdfFactory.CreateDocument();
        IDocument word = wordFactory.CreateDocument();

        pdf.Open();
        word.Open();

        pdf.Close();
        word.Close();
    }
}

As we can see now we have such a setup that if we need to add a new document type we don't
need to modify any classes. We just create a new class and factory like following.

public class Excel : IDocument
{
    public void Open()
    {
        //logic
    }

    public void Close()
    {
        //logic
    }
    public void Save()
    {
        //logic
    }
}

public class ExcelFactory : DocumentFactory
{
    public override IDocument CreateDocument()
    {
        return new Excel();
    }
}

That makes our code closed for modification but open for extension. Below are some more details about this desing pattern.

The Factory Method pattern is a creational pattern that provides an interface for creating objects but allows subclasses to alter the type of objects that will be created. Here's when and why you should use it:

When to Use:
- When you don't know ahead of time what exact types of objects you need to create
- When you want to delegate the responsibility of object creation to subclasses
- When you want to provide a way to extend the application's code with new types without modifying existing code
- When you have a class that needs to create different types of objects based on some condition
Problems it Solves:
- Decouples object creation from the code that uses the objects
- Makes the code more flexible and extensible
- Follows the Open/Closed Principle (open for extension, closed for modification)
- Eliminates the need for complex conditional logic in object creation
- Provides a way to encapsulate object creation logic

In the example above:

IDocument is the product interface that defines what a document can do
Pdf and Word are concrete products
DocumentFactory is the abstract creator with the factory method
PdfFactory and WordFactory are concrete creators

Real-world examples where Factory Method is useful:

UI Framework Components:

public abstract class ButtonFactory
{
    public abstract IButton CreateButton();
}

// Different factories for Windows, Mac, Web buttons

Database Connections:

public abstract class DbConnectionFactory
{
    public abstract IDbConnection CreateConnection();
}

// Separate factories for SQL Server, Oracle, MySQL

Payment Processing:

public abstract class PaymentProcessorFactory
{
    public abstract IPaymentProcessor CreateProcessor();
}

// Different factories for PayPal, Stripe, Square

Benefits of using Factory Method:

Easy to add new product types without changing existing code
Single Responsibility Principle - separates product creation code from the product usage code
Helps manage complexity in applications with multiple product variants
Makes the code more testable by allowing mock object creation

🔎Exploring Design Patterns: Thread Safe Singleton Pattern in C#

Abdullah Al Mahmud — Mon, 28 Oct 2024 10:00:06 +0000

Singleton (Thread Safe)

private static readonly Lazy<DbConnectionThreadSafe> _instance = null!;

Using `Lazy<T>` Because

Thread safe by default
Provides lazy initialization

static DbConnectionThreadSafe()
{
    _instance = new Lazy<DbConnectionThreadSafe>(
        () => new DbConnectionThreadSafe(_connectionString),
        LazyThreadSafetyMode.ExecutionAndPublication
    );
}

Let's break down this static constructor and the Lazy initialization:

static DbConnection()  // This is a static constructor
{
    _lazyInstance = new Lazy<DbConnection>(
        () => new DbConnection(_connectionString),  // Lambda expression
        LazyThreadSafetyMode.ExecutionAndPublication  // Thread safety mode
    );
}

Let's examine each part:

Static Constructor (static DbConnection())
- A static constructor is called automatically before any static members are referenced
- It runs only once per app domain
- It's thread-safe by default (CLR guarantees this)
- Used to initialize static fields
Lazy
- Lazy<T> is a class that provides lazy initialization
- The actual object isn't created until it's first accessed
- When you access Lazy<T>.Value for the first time, it creates the instance
Lambda Expression (() => new DbConnection(_connectionString))
- This is a factory function that creates the DbConnection instance
- It's only executed when the Lazy.Value is first accessed
- The => syntax defines a lambda expression (anonymous function)
LazyThreadSafetyMode.ExecutionAndPublication
- This enum value specifies how the Lazy instance handles thread safety
- Three possible modes:

// No thread safety
LazyThreadSafetyMode.None

// Locks initialization
LazyThreadSafetyMode.ExecutionAndPublication

// Multiple threads can attempt initialization
LazyThreadSafetyMode.PublicationOnly

The execution flow:

When the class is first referenced, the static constructor runs
The _lazyInstance is created, but the DbConnection instance is not yet created
When Instance is first accessed:
- The lambda expression runs
- Creates new DbConnection with the connection string
- Stores it in the Lazy instance
Subsequent accesses to Instance return the same stored instance