DEV Community: Vedant Phougat

Important Links

Vedant Phougat — Fri, 20 Dec 2024 07:35:37 +0000

Table of content

1. ASP.NET
- 1.1. Authentication & Authorization
- 1.2. Guidelines
2. ADVANCED .NET
- 2.1. HttpClient
- 2.2. Asynchronous programming
- 2.3. GC
3. .NET PERFORMANCE & PROFILING
- 3.1. Performance engineering
- 3.2. Memory and Span
- 3.3. System.IO.Pipelines
- 3.4. ArrayPool
- 3.5. Profiling and Diagnostics
4. REST APIs
5. DISTRIBUTED CLOUD APPLICATION

1. ASP.NET

1.1. Authentication & Authorization

Improvements to Auth and Identity in ASP.NET Core 8

1.2. Guidelines

2. ADVANCED .NET

2.1. HttpClient

2.2. Asynchronous programming

2.3. GC

3. .NET PERFORMANCE & PROFILING

3.1. Performance engineering

3.2. Memory and Span

Memory and Span usage guidelines
All About Span: Exploring a New .NET Mainstay
📺 Deep .NET: A Complete .NET Developer's Guide to Span
📺 C# 7.2: Understanding Span
Span by Adam Sitnik
Span<T> by Krzysztof Cwalina
An Introduction to Optimising Code Using Span<T> by Steve Gordon

3.3. System.IO.Pipelines

3.4. ArrayPool

3.5. Profiling and Diagnostics

4. REST APIs

5. DISTRIBUTED CLOUD APPLICATION

Architecting Distributed Cloud Applications

How to implement IEquatable?

Vedant Phougat — Sun, 15 Dec 2024 16:00:44 +0000

Table of content

1. Introduction
2. What and why of IEquatable<T>?
3. Equality comparison prior to IEquatable<T>
- 3.1. Value Type (struct)
- 3.2. Reference Type (class)
- 3.3. Recommendation
4. User-defined struct implementing IEquatable<T>
- 4.1. Implementation
- 4.2. Testing
5. User-defined class implementing IEquatable<T>
- 5.1. Implementation
- 5.2. Testing
- 5.3. When inheritance steps in
6. Conclusion
7. See also

1. Introduction

In this blog post, we will dive into the equality comparison with a focus on implementing IEquatable<T> and I will try to answer the following on the way:

How equality comparison worked for user-defined types before the introduction of IEquatable<T>?
How to implement IEquatable<T> for both user-defined structs and classes?
How to test our implementation to ensure reliability and consistency?

To implement IEquatable<T> accurately, reliably, and consistently, the developer must also override Equals(Object? obj) and GetHashCode() as well.
Here is why:

Performance implications of default struct equality in C#?

If You Implement IEquatable<T> You Still Must Override Object.Equals And Gethashcode

Why is it important to override GetHashCode when Equals method is overridden?

2. What and why of `IEquatable<T>`?

It is a generic interface, that allows an object of type A to compare itself to another object of the same type.

The IEquatable<T> was primarily introduced for structs to:

Provide a more efficient equality comparison than the default, reflection-based equality comparison defined in the overridden Equals method in the System.ValueType class.
Avoid the boxing/unboxing overhead of Equals(Object? obj) by enabling strongly-typed equality with the Equals(T other) method.

3. Equality comparison prior to `IEquatable<T>`

3.1. Value Type (struct)

Default implementation: If we don’t override the Equals(Object? obj) method, equality comparisons rely on the default behavior provided by Object.Equals(Object? obj) method, which is overridden in the Equals implementation of the System.ValueType class. This approach involves:
- Boxing: The struct instance is boxed into an object by allocating memory on the heap and copying the struct's value to this memory.
- Reflection: The System.ValueType.Equals implementation uses reflection to iterate over and compare each field of the struct for equality.
Overrding Equals(Object? obj): It improves performance by eliminating reflection compared to the default implementation. However, it still incurs the performance overhead associated with boxing and unboxing. To avoid this completely, implement IEquatable<T>.

public struct Count
{
    //value property
    //Count constructor

    public override Boolean Equals(Object? obj)
    {
        if (obj is Count count)    //UNBOXING
        {
            return Value == count.Value;    //direct field access
        }

        return false;
    }
}

public class Program
{
    public static void Main(String[] args)
    {
        var count = new Count(10);
        var isEqual = count.Equals(count);    //BOXING
    }
}

3.2. Reference Type (class)

Default behaviour: The Equals(Object? obj) method in System.Object performs reference equality, meaning it checks if the references (memory addresses) of the two objects are same. If the references match, the objects are considered equal.
- However, if our business requirement defines equality based on identical data, the default behaviour will not work. Two objects with identical data but different references will not be considered equal.
Overriding Equals(Object? obj): We can define equality for our user-defined reference types by overriding the Equals(Object? obj) method.
- This allows explicit implementation of equality logic based on the properties or fields of our user-defined type.
- However, this approach involves the overhead of type casting between Object and the specific type. While this overhead is negligible for a single comparison, it can become significant when performing equality checks on a collection of objects.

class Person
{
    public string Name { get; set; }

    public override bool Equals(object? obj)
    {
        if (obj is Person other)  //casting to Person type.
        {
            return Name == other.Name;
        }

        return false;
    }
}

3.3. Recommendation

For best performance and clarity, it is highly recommended to implement the IEquatable<T> interface on user-defined types (both value and reference types). This provides a strongly-typed, efficient, and reusable equality comparison mechanism.

4. User-defined struct implementing `IEquatable<T>`

User-defined struct types don't support the == and != operators by default. Overloading them ensures that developers can use these operators naturally while maintaining consistency with Equals.

4.1. Implementation

In here we will implement IEquatable<T> on a struct, called CommandKey.

public readonly struct CommandKey : IEquatable<CommandKey>
{
    public static readonly CommandKey None = "none";

    public String Key { get; }

    public CommandKey(String key)
    {
        ArgumentNullException.ThrowIfNull(key);

        Key = key;
    }

    public Boolean Equals(CommandKey other) => String.Equals(Key, other.Key);
    public override Boolean Equals(Object? obj) => obj is CommandKey other && Equals(other);
    public override Int32 GetHashCode() => Key.GetHashCode();
    //public override String ToString() => Key;
    //public static implicit operator CommandKey(String key) => new CommandKey(key);
    //public static implicit operator String(CommandKey commandKey) => commandKey.Key;
    public static Boolean operator ==(CommandKey left, CommandKey right) => left.Equals(right);
    public static Boolean operator !=(CommandKey left, CommandKey right) => !left.Equals(right);
}

4.2. Testing

In here, we will write unit test cases for Equals(T other) and Equals(Object? obj) methods. The code snippet uses the following libraries:

Testing these methods verifies that:

The equality logic correctly identifies when two instances of the struct are equal or not equal.
The .NET collections, such as HashSet<T>, Dictionary<T> etc., work as expected with our user-defined struct
The edge cases like null comparisons, comparisons with other types, and comparisons between identical or different instances are handled correctly without throwing unexpected errors

/// <summary>
/// This class tests the equality logic for the <see cref="CommandKey"/> class.
/// It includes tests for the following methods and operators:
///     - <see cref="CommandKey.Equals(CommandKey)"/>
///     - <see cref="CommandKey.Equals(Object?)"/>
///     - == operator
///     - != operator
/// </summary>
public class Equals
{
    #region Equals(CommandKey)
    [Fact]
    public void ReturnsFalse_WhenCommandKeyIsDefault()
    {
        //Arrange
        CommandKey thisKey = "c";
        CommandKey otherKey = default;

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenCommandKeysAreDifferent()
    {
        //Arrange
        var thisKey = (CommandKey)"c";
        var otherKey = CommandKey.None;

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenCommandKeysDiffersInCasing()
    {
        //Arrange
        CommandKey thisKey = "c";
        CommandKey otherKey = "C";

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenCommandKeysDiffersInWhitespace()
    {
        //Arrange
        CommandKey thisKey = "c";
        CommandKey otherKey = " c ";

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsTrue_WhenBothCommandKeysAreDefault()
    {
        //Arrange
        CommandKey thisKey = default;
        CommandKey otherKey = default;

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeTrue();
    }

    [Fact]
    public void ReturnsTrue_WhenCommandKeysAreEqual()
    {
        //Arrange
        CommandKey thisKey = "c";
        CommandKey otherKey = "c";

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeTrue();
    }
    #endregion Equals(CommandKey)

    #region Equals(Object?)
    [Fact]
    public void ReturnsFalse_WhenKeyIsNull()
    {
        //Arrange
        CommandKey thisKey = "c";
        Object? otherKey = null;

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenKeyIsNotCommandKey()
    {
        //Arrange
        CommandKey thisKey = "c";
        var otherKey = 'c';

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenKeyIsDefaultCommandKey()
    {
        //Arrange
        CommandKey thisKey = "c";
        Object? otherKey = default(CommandKey);

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeFalse();
    }

    [Fact]  
    public void ReturnsTrue_WhenBothKeysAreDefaultCommandKey()
    {
        //Arrange
        CommandKey thisKey = default;
        Object? otherKey = default(CommandKey);

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeTrue();
    }

    [Fact]
    public void ReturnsTrue_WhenKeyIsCommandKeyAndEqual()
    {
        //Arrange
        CommandKey thisKey = "c";
        Object? otherKey = (CommandKey)"c";

        //Act
        var isEqual = thisKey.Equals(otherKey);

        //Assert
        isEqual.Should().BeTrue();
    }
    #endregion Equals(Object?)

    #region == operator
    [Fact]
    public void OperatorEquals_ReturnsFalse_WhenKeysAreNotEqual()
    {
        //Arrange
        CommandKey left = "c";
        CommandKey right = "d";

        //Act
        var isEqual = left == right;

        //Assert
        isEqual.Should().BeFalse();
    }

    [Fact]
    public void OperatorEquals_ReturnsFalse_WhenOnlyLeftKeyIsNull()
    {
        //Arrange
        CommandKey? left = null;
        CommandKey right = "c";

        //Act
        var isEqual = left == right;

        //Assert
        isEqual.Should().BeFalse();
    }

    [Fact]
    public void OperatorEquals_ReturnsTrue_WhenBothKeysAreNull()
    {
        //Arrange
        CommandKey? left = null;
        CommandKey? right = null;

        //Act
        var isEqual = left == right;

        //Assert
        isEqual.Should().BeTrue();
    }

    [Fact]
    public void OperatorEquals_ReturnsTrue_WhenKeysAreEqual()
    {
        //Arrange
        CommandKey left = "c";
        CommandKey right = "c";

        //Act
        var isEqual = left == right;

        //Assert
        isEqual.Should().BeTrue();
    }
    #endregion == operator

    #region != operator
    [Fact]
    public void OperatorNotEquals_ReturnsFalse_WhenKeysAreEqual()
    {
        // Arrange
        CommandKey left = "c";
        CommandKey right = "c";

        // Act
        var isEqual = left != right;

        // Assert
        isEqual.Should().BeFalse();
    }

    [Fact]
    public void OperatorNotEquals_ReturnsFalse_WhenBothKeysAreNull()
    {
        //Arrange
        CommandKey? left = null;
        CommandKey? right = null;

        //Act
        var isEqual = left != right;

        //Assert
        isEqual.Should().BeFalse();
    }

    [Fact]
    public void OperatorNotEquals_ReturnsTrue_WhenKeysAreNotEqual()
    {
        // Arrange
        CommandKey left = "c";
        CommandKey right = "d";

        // Act
        var isEqual = left != right;

        // Assert
        isEqual.Should().BeTrue();
    }

    [Fact]
    public void OperatorNotEquals_ReturnsTrue_WhenOnlyLeftKeyIsNull()
    {
        //Arrange
        CommandKey? left = null;
        CommandKey right = "c";

        //Act
        var isEqual = left != right;

        //Assert
        isEqual.Should().BeTrue();
    }
    #endregion != operator
}

5. User-defined class implementing `IEquatable<T>`

If one wants to implement value equality in user-defined reference types (classes), consider using Records available from C# 9.0 onward.

User-defined reference types support == and != operators by default, but these only check for reference equality. To ensure consistency with the logic in Equals, these operators must be explicitly overloaded.

5.1. Implementation

In here we will implement IEquatable<T> on a class, called Person.

public class Person : IEquatable<Person>
{
    public String FirstName { get; set; }
    public String LastName { get; set; }
    public DateTime Dob { get; set; }
    public String Email { get; set; }

    public Person(String firstName, String lastName, DateTime dob, String email)
    {
        FirstName = firstName;
        LastName = lastName;
        Dob = dob;
        Email = email;
    }

    public Boolean Equals(Person? other)
    {
        if (other is null)
        {
            return false;
        }

        return
            FirstName.Equals(other.FirstName) &&
            LastName.Equals(other.LastName) &&
            Dob.Equals(other.Dob) &&
            Email.Equals(other.Email);
    }

    public override Boolean Equals(Object? obj)
    {
        return
            obj is Person other &&
            Equals(other);
    }

    public override Int32 GetHashCode()
    {
        return HashCode.Combine(FirstName, LastName, Dob, Email);
    }

    public override String ToString()
    {
        return $"Person [Name={FirstName} {LastName}, Dob={Dob}, Email={Email}]";
    }

    public static Boolean operator ==(Person? left, Person? right)
    {
        //if references of the two objects is equal or both are null; returns true.
        if (ReferenceEquals(left, right))
        {
            return true;
        }

        if (left is null || right is null)
        {
            return false;
        }

        return left.Equals(right);    //calls the Equals(T other) method
    }

    public static Boolean operator !=(Person? left, Person? right)
    {
        return !(left == right);
    }
}

5.2. Testing

In here, we will write unit test cases for Equals(T other) and Equals(Object? obj) methods.

public class Equals
{
    #region IEquatable<Person>.Equals tests
    [Fact]
    public void ReturnsFalse_WhenOtherObjectIsNull()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");

        //Assert
        var actual = current.Equals(null);

        //Act
        actual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenFirstNameDoesNotMatches()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");
        var other = new Person(//everything matches except the first name);


        //Assert
        var actual = current.Equals(other);

        //Act
        actual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenLastNameDoesNotMatches()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");
        var other = new Person(//everything matches except the last name);

        //Assert
        var actual = current.Equals(other);

        //Act
        actual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenDobDoesNotMatches()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");
        var other = new Person(//everything matches except the dob);

        //Assert
        var actual = current.Equals(other);

        //Act
        actual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenEmailDoesNotMatches()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");
        var other = new Person(//everything matches except the email);

        //Assert
        var actual = current.Equals(other);

        //Act
        actual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsTrue_WhenFirstNameLastNameDobAndEmailMatches()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");
        var other = new Person(//everything matches);

        //Assert
        var actual = current.Equals(other);

        //Act
        actual.Should().BeTrue();
    }
    #endregion IEquatable<Person>.Equals tests

    #region Object.Equals tests
    [Fact]
    public void ReturnsFalse_WhenObjectIsNull()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");

        //Assert
        var actual = current.Equals(null);

        //Act
        actual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenObjectIsOfTypePersonAndNull()
    {
        //Arrange
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");
        var other = (Person?)null;

        //Assert
        var actual = current.Equals(other);

        //Act
        actual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenObjectIsNotOfTypePersonAndNull()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");
        var other = (String?) null;

        //Assert
        var actual = current.Equals(other);

        //Act
        actual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenObjectIsOfTypePersonNotNullAndNotEqual()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");
        var other = new Person(//with one or more properties that doesn't match);

        //Assert
        var actual = current.Equals(other);

        //Act
        actual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsFalse_WhenObjectIsNotOfTypePersonAndNotNull()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");
        var other = new Point(10, 20);

        //Assert
        var actual = current.Equals(other);

        //Act
        actual.Should().BeFalse();
    }

    [Fact]
    public void ReturnsTrue_WhenObjectIsOfTypePersonAndIsEqual()
    {
        //Arrange
        var dob = new DateTime(20, 1, 1991);
        var current = new Person("first-name", "last-name", dob, "test@example.com");
        var other = new Person(//everything matches);

        //Assert
        var actual = current.Equals(other);

        //Act
        actual.Should().BeTrue();
    }
    #endregion Object.Equals tests
}

5.3. When inheritance steps in

When a user-defined class inherits from another user-defined class, the child class should handle equality checks for its own fields, while relying on the parent class to handle equality for shared fields. If the parent class is at the top of the inheritance hierarchy and directly derives from System.Object, it does not need to call base.Equals(Object? obj) in its equality implementation.

For implementation details visit: How to implement value equality in a reference type (class)

While browsing the code snippet shown in the above-mentioned link, keep in mind that there are 2 user-defined classes which provide implementation of Equals method:

TwoDPoint, that derives directly from the System.Object class.
ThreeDPoint, that derives from the TwoDPoint class.

6. Conclusion

Implementing IEquatable<T> in user-defined types ensures:

Improved performance and type-safety, by avoiding boxing for value types and providing type-safe equality checks.
Consistency across equality checks, by centralizing equality logic in the Equals(T other) method.
Compatibility of user-defined types with .NET collections.

7. See also

Applying Open Closed Principle to Real-World Code

Vedant Phougat — Sat, 12 Oct 2024 11:30:59 +0000

1. Introduction
2. Requirements
3. Development
- 3.1. Challenges of initial approach
4. Refactor
- 4.1. Move each command to individual classes
- 4.2. Introduce a factory for command creation
- 4.3. Dynamic command discovery and auto-registration
5. Exercise
6. Conclusion
7. See also

1. Introduction

Have you ever had to dig through an existing codebase to modify it, just to add a new feature? After making changes, you then find yourself re-testing the modified part of the system, that was previously functioning well. This is a classic example of violation of the Open-Closed Principle (OCP from here), which emphasizes designing software so that new features can be added with minimal or no changes to existing code.

In his article—The Open-Closed Principle, Uncle Bob describes a plugin system as “the ultimate example of the Open-Closed Principle”.
In a related post—An Open and Closed Case, he clarifies OCP’s essence, stating: “... you should aim to structure your code so that, when behavior changes in expected ways, you won’t need to make sweeping changes across the system. Ideally, you’ll be able to add new behavior by adding new code and making minimal or no changes to existing code.”

In this blog post, we will use an example of a command-utility tool, let's call it wc.NET, where commands are added as new requirements. The design of wc.NET aligns closely with a plugin architecture. While it may not be an external plugin system, where commands are loaded from separate assemblies or packages at runtime, the architecture achieves internal extensibility. This means new commands (or "internal plugins") can be added simply by writing new code, with minimal or zero modification to the existing codebase—the essence of OCP.

Let's start with the official definition:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

2. Requirements

Develop a command line tool (wc.NET from here) using C# & .NET. The wc.NET must accept commands in the following format:

> -c <file_path>.txt
> -w <file_path>.txt
> -l <file_path>.txt
> -m <file_path>.txt

Here is the table indicating which command performs what type of count on a text file:

Command Key	Type of count to be performed
`-c`	Gets the number of Bytes
`-w`	Gets the number of Word
`-l`	Gets the number of Line
`-m`	Gets the number of Character

I believe these requirements are sufficient for our purpose, but in case you want detailed information about requirements, please visit Build Your Own wc Tool.

3. Development

As per the requirements, the initial development led us to the following code:

public class Processor
{
    public Int32 ProcessCommand(String[] args)
    {
        //validate 'args' to make sure that it
        //has the required arguments
        var filepath = args[^1];  //gets the last item of array
        var commandKey = args[0];
        switch (commandKey)
        {
            case "-c":
                return GetByteCount(filepath);
            case "-w":
                return GetWordCount(filepath);
            case "-l":
                return GetLineCount(filepath);
            default:
                throw new InvalidOperationException("Command not found.");
        }
    }

    private Int32 GetByteCount(String filepath)
    {
        //process and return the Byte Count.
    }

    private Int32 GetWordCount(String filepath)
    {
        //process and return the Word Count.
    }

    private Int32 GetLineCount(String filepath)
    {
        //process and return the Line Count.
    }
}

The class Processor currently has three commands, and per the requirements, when we implements a fourth, we will have to update the Processor class by adding:

a GetCharacterCount method
a case "-m" statement to handle the GetCharacterCount method.

And here is how it will look:

public class Processor
{
    public Int32 ProcessCommand(String[] args)
    {
        //validate 'args' to make sure that it
        //has the required arguments
        var filename = args[^1];  //gets the last item of array
        var commandKey = args[0];
        switch (commandKey)
        {
            case "-c":
                return GetByteCount(filepath);
            case "-w":
                return GetWordCount(filepath);
            case "-l":
                return GetLineCount(filepath);
            case "-m":    //<--- newly added case block
                return GetCharacterCount(filepath);
            default:
                throw new InvalidOperationException("Command not found.");
        }
    }

    private Int32 GetByteCount(String filepath)
    {
        //process and return the Byte Count.
    }

    private Int32 GetWordCount(String filepath)
    {
        //process and return the Word Count.
    }

    private Int32 GetLineCount(String filepath)
    {
        //process and return the Line Count.
    }

    //<--- newly added method to be called in 'case "-m"' block --->
    private Int32 GetCharacterCount(String filepath)
    {
        //process and return the Line Count.
    }
}

We wouldn’t just need to add a case block and a method to calculate the count, we would also have to add several other helper methods to support the count calculations. Over time, this approach would turn the class into an unmanageable, overly complex piece of code.

3.1. Challenges of initial approach

Risk of introducing bugs in a stable system: Adding each new command modifies the Processor class directly. And modifying an existing class directly, raises the risk of introducing bugs in a stable system, that was previously functioning well.
Hard to read, maintain, and extend: As more commands are added, the switch block grows, making the code harder to read and maintain. This complexity makes it tough to extend or update the class over time.

4. Refactor

To ensure the code adheres to the OCP and improves modularity, we will take a phased approach to refactoring.

4.1. Move each command to individual classes

In this phase, we will apply Single Responsibility Principle (SRP), to move each command's logic into its own class, and Polymorphism with each command implementing ICommand interface. This will remove Processor's direct dependency on each command's implementation.

Define the ICommand interface:

// <--- Interface --->
public interface ICommand
{
    string Execute(string filepath);
}

Move each command into its own class, the implementations:

public class ByteCountCommand : ICommand
{
    public string Execute(string filePath)
    { /* implementation */}
}

public class WordCountCommand : ICommand
{
    public string Execute(string filePath)
    { /* implementation */}
}

public class LineCountCommand : ICommand
{
    public string Execute(string filePath)
    { /* implementation */}
}

Refactoring Processor class to use a dictionary of commands:

public class Processor
{
    private readonly Dictionary<string, ICommand> _commands;

    public Processor()
    {
        _commands = new Dictionary<string, ICommand>
        {
            { "-c", new ByteCountCommand() },
            { "-w", new WordCountCommand() },
            { "-l", new LineCountCommand() }
        };
    }

    public string ProcessCommand(string commandKey, string filePath)
    {
        if (_commands.TryGetValue(commandKey, out var command))
        {
            return command.Execute(filePath);
        }

        throw new InvalidOperationException("Unknown command");
    }
}

4.2. Introduce a factory for command creation

Here we will create a CommandFactory class to centralize command creation. This change removes the direct dependency of creating individual command objects from the Processor.

Define CommandFactory:

public class CommandFactory
{
    private readonly Dictionary<string, ICommand> _commands = new()
    {
        { "-c", new ByteCountCommand() },
        { "-w", new WordCountCommand() },
        { "-l", new LineCountCommand() }
    };

    public ICommand GetCommand(string commandKey)
    {
        if (!_commands.TryGetValue(commandKey, out var command))
        {
            throw new CommandNotFound();
        }
        return command;
    }
}

Modify Processor to use CommandFactory:

public class Processor
{
    private readonly CommandFactory _factory = new();

    public string ProcessCommand(string commandKey, string filePath)
    {
        var command = _factory.GetCommand(commandKey);
        return command.Execute(filePath);
    }
}

In this phase OCP is nearly achieved, as the current design allows us to add new features (commands) with only small changes in existing code—the class CommandFactory will be modified by adding each new command to the dictionary.

4.3. Dynamic command discovery and auto-registration

To fully comply with OCP, we need to eliminate any need to change CommandFactory by using attribute-based discovery and auto-registration using reflection. This approach allow new commands to be discovered and auto-registered, without changing any existing code—achieving complete OCP compliance.

Define CommandKeyAttribute:

[AttributeUsage(AttributeTargets.Class)]
public class CommandKeyAttribute : Attribute
{
    public string Key { get; }
    public CommandKeyAttribute(string key) => Key = key;
}

Decorate each command with CommandKeyAttribute as follows:

[CommandKey("-c")]
public class ByteCountCommand : ICommand { /* Same implementation */ }

[CommandKey("-w")]
public class WordCountCommand : ICommand { /* Same implementation */ }

[CommandKey("-l")]
public class LineCountCommand : ICommand { /* Same implementation */ }

Modify CommandFactory to discover and register commands dynamically:

public class CommandFactory
{
    private readonly Dictionary<string, ICommand> _commands;

    public CommandFactory()
    {
        //>>> This will fetch all the concrete classes that implement ICommand.
        //>>> And then it will filter out those that are not decorated using the CommandKeyAttribute.
        //>>> And then, the remaining commands are stored as key-value pairs in the dictionary.
        //>>> Key: command key (c, l etc.) | Value: object of that commands
        _commands = Assembly
            .GetExecutingAssembly()
            .GetTypes()
            .Where(type => typeof(ICommand).IsAssignableFrom(type) && !type.IsAbstract && type.IsClass)
            .Where(type => type.GetCustomAttribute<CommandKeyAttribute>() is not null)
            .ToDictionary(
                type => type.GetCustomAttribute<CommandKeyAttribute>()!.Key,
                type => (ICommand)Activator.CreateInstance(type)!);
    }

    public ICommand GetCommand(string commandKey)
    {
        if (!_commands.TryGetValue(commandKey, out var command))
        {
            throw new CommandNotFound();
        }

        return command;
    }
}

5. Exercise

Lets test our complete OCP compliance by adding a new command, "-m", which calculates the character count of the text file, as described in the Requirements section.

All we need to do is add a new CharacterCountCommand class that implements ICommand. No existing code modification needed:

[CommandKey("-m")]
public class CharacterCountCommand : ICommand
{
    /* Implementation */
}

6. Conclusion

The OCP is a powerful principle for designing and developing software that are easier to extend with minimal or no code changes to existing codebase.

Step-by-Step OCP application in wc.NET: We transformed a tightly coupled design into a fully flexible one, by:

Separating commands into their own classes.
Using a factory to handle command creation.
Adding attribute-based discovery and reflection to auto-register new commands.

Advantages of following OCP

Easier to Extend: This approach keeps the code easier to extend by writing new code, for new requirements, instead of changing existing parts of the code.
Fewer Bugs: As long as existing code is stable and remains untouched, it is less likely to break and resulting in fewer bugs.

To fully implement OCP, we needed the Single Responsibility Principle (SRP) to keep each command focused.

7. See also

Open-Closed Principle by Wikipedia
The Open-Closed Principle, In Review by Jon Skeet

NOTE: Please fully verify all code snippets before using them, as they may or may not function as shown.

Environment Variables: Naming Conventions and Runtime Access in C# .NET

Vedant Phougat — Thu, 10 Oct 2024 06:07:01 +0000

1. Introduction
2. Why use prefixes for variables?
3. Mapping variables to configuration classes
- 3.1. Define configuration classes
- 3.2. Naming convention
- 3.3. Understanding the use of delimiters
4. Accessing the variables
5. Conclusion
6. See also

1. Introduction

In modern application development, managing configurations—especially sensitive data—is crucial. Hardcoding secrets in your codebase can lead to accidental exposures, so what's the alternative? Environment variables help keep secret configurations out of your code, reducing the risk of accidental exposure. This way you can also change the value of your secrets, without the need to redeploy the application. But for them to be effective, you need a clear approach to naming and accessing these variables.

In this post we will dive into

naming of environment variable keys for:
- Simple properties,
- Complex properties,
- Collection properties, and
- Dictionary properties
adding prefix to environment variables for easy organization
loading them into the application at runtime.

⚠️ Caution

While environment variables help prevent accidental exposure of sensitive data, by separating the secrets from you codebase, they do not provide any additional "security" as explained in this Stackoverflow question.

Storing secrets as plain text has risks like CWE-256. To improve security, consider using services similar to Azure Key-Vault and AWS Secrets Manager to securely retrieve sensitive information at runtime. Read this MSDN post for more details.

2. Why use prefixes for variables?

To avoid naming conflicts: Two applications might use a variable name ConnectionString. By prefixing it with application name/key, ensures that a specific application's variables are unique.
For ease of readability and maintenance: By grouping all the configuration keys related to a specific application together.
Avoid accidentally picking up of variables intended for other applications: By using .AddEnvironmentVariables("MyApp_") in .NET allows the application to load only variables prefixed with MyApp.

3. Mapping variables to configuration classes

3.1. Define configuration classes

Here is a class which will be used to hold the configurations read from the environment variables:

public class AwsConfiguration
{
    private const String SectionKey = "AwsConfiguration";

    public String AccessKey { get; set; }
    public String SecretKey { get; set; }
    public EndpointConfiguration Endpoint { get; set; }
    public List<String> Regions { get; set; }
    public Dictionary<String, String> DetailTypes { get; set; }
}

public class EndpointConfiguration
{
    public String Url { get; set; }
    public Int32 Port { get; set; }
}

3.2. Naming convention

The naming convention for naming the keys in environment variables:

## Simple Properties
MyAwsApp_AwsConfiguration__AccessKey
MyAwsApp_AwsConfiguration__SecretKey

## Nested Properties
MyAwsApp_AwsConfiguration__Enpoint__Url
MyAwsApp_AwsConfiguration__Enpoint__Port

## Collection/Array Properties
MyAwsApp_AwsConfiguration__Region__0
MyAwsApp_AwsConfiguration__Region__1
MyAwsApp_AwsConfiguration__Region__2

## Dictionary Properties
# DetailTypes dictionary will have 2 keys - InProgress & Completed
# after successful binding of these key-value pairs
# to the object of class - AwsConfiguration
MyAwsApp_AwsConfiguration__DetailTypes__InProgress
MyAwsApp_AwsConfiguration__DetailTypes__Completed

## These properties will not be picked by the `.AddEnvironmentVariables("MyAwsApp_")
NOTMyAwsApp_AwsConfiguration__AccessKey
NOTMyAwsApp_AwsConfiguration__SecretKey

3.3. Understanding the Use of Delimiters

The single-underscore (_) is used with the main prefix only, while double-underscore(__) is used for complex properties of the configuration class (described in section 3.1.).

Why not use : as the separator? Because as per MSDN:

The : separator doesn't work with environment variable hierarchical keys on all platforms. For example, the : separator is not supported by Bash. The double-underscore, __, is:

Supported by all platforms.

Automatically replaced by a colon, :.

4. Accessing the variables

One can access the environment variables in Main method of Program class as follows:

public class Program
{
    public static void Main(String[] args)
    {
        var builder = new ConfigurationBuilder()
            //the prefix - "MyAwsApp_" will be removed from the environment variable names
            .AddEnvironmentVariables("MyAwsApp_");
        var configuration = builder.Build();
        var awsConfiguration = configuration
            .GetSection(AwsConfiguration.SectionKey)
            .Get<AwsConfiguration>();
    }
}

The code AddEnvironmentVariables("MyAwsApp_"); will fetch all the variables that are marked with prefix MyAwsApp_, strip this prefix from the variables name and then load them in the application. Consider the following variable MyAwsApp_ConnectionString, it will be loaded into application as ConnectionString.

5. Conclusion

Using clear naming, organized prefixes, and structured mapping for environment variables simplifies application setup. Here are a few advantages:

Better organization: Prefixes group related settings, making them easier to locate.
Avoid naming conflicts: Unique key names created by combining application and configuration name.
Avoid accidental exposure of secret configurations: By keeping the sensitive data separate from the codebase.

6. See also

Applying Single Responsibility Principle to Real-World Code

Vedant Phougat — Tue, 08 Oct 2024 17:06:38 +0000

1. Introduction
2. Requirements
- 2.1. Expected workflow logic
- 2.2. Technical details
3.Development
- 3.1. Initial approach
- 3.2. Initial Orchestrator code
- 3.3. Challenges with initial Orchestrator
4 Identifying separate responsibilities
5. Refactor
- 5.1. Invoice fetching logic
- 5.2. Invoice matching logic
- 5.3. Matched invoice saving logic
6. Exercise
7. Conclusion

1. Introduction

Ever wondered why you found yourself modifying the same class to accommodate unrelated features? Imagine having a class responsible for processing invoices, but over time, it has become the go to class to fix issues related to database queries, business rules, and external API calls. This is a common issue when classes take on multiple responsibilities, leading to code that's difficult to maintain and extend.

This post will provide you with practical insights into identifying, breaking down and refactoring a class – InvoiceMatchOrchestrator, that is performing multiple tasks, by applying Single Responsibility Principle (SRP from here) to a real-world example. First, let's start with the formal definition:

A class should have only one reason to change.

Next we will look at the project requirements that led to our initial approach.

2. Requirements

We are tasked with developing a service to match invoices from two distinct sources, PA and IA, based on specific business logic. This involves fetching invoices from both sources, comparing them according to the matching criteria, and saving the matched invoices back to PA. The goal is to streamline this workflow while keeping the code readable, maintainable and adaptable for future changes.

2.1. Expected Workflow Logic

A class named InvoiceMatchOrchestrator is responsible for managing the invoice matching workflow logic.

What is invoice matching workflow logic?

It is the order of steps – fetching invoices from both data sources, applying business logic to find matches, and saving matched invoices back to PA.

2.2. Technical Details

PA's data source: PostgreSQL, accessed via a Hasura GraphQL layer, which provides a GraphQL API for database interaction.
IA's data source: OpenSearch, used as an external reference source for comparison
Programming language: C#.

3. Development

3.1. Initial Approach

We opt for a quick, all-in-one approach to get the application ready for the demo. This initial approach involves creating a single class called InvoiceMatchOrchestrator that handles the following tasks on its own:

Fetching invoices from PA: Creates and configures an HttpClient instance to connect to PA's data source.
Fetching invoices from IA: Creates and configures an OpenSearchClient instance to connect to IA’s data source.
Matching invoices: Implements business logic to match the invoices from PA and IA.
Saving matched invoices: Saves the matched invoices back to PA using HttpClient.

3.2. Initial Orchestrator Code

After the initial developement phase, the code for InvoiceMatchOrchestrator looks as follows:

public class InvoiceMatchOrchestrator
{
    // This method's job is to orchestrate the invoice matching process
    public ICollection<Int32> ExecuteMatching(Int32 batchId)
    {
        // ------ Fetch invoices from PA ------
        var query_FetchInvoices = "it contains hasura query to fetch invoices";
        var httpClient = new HttpClient();
        // configure httpClient and create the message request using batchId
        var response = httpClient.SendAsync(request);
        // check and parse the response
        var paInvoices = JsonSerializer.Deserialize<List<PaInvoice>>(stringifyJson);

        // ------ Fetch invoices from IA ------
        var openSearchClient = new OpenSearchClient();
        // configure the openSearchClient and create search request using batchId
        var iaInvoices = openSearchClient.Search<List<IaInvoice>>(searchRequest);

        // ------ Find matching invoices ------
        // logic to find the matching invoices

        // ------ Save matching invoices ------
        var mutation_SaveMatches = "it contains hasura query to save invoices";
        // create the save request using matched invoices
        var saveResponse = httpClient.SendAsync(saveRequest);
        // check and parse the response to generate the IDs of the saved result
        return ids;
    }
}

3.3. Challenges with Initial Orchestrator

As development progressed, this initial approach quickly became complex and hard to adapt. With each new requirement, such as:

Saving matched invoices to IA (OpenSearch) in addition to PA.
Adjusting the invoice matching criteria to use a different field, x (abstracted for confidentiality) instead of y.

the InvoiceMatchOrchestrator class required significant code changes, making it increasingly error-prone. This Initial Approach bundled multiple responsibilities within one class, causing any new requirement to impact unrelated parts of the code, thus introducing risks and reducing reliability.

4. Identifying separate responsibilities

With the challenges identified in the Development section, we’ll now focus on refactoring the InvoiceMatchOrchestrator class by applying the SRP. The goal is to make this class perform task that aligns with its name and delegate everything else to specialized classes by clearly separating responsibilities. To determine if a class is handling multiple responsibilities, ask these questions:

What is the primary purpose of the class? In the case of InvoiceMatchOrchestrator, its main job is to manage workflow logic related to invoice matching.
Should this class change when requirements unrelated to the workflow logic are introduced? If the answer is "yes", the class likely has multiple responsibilities or named incorrectly. For InvoiceMatchOrchestrator, any change to data-fetching or saving steps would require updates, even though these tasks aren't part of its main workflow management role.

Using the above-mentioned questions, let’s consider when the InvoiceMatchOrchestrator class should be modified if the following new requirements arise:

How invoices should be fetched from PA? No ❌
How invoices should be fetched from IA? No ❌
How invoices should be matched? No ❌
How matched invoices should be saved to PA? No ❌

These answers confirm that InvoiceMatchOrchestrator should delegate each of these tasks to specialized classes to ensure it adheres to SRP by focusing only on coordinating the invoice matching workflow.

5. Refactor

After the demo, the developer should pause to evaluate how new requirements might impact the InvoiceMatchOrchestrator class. While the initial approach was suitable for meeting the deadline, it's now important to consider whether this design will continue to support future changes efficiently. And if he finds potential issues, like increased complexity or the need for frequent modifications, refactoring is necessary.

It is also part of the developer's role to communicate and explain this to stakeholders, highlighting why time for refactoring is needed, the long-term benefits it offers, and how it will make future changes quicker and easier.

5.1. Invoice fetching logic

Move the invoice fetching logic for each invoice source into separate classes, isolating data retrieval.

Create PaInvoiceService

//-------- Interface --------
public interface IPaInvoiceService
{
    Task<ICollection<PaInvoice>> GetInvoicesForBatchAsync(Int32 batchId);
}

//-------- Implementation --------
public class PaInvoiceService : IPaInvoiceService
{
    public async Task<ICollection<PaInvoice>> GetInvoicesForBatchAsync(Int32 batchId)
    {
        var query = "query to fetch invoices from PA";
        var httpClient = new HttpClient();
        // configure and send the request using batchId
        // parse the response
        return JsonSerializer.Deserialize<List<PaInvoice>>(responseString);
    }
}

Create IaInvoiceService

//-------- Interface --------
public interface IIaInvoiceService
{
    Task<ICollection<IaInvoice>> GetInvoicesForBatchAsync(Int32 batchId);
}

//-------- Implementation --------
public class IaInvoiceService : IIaInvoiceService
{
    public async Task<ICollection<IaInvoice>> GetInvoicesForBatchAsync(Int32 batchId)
    {
        var openSearchClient = new OpenSearchClient();
        // configure and create search request using batchId
        return openSearchClient.Search<List<IaInvoice>>(searchRequest);
    }
}

Create InvoiceMatchOrchestrator

public class InvoiceMatchOrchestrator
{
    private readonly PaInvoiceService _paInvoiceService;
    private readonly IaInvoiceService _iaInvoiceService;

    public InvoiceMatchOrchestrator(
        PaInvoiceService paInvoiceService,
        IaInvoiceService iaInvoiceService
    )
    {
        _paInvoiceService = paInvoiceService;
        _iaInvoiceService = iaInvoiceService;
    }

    public async Task<ICollection<Int32>> ExecuteMatching(Int32 batchId)
    {
        var paInvoices = await _paInvoiceService.GetInvoicesForBatchAsync(batchId);
        var iaInvoices = await _iaInvoiceService.GetInvoicesForBatchAsync(batchId);
        //Matching and saving logic remains here for now
    }
}

5.2. Invoice matching logic

Move the matching logic into a dedicated InvoiceProcessor class.

Create InvoiceProcessor class:

  //-------- Invoice Match Processor --------
  public interface IMatchProcessor
  {
      ICollection<Match> MatchInvoices(
          ICollection<PaInvoice> paInvoices,
          ICollection<IaInvoice> iaInvoices);
  }

  //------ Implementation ------
  public class InvoiceMatchProcessor : IMatchProcessor
  {
      public ICollection<Invoice> MatchInvoices(
          ICollection<PaInvoice> paInvoices,
          ICollection<IaInvoice> iaInvoices)
      {
          //the logic to match the invoices
          return matchedInvoices;
      }
  }

Update InvoiceMatchOrchestrator to use InvoiceProcessor:

public class InvoiceMatchOrchestrator
{
    private readonly PaInvoiceService _paInvoiceService;
    private readonly IaInvoiceService _iaInvoiceService;
    private readonly IMatchProcessor _invoiceMatchProcessor;

    public InvoiceMatchOrchestrator(
        PaInvoiceService paInvoiceService,
        IaInvoiceService iaInvoiceService,
        IMatchProcessor invoiceMatchProcessor
    )
    {
        _paInvoiceService = paInvoiceService;
        _iaInvoiceService = iaInvoiceService;
        _processor = processor;
        _invoiceMatchProcessor = invoiceMatchProcessor;
    }

    public async Task<ICollection<Int32>> ExecuteMatching(Int32 batchId)
    {
        var paInvoices = await _paInvoiceService.GetInvoicesForBatchAsync(batchId);
        var iaInvoices = await _iaInvoiceService.GetInvoicesForBatchAsync(batchId);
        var matchedInvoices = _processor.MatchInvoices(paInvoices, iaInvoices);
        //Saving logic remains here for now
    }
}

5.3. Matched invoice saving logic

Move the saving logic into a InvoiceService class, isolating the save operation.

Create InvoiceService:

  //-------- Matched Invoice Service --------
  public interface IInvoiceService
  {
      Task<ICollection<Int32>> SaveMatchesAsync(ICollection<Invoice> matches);
  }

  public class InvoiceService : IInvoiceService
  {
      public async Task<ICollection<Int32>> SaveMatchesAsync(ICollection<Invoice> matches)
      {
          var query = "mutation query to save matches";
        var httpClient = new HttpClient();
        // configure and send the save request
        return parsedIds; // Parsed from response
      }
  }

Updated InvoiceMatchOrchestrator to use InvoiceService:

public class InvoiceMatchOrchestrator
{
    private readonly IPaInvoiceService _paInvoiceService;
    private readonly IIaInvoiceService _iaInvoiceService;
    private readonly IMatchProcessor _invoiceMatchProcessor;
    private readonly IInvoiceService _invoiceService;

    public InvoiceMatchOrchestrator(
        IPaInvoiceService paInvoiceService,
        IIaInvoiceService iaInvoiceService,
        IMatchProcessor invoiceMatchProcessor,
        IInvoiceService invoiceService)
    {
        _paInvoiceService = paInvoiceService;
        _iaInvoiceService = iaInvoiceService;
        _invoiceMatchProcessor = invoiceMatchProcessor;
        _invoiceService = invoiceService;
    }

    public async Task<ICollection<int>> ExecuteMatching(int batchId)
    {
        // 1. Fetch invoices from PA
        var paInvoices = await _paInvoiceService.GetInvoicesForBatchAsync(batchId);

        // 2. Fetch invoices from IA
        var iaInvoices = await _iaInvoiceService.GetInvoicesForBatchAsync(batchId);

        // 3. Perform invoice matching
        var matchedInvoices = _invoiceMatchProcessor.MatchInvoices(paInvoices, iaInvoices);

        // 4. Save the matched invoices
        var matchedInvoiceIds = await _invoiceService.SaveMatchesAsync(matchedInvoices);
        return matchedInvoiceIds;
    }
}

By isolating each responsibility in dedicated classes, we ensure that changes to one responsibility will only impact the relevant class, not the orchestrator or unrelated functionality.

6. Exercise

Let's say a new requirement is introduced and as per it – the matched invoices must also be saved in IA (OpenSearch) as well. The way this change can be incorporated:

Before refactoring – The InvoiceMatchOrchestrator class will be modified, which will lead to more complexity, making the code harder to maintain, test, and understand.
After refactoring – First, these matched invoices are a collection of type Invoice and InvoiceService is responsible for handling Invoice operations. So, to implement new requirement, we will first create a dedicated client/service – let's call it MyApplicationNameOpenSearchClient – responsible for actually saving data to OpenSearch. This client will then be injected into the InvoiceService, where the SaveMatchAsync method will call both HttpClient and MyApplicationNameOpenSearchClient to save the matched invoices in their respective data stores. Thus leaving the InvoiceMatchOrchestrator untouched.

The key point here is that only the class related to saving the matched invoices is modified and ensuring that the changes are isolated to their specific classes while the overall workflow remains unchanged.

7. Conclusion

So, refactoring the orchestrator class by applying the SRP resulted in cleaner and readable code. By separating concerns – such as fetching invoices from PA and IA, performing the matching logic, and saving the matched invoices – each of these tasks are now handled by their respective classes. This approach allows the orchestrator to manage the workflow logic, while making future modifications easier and less risky.

The refactoring by applying SRP is an ongoing process, other classes within the application, like PaInvoiceService, IaInvoiceService, etc, will be refactored as necessary, depending upon the frequency of changes and needs of the application.

NOTE: Please fully verify all code snippets before using them, as they may or may not function as shown.

DEV Community: Vedant Phougat

Important Links

Table of content

1. ASP.NET

1.1. Authentication & Authorization

1.2. Guidelines

2. ADVANCED .NET

2.1. HttpClient

2.2. Asynchronous programming

2.3. GC

3. .NET PERFORMANCE & PROFILING

3.1. Performance engineering

3.2. Memory and Span

3.3. System.IO.Pipelines

3.4. ArrayPool

3.5. Profiling and Diagnostics

4. REST APIs

5. DISTRIBUTED CLOUD APPLICATION

How to implement IEquatable?

Table of content

1. Introduction

2. What and why of IEquatable<T>?

3. Equality comparison prior to IEquatable<T>

3.1. Value Type (struct)

3.2. Reference Type (class)

3.3. Recommendation

4. User-defined struct implementing IEquatable<T>

4.1. Implementation

4.2. Testing

5. User-defined class implementing IEquatable<T>

5.1. Implementation

5.2. Testing

5.3. When inheritance steps in

6. Conclusion

7. See also

Applying Open Closed Principle to Real-World Code

Table of Contents

1. Introduction

2. Requirements

3. Development

3.1. Challenges of initial approach

4. Refactor

4.1. Move each command to individual classes

4.2. Introduce a factory for command creation

4.3. Dynamic command discovery and auto-registration

5. Exercise

6. Conclusion

7. See also

Environment Variables: Naming Conventions and Runtime Access in C# .NET

Table of contents

1. Introduction

⚠️ Caution

2. Why use prefixes for variables?

3. Mapping variables to configuration classes

3.1. Define configuration classes

3.2. Naming convention

3.3. Understanding the Use of Delimiters

4. Accessing the variables

5. Conclusion

6. See also

Applying Single Responsibility Principle to Real-World Code

Table of contents

1. Introduction

2. Requirements

2.1. Expected Workflow Logic

2.2. Technical Details

3. Development

3.1. Initial Approach

3.2. Initial Orchestrator Code

3.3. Challenges with Initial Orchestrator

4. Identifying separate responsibilities

5. Refactor

5.1. Invoice fetching logic

5.2. Invoice matching logic

5.3. Matched invoice saving logic

6. Exercise

7. Conclusion

2. What and why of `IEquatable<T>`?

3. Equality comparison prior to `IEquatable<T>`

4. User-defined struct implementing `IEquatable<T>`

5. User-defined class implementing `IEquatable<T>`