Hello all, today I back with another C# topic, and today I will share what i learned about C# Asynchronous. I hope with this article you will know more about C# Asynchronous and use it on your project.

What Is It?

Microsoft introduced asynchronous programming in .NET Framework 4.0 to improve the handling of long-running tasks, such as file I/O, network communication, or database operations, without blocking the main thread.

In traditional synchronous programming, operations are executed in a sequential order, meaning one operation must complete before the next one can begin. In contrast, asynchronous programming allows other tasks to run concurrently while waiting for a long-running operation to finish.

Why Implement It?

There are several pros and cons to consider before implement asynchronous in our project. Here are some of them:

Pros

• Enhances application responsiveness during long-running operations.

• Increases application scalability by allowing concurrent task handling.

• Optimizes resource usage by freeing up threads while waiting for tasks.

Cons

• May introduce deadlocks if not managed carefully.

• Can lead to unexpected behavior due to context switching.

• Can make debugging more challenging because of non-linear execution.

How It Works?

To understand how asynchronous work in the system, let's implement it first. In C#, a basic asynchronous operation requires three key components: async, Task, and await.

1. Async

   This modifier is applied to methods to indicate they contain asynchronous operations and allows the method to use the await keyword.

2. Await

   This keyword is used before calling an asynchronous method. It tells the compiler to pause the execution of the current method until the awaited task completes. Importantly, it doesn’t block the thread and lets the program continue executing other tasks while waiting for the asynchronous operation to finish.

3. Task Or Task<T>

   These keywords represent an asynchronous operation. Task is used when the operation doesn’t return a value, and Task<T> is used when the operation returns a value of type T asynchronously.

using System;
using System.Threading.Tasks;

namespace Lncodes.Example.Async;

public sealed class Program
{
    static async Task Main(string[] args)
    {
        await LoadAssetAsync();
    }

    private async Task LoadAssetAsync()
    {
        await Task.Delay(2000);
        Console.WriteLine($"Asset loaded.");
    }
}

In the code above, I have created an asynchronous method that will await 2 seconds before print "Asset loaded." on the console. After implementing an asynchronous method in the code, here's what will happen in the system:

1. When an asynchronous method is called, it doesn't automatically run on a separate thread. Instead, it begins executing synchronously until it reaches the first await keyword.

2. When the await keyword is encountered, the method is divided into two parts. The code before await runs immediately, while the code after await is delayed and executes later as a continuation (or callback) once the awaited operation completes (e.g., await Task.Delay(2000)).

3. When the operation of await is running, the system will handle the threading differently. If the operation is I/O-bound (e.g., database query, file reading, or web request), the operation is sent to the OS kernel to allow it to communicate with the hardware (e.g., network card or disk controller). However, if the operation is CPU-bound (e.g., heavy calculations), it will be sent to another thread in the thread pool.

4. Once the awaited operation completes, the Task Scheduler ensures the continuation executes in the correct context. If a SynchronizationContext is present (such as in a UI or ASP.NET application), it ensures the continuation is synchronized and runs in the appropriate context (e.g., back on the main thread) to prevent race conditions.

Console Application

In my console application, I use an asynchronous approach to create a game asset loader. This implementation ensures that assets like textures and audio files load without blocking the main thread. It also includes a cancellation feature, allowing the loading process to be stopped when necessary.

Below is a list of the classes I used to create this console application, along with a brief explanation of each class:

In the video above, the console application displays the asynchronous loading process of game assets, including textures and audio files, and shows how the process can be canceled midway.

Additional Information

I have discovered some additional information about C# Asynchronous. If you have any additional information regarding C# Asynchronous that you'd like to share, please feel free to leave a comment.

Naming Guidelines

When implementing asynchronous, following specific naming guidelines can help ensure code readability and consistency. Here are some naming conventions recommended by Microsoft:

• Do use 'Async' suffix for asynchronous method e.g. TimerAsync, PushDataAsync, etc.

Further Discoveries

Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of C# Asynchronous:

• Avoid using .Result or .Wait() to get results from a Task, as they can cause deadlocks. A better approach is to use await, which allows asynchronous code to run without blocking the current thread. Deadlocks are particularly problematic in UI applications and other scenarios where maintaining thread responsiveness is essential.

• The ConfigureAwait(false) method can be used to improve the performance of asynchronous operations by preventing the continuation from capturing the original synchronization context. However, be cautious, as it may cause issues if your code depends on running on a specific thread, such as when updating the UI in desktop applications.

• Avoid using async void, as it can lead to race conditions by allowing the calling code to continue without waiting for the asynchronous method to finish. Use async void only in cases where awaiting the method’s completion is unnecessary. In all other situations, prefer returning a Task or Task<T> to handle asynchronous operations more effectively.

• Before .NET 4.5, Task.Factory.StartNew() was commonly used to create and start tasks with flexible configurations. However, starting with .NET 4.5, Task.Run() became the preferred option for simpler task creation and execution, as it runs tasks on the ThreadPool by default without needing additional configuration, unlike Task.Factory.StartNew().

• A CancellationToken is used to signal and manage cancellation requests in asynchronous operations, allowing them to be interrupted or stopped before they complete.

• A ValueTask can be used instead of a Task in asynchronous methods where the operation might complete synchronously or when the result can be produced without needing to await any operations.

Reference

1. C# Asynchronous – Microsoft

2. Synchronization Context – Microsoft

3. Deep Dive C# Asynchronous – NDC Conferences

Hello all, today I back with another Design Patterns topic, and today I will share what i learned about Facade design pattern. I hope with this article you will know more about Facade design pattern and use it on your project.

What It Is?

The Facade design pattern is a structural pattern that simplifies access to a complex subsystem by providing a unified, high-level interface for the client. This pattern hides the internal details of the subsystems from the client, making it easier for the client to interact with the subsystems.

When To Use It?

Here are some scenarios where implementing the Facade design pattern can be beneficial to a project:

• When the client needs a simple way to access complex subsystems.

• When there’s a need to decouple the client from the subsystems.

• When it’s important to reduce dependencies between the client and the subsystems.

• When the client needs to access several related parts of subsystems through a single access point.

Why Implement It?

Here are some pros and cons to consider before implementing the Facade design pattern in a project:

Pros

• Reduces the complexity of client code by unifying the interface that interacts with multiple subsystems.

• Decouples the client code from the internal details of the subsystems, making it easier to change subsystem implementations without changing the client code.

• Reduces the number of dependencies for the client, as it only interacts with a single facade instead of multiple subsystems.

• Improves readability by hiding unnecessary details of the subsystem in the client’s code.

• Enhances scalability by allowing new features to be added to the facade without modifying the existing subsystem classes.

Cons

• Might become a "God Object" if it manages too many subsystems, making the system harder to maintain and violating the Single Responsibility Principle.

• Might make debugging and extending the system challenging if it hides too much of the underlying complexity.

• Might create a single point of failure that affects the entire system if it fails, as it often acts as the only access point to subsystems.

• Might reduce flexibility for the client if it is designed to restrict direct access to subsystem components, which could limit the use of certain features or functionalities of the subsystems.

How To Implement It?

Here are the steps to implement the Facade design pattern in a project:

1. Identify the complex subsystem operations that the client needs to simplify.

2. Create a facade class that acts as a middle layer between the client and the subsystems.

3. In the facade class, create high-level methods that perform multiple subsystem operations.

4. In the client, use the facade class to replace all the subsystem operations.

Structure

Pseudocode

BEGIN CLASS SubsystemA
    BEGIN PUBLIC PROCEDURE operationA()
        PRINT "Running SubsystemA Operation"
    END PROCEDURE
END CLASS

BEGIN CLASS SubsystemB
    BEGIN PUBLIC PROCEDURE operationB()
        PRINT "Running SubsystemB Operation"
    END PROCEDURE
END CLASS

BEGIN CLASS SubsystemC
    BEGIN PUBLIC PROCEDURE operationC()
        PRINT "Running SubsystemC Operation"
    END PROCEDURE
END CLASS

BEGIN CLASS Facade
    PRIVATE FIELD subsystemA = new SubsystemA()
    PRIVATE FIELD subsystemB = new SubsystemB()
    PRIVATE FIELD subsystemC = new SubsystemC()

    BEGIN PUBLIC PROCEDURE execute()
        subsystemA.OperationA()
        subsystemB.OperationB()
        subsystemC.OperationC()
    END PROCEDURE
END CLASS

BEGIN CLASS Client
    BEGIN PRIVATE PROCEDURE useFacade()
        FIELD facade = new Facade()
        facade.Execute()
    END PROCEDURE
END CLASS

Additional Information

I have discovered some additional information about Facade design pattern. If you have any additional information about Facade design pattern that you'd like to share, please feel free to leave a comment.

Facade Design Pattern VS Adapter Design Pattern

Both Facade and Adapter design patterns have similar code structures. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:

• The Facade design pattern focuses on simplifying the interaction with complex subsystems by providing a unified interface, while the Adapter design pattern focuses on making two incompatible interfaces work together by providing a translation layer between them.

• The Facade design pattern usually works with a set of classes or an entire subsystem, whereas the Adapter design pattern works with a single class or component.

Further Discoveries

Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of Facade design pattern:

• The Facade design pattern doesn't require the client to use every operation in the subsystem because it only wraps the essential operations.

• The Facade design pattern is often used in libraries and frameworks to provide a simplified interface for the user.

• The Facade design pattern can be combined with the Singleton design pattern, especially when the facade represents a global point of access for various subsystems.

• The Facade design pattern can be used to manage security features by controlling access to specific subsystems.

• The Facade design pattern can act as a boundary between different layers in a layered architecture. For example, it can act as a boundary between the presentation layer and the business logic layer to simplify their interaction.

• The Facade design pattern doesn't change the behavior of the subsystems but simply provides a simplified interface to them.

• The Facade design pattern makes unit testing easier by simplifying the subsystems' interface, allowing tests to focus on the simplified interface instead of multiple subsystems.

Reference

1. Facade Design Pattern – Sourcemaking

2. Facade Design Pattern – Refactoring.guru

Hello all, today I back with another Design Patterns topic, and today I will share what i learned about Adapter design pattern. I hope with this article you will know more about Adapter design pattern and use it on your project.

What It Is?

The Adapter design pattern is a structural pattern that allows objects with incompatible interfaces to work together. It acts as a bridge between incompatible interfaces by making one interface compatible with another.

When To Use It?

Here are some scenarios where implementing the Adapter design pattern can be beneficial to a project:

• When two or more classes or systems with incompatible interfaces need work together.

• When there’s a need to integrate new components with legacy code that uses different or outdated interfaces.

• When there’s a need to use a third-party library or external service that doesn't match the design of the current system.

• When the existing code can’t be modified but still needs to work with the new system.

Why Implement It?

Here are some pros and cons to consider before implementing the Adapter design pattern in a project:

Pros

• Increases compatibility by allowing systems with incompatible interfaces to work together without modifying their source code.

• Adheres to the Single Responsibility Principle by isolating interface-related logic within the adapter classes.

• Adheres to the Open-Closed Principle by enabling the creation of new adapters without modifying the existing system's code.

• Increases scalability by allowing seamless integration of new components or systems without modifying existing code.

Cons

• Increases complexity by adding an adapter layer to the system, which can make debugging and maintaining the code more difficult.

• May require constant maintenance if the interface of the adapted class changes regularly.

How To Implement It?

Here are the steps to implement the Adapter design pattern in a project:

1. Identify the existing class (Adaptee) that has an incompatible interface with the current system.

2. Create an interface or abstract class that has a compatible interface with the current system.

3. Create an adapter class that implements the interface or abstract class.

4. Create a field in the adapter class to store a reference to the existing class (Adaptee) so the adapter can access the existing class's incompatible interface.

5. Implement the methods defined in the interface or abstract class in the adapter class. Within these methods, call the corresponding methods (The incompatible interface) of the existing class (Adaptee) to make it compatible with the current system.

6. Use the adapter class in the client to interact with the existing class (Adaptee) seamlessly.

Structure

Pseudocode

BEGIN CLASS Adaptee
    BEGIN PUBLIC FUNCTION getSpecificRequest()
        RETURN "Specific request."
    END FUNCTION
END CLASS

BEGIN INTERFACE IAdapter
    FUNCTION getRequest(): string
END INTERFACE

BEGIN CLASS Adapter IMPLEMENTS IAdapter
    PRIVATE FIELD adaptee

    BEGIN PUBLIC CONSTRUCTOR Adapter(adaptee)
        this.adaptee = adaptee
    END CONSTRUCTOR

    BEGIN PUBLIC FUNCTION getRequest()
        return adaptee.getSpecificRequest()
    END FUNCTION
END CLASS

BEGIN CLASS Client
    BEGIN PRIVATE PROCEDURE useAdapter()
        FIELD adaptee = new Adaptee()
        FIELD iAdapter = new Adapter(adaptee)
        FIELD result = iAdapter.getRequest()
    END PROCEDURE
END CLASS

Additional Information

I have discovered some additional information about Adapter design pattern. If you have any additional information about Adapter design pattern that you'd like to share, please feel free to leave a comment.

Adapter Design Pattern VS Facade Design Pattern

Both Adapter and Facade design patterns have similar code structures. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:

• The Adapter design pattern focuses on making two incompatible interfaces work together by providing a translation layer between them, while the Facade design pattern focuses on simplifying the interaction with complex subsystems by providing a unified interface.

• The Adapter design pattern usually works with a single class or component, whereas the Facade design pattern works with a set of classes or an entire subsystem.

Adapter Design Pattern VS Decorator Design Pattern

Both Adapter and Decorator design patterns have similar code structures. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:

• The Adapter design pattern focuses on making two incompatible interfaces work together by providing a translation layer between them, while the Decorator design pattern focuses on adding new functionality to objects.

• The Adapter design pattern usually works with a single class or component (One adapter per one incompatible interface), whereas the Decorator design pattern often involves stacking multiple decorators to add several layers of functionality.

Further Discoveries

Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of Adapter design pattern:

• The Adapter design pattern can be implemented using either inheritance (extending the Adaptee class) or composition (using an object reference inside the adapter). Composition is generally preferred because it avoids tightly coupling between the adapter and the Adaptee class.

• The Adapter design pattern doesn't have to implement all methods from the target interface, instead it only needs to "adapt" the necessary methods of the Adaptee class to ensure compatibility with the current system.

• The Adapter design pattern can be combined with the Facade design pattern to provide a simpler interface for the client to interact with multiple adaptees.

• The Adapter design pattern can be combined with the Decorator design pattern to add extra functionality to an adaptee without changing its core structure.

Reference

1. Adapter Design Pattern – Sourcemaking

2. Adapter Design Pattern – Refactoring.guru

Hello all, today I back with another Design Patterns topic, and today I will share what i learned about Builder design pattern. I hope with this article you will know more about Builder design pattern and use it on your project.

What It Is?

The Builder design pattern is a creational pattern that provides a way to construct complex objects step by step. Builder design pattern allows us to reuse the same construction steps to build different types of the object, It decouples the object construction logic from the object representation.

When To Use It?

Here are some scenarios where implementing the Builder design pattern can be beneficial to a project:

• When constructing an object requires multiple steps, configurations, or optional parameters, making direct construction complex and inefficient.

• When improving code readability is necessary, as the pattern decouples object construction logic from its representation.

• When there is a need to constructing immutable objects that require all attributes to be set during their initialization.

• When there is a need to constructing different variations of an object using the same construction process.

Why Implement It?

Here are some pros and cons to consider before implementing the Builder design pattern in a project:

Pros

• Makes complex object construction easier to understand.

• Ensures consistent object construction across the application.

• Decouples the construction logic from the business logic of the object.

• Makes it easy to add new attributes or configurations without modifying existing code.

Cons

• Increases code complexity by introducing additional classes and methods.

• Might cause minor performance issues when used to create simple objects.

• Can lead to tight coupling between the pattern and the objects it constructs.

How To Implement It?

Here are the steps to implement the Builder design pattern in a project:

1. Define the product class that needs to be constructed.

2. Define an interface or abstract class with methods to build the parts of the product.

3. Implement the builder interface or abstract class into concrete builder class with methods and construct the product steps by steps.

4. Create a director class isolates the construction process from the client.

5. In the client code, instantiate the director to construct the product and retrieve the final result.

Structure

Pseudocode

BEGIN CLASS Product
    PUBLIC FIELD partA
    PUBLIC FIELD partB
    PUBLIC FIELD partC

    BEGIN PUBLIC CONSTRUCTOR Product(partA, partB, partC)
        this.partA = partA
        this.partB = partB
        this.partC = partC
    END CONSTRUCTOR
END CLASS

BEGIN INTERFACE IBuilder
    PUBLIC PROCEDURE setPartA()
    PUBLIC PROCEDURE setPartB()
    PUBLIC PROCEDURE setPartC()
    PUBLIC FUNCTION build(): Product
END INTERFACE

BEGIN CLASS ConcreteBuilder IMPLEMENTS IBuilder
    PRIVATE FIELD partA
    PRIVATE FIELD partB
    PRIVATE FIELD partC

    BEGIN PUBLIC PROCEDURE setPartA()
        partA = "PartA"
    END PROCEDURE 

    BEGIN PUBLIC PROCEDURE setPartB()
        partB = "PartB"
    END PROCEDURE

    BEGIN PUBLIC PROCEDURE setPartC()
        partC = "PartC"
    END PROCEDURE

    BEGIN PUBLIC FUNCTION build()
        RETRUN new Product(partA, partB, partC)
    END FUNCTION
END CLASS

BEGIN CLASS Director
    PRIVATE FIELD builder: IBuilder

    BEGIN PUBLIC CONSTRUCTOR Director(builder: IBuilder)
        this.builder = builder
    END CONSTRUCTOR

    BEGIN PUBLIC PROCEDURE setBuilder(builder: IBuilder)
        this.builder = builder
    END PROCEDURE 

    BEGIN PUBLIC FUNCTION construct()
        iBuilder.setPartA()
        iBuilder.setPartB()
        iBuilder.setPartC()
        RETRUN iBuilder.build();
    END FUNCTION
END CLASS

BEGIN CLASS Client
    BEGIN PRIVATE PROCEDURE useBuilder()
        FIELD builder = new ConcreteBuilder()
        FIELD director = new Director(builder)
        FIELD result = director.construct()
    END PROCEDURE
END CLASS

Additional Information

I have discovered some additional information about Builder design pattern. If you have any additional information about Builder design pattern that you'd like to share, please feel free to leave a comment.

• The Builder design pattern can be combined with Singleton Design Pattern to make the builder accessible throughout the system.

• The Builder design pattern can be combined with the Fluent Interface design pattern to simplify the construction steps, making the code easier to read and maintain, especially when constructing complex objects.

• The Builder design pattern is often used to construct objects of classes that have many constructor parameters (usually more than three). However, it’s a good idea to first check if the class can be simplified, as having too many parameters might indicate that the class is too complex or violates the Single Responsibility Principle (SRP).

Reference

1. Builder Design Pattern – Sourcemaking

2. Builder Design Pattern – Refactoring.guru

Hello all, today I back with another Design Patterns topic, and today I will share what i learned about Singleton design pattern. I hope with this article you will know more about Singleton design pattern and use it on your project.

What It Is?

The Singleton design pattern is a creational pattern that ensures a class has only one instance throughout the application's lifecycle. By providing global access to this instance, the pattern allows developers to easily retrieve and use the same instance whenever needed.

When To Use It?

Here are some scenarios where implementing the Singleton design pattern can be beneficial to a project:

• When a single access point is essential for managing a shared resource or configuration, the Singleton design pattern ensures that only one instance is created and accessed throughout the application.

• When multiple components need to access and share the same state or resource, such as a database connection or configuration setting, the Singleton design pattern provides a consistent and controlled way to manage that shared resource.

• When managing limited resources, such as a thread pool or connection pool, the Singleton design pattern ensures efficient resource allocation while preventing resource exhaustion.

Why Implement It?

Here are some pros and cons to consider before implementing the Singleton design pattern in a project:

Pros

• Guarantees only one instance of a class exists, avoiding conflicts or duplication.

• Provides a single point of access to the instance across the application.

• Simplifies the handling of shared global state within the application.

• Reduces resource consumption by avoiding multiple instances.

Cons

• Violates the Single Responsibility Principle.

• Can lead to race conditions in multi-threaded environments.

• Can lead to hidden dependencies and make the code harder to maintain.

• Can lead to tight coupling between components, making the code less flexible and harder to modify.

How To Implement It?

Here are the steps to implement the Singleton design pattern in a project:

1. Create a private constructor for the Singleton class to prevent other classes from creating instances of the Singleton class.

2. Create a private static variable that will hold the instance of the Singleton class to ensures that only one instance exists.

3. Create a public static method that returns the instance of the Singleton class. This method should check if the instance is null and create a new instance if it’s null to ensure controlled access to the single instance.

Structure

Pseudocode

BEGIN CLASS Singleton
    PRIVATE STATIC FIELD instance : Singleton

    BEGIN PRIVATE CONSTRUCTOR Singleton
    END CONSTRUCTOR

    BEGIN PUBLIC STATIC FUNCTION getInstance()
        IF instance is null then
            instance = new Singleton()
        END IF
        RETURN instance
    END FUNCTION
END CLASS

BEGIN CLASS Client
    BEGIN PROCEDURE UseSingleton()
        FIELD instance = Singleton.getInstance()
    END PROCEDURE
END CLASS

Additional Information

I have discovered some additional information about Singleton design pattern. If you have any additional information about Singleton design pattern that you'd like to share, please feel free to leave a comment.

Initialization Types

In the Singleton design pattern, the choice of initialization strategy plays a crucial role in determining when and how the instance is created. Here are the initialization types of the Singleton design pattern:

1. Eager Initialization
   In this type of initialization, the Singleton instance is created as soon as the class is loaded into memory. This approach ensures that the instance is readily available whenever needed, which can be beneficial in applications where immediate access to the instance is required, or when the overhead of delayed instantiation is not acceptable.

2. Lazy Initialization
   In this type of initialization, the Singleton instance is created only when it is first accessed. This approach ensures that the instance is instantiated only when it truly needed, which can be beneficial to reduce resource usage.

Singleton Design Pattern VS Static Class

Both Singleton design pattern and static classes provide similar functionality by ensuring that only a single instance can be created throughout the application's lifecycle. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:

• A Singleton can only create one instance throughout the application lifecycle, whereas a static class cannot create any instances at all.

• A Singleton can have both static and non-static members, while a static class can only contain static members.

• A Singleton can maintain state through instance variables, while a static class can only maintain state through static fields.

• A Singleton can from another class or implement interfaces, while a static class cannot inherit from any class or implement interfaces.

Further Discoveries

Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of Singleton design pattern:

• The Singleton design pattern can be combined with other design patterns, such as Abstract Factory, Builder, Facade, or Prototype.

• When implementing the Singleton design pattern in a multithreaded environment, it’s important to consider thread safety. Techniques such as double-checked locking and using static constructors can help ensure that the Singleton instance remains thread-safe.

• Some programming languages offer built-in classes or mechanisms for implementing lazy initialization. For example, in C#, the Lazy<T> class can be used to achieve lazy initialization.

• Using dependency injection frameworks can provide a more flexible way to manage dependencies compared to traditional Singleton implementations.

Reference

1. Singleton Design Pattern – Sourcemaking

2. Singleton Design Pattern – Refactoring.guru

Hello all, today I back with another C# topic, and today I will share what i learned about C# Generic. I hope with this article you will know more about C# Generic and use it on your project.

What It Is?

Introduced in C# 2.0, generic provide a placeholder mechanism for defining types in classes, interfaces, or methods that can be replaced with specific types as needed, such as int, float, or string. These placeholders, known as type parameters, allow the same code to work with different data types while maintaining type safety.

Why Implement It?

There are several pros and cons to consider before implement a generic in our project. Here are some of them:

Pros

• Enhance code reusability.

• Reducing runtime errors related to type mismatches.

• Reduce the need to boxing and unboxing by enabling operations on value types directly.

Cons

• Could potentially increase code size.

• It may be challenging for new programmers to understand.

• Could potentially impact performance because the Just-In-Time (JIT) compiler generates specific code for each generic type.

How It Works?

To understand how generic work in the system, let's implement it first. To implement a generic, all you need to do is add <T> after the method or class name, as shown in the code below:

namespace Lncodes.Example.Generic;

public sealed class QuizController<TQuestion, TCorrectAnswer>
{
    private readonly TQuestion _question;
    private readonly TCorrectAnswer _correctAnswer;

    public QuizController(TQuestion question, TCorrectAnswer correctAnswer) =>
       (_question, _correctAnswer) = (question, correctAnswer);
}

In the code above, I created a generic QuizController class with generic variables named _question and _correctAnswer. By using generic, I can customize the _question and _correctAnswer variable types as needed. After implementing generic, here's what happens in the system:

1. When a generic type is defined using a specific reference type, the compiler sets up the generic class with a flexible type parameter. For example, if a QuizController<T> class is defined with the int type, the compiler prepares the class for this specific type in Microsoft Intermediate Language (MSIL).

2. When a specific generic class is prepared and the program is running, the Just-In-Time (JIT) compiler generates a specialized version of the generic type. For example, if QuizController<T> is instantiated with the int type, the JIT compiler creates a QuizController<int> class at runtime.

3. When a generic type is initialized with previously used type parameters, the system reuses the specialized version of the generic type that was already created by the JIT compiler. This reuse reduces the amount of generated code by minimizing the number of specialized classes created by the JIT compiler.

4. When assigning a type to a generic, the system by default allows any type to be assigned. However, adding a constraint limits which types can be used. To add a constraint, use the where keyword after the class name. For example, in QuizController where TAnswer : List, the TAnswer type must be a List or any class that inherits from List.

Console Application

In my console application, I use generic for my QuizController class, allowing me to customize the types of question, answer, and choices based on my needs.

Below is a list of the classes I used to create this console application, along with a brief explanation of each class:

In the video above, the console application demonstrates three quiz variations, each using different data types for the answers and choices. All of these variations are managed by a single generic class called QuizController.

By using generic, handling different data types within a single class is greatly simplified. Instead of creating multiple versions of a class to accommodate different data types, a single generic class can be used to handle any type. This flexibility ensures that the code remains cleaner, more consistent, and easier to maintain over time, while also reducing the complexity of managing similar classes.

Additional Information

I have discovered some additional information about C# Generic. If you have any additional information about C# Generic that you'd like to share, please feel free to leave a comment.

Naming Guidelines

When implementing generics, following specific naming guidelines can help ensure code readability and consistency. Here are some naming conventions recommended by Microsoft:

• Do use a 'T' prefix with descriptive names for generic type parameters, e.g. QuizController<TQuestion>.

• Consider using the single character 'T' for generic type parameters when there is only one type parameter, e.g. QuizController<T>.

• Consider using names that indicate the constraints of generic type parameters when the generic has constraints, e.g. QuizController<TChoicesCollection> where TChoicesCollection : ICollection.

Further Discoveries

Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of C# Generic:

• Use generic instead of object or dynamic types whenever possible. Object requires boxing and unboxing processes, and dynamic requires runtime type resolution processes, both of which can lead to performance issues. Generic avoid these issues by removing the need for boxing, unboxing, and runtime type resolution, leading to better performance.

  ℹ

  Boxing is the process of converting a value type, such as int, float, or char, into an object type. Unboxing is the process of converting an object type into a value type.
  ℹ

  Runtime type resolution is the process of checking the actual type of a variable, determining its specific type at runtime, and performing operations based on this type to ensure type safety.

• A generic method can be called without explicitly specifying the type parameter. For example, a generic method CheckAnswer<int>(int answer) can be invoked using CheckAnswer(1) instead of CheckAnswer<int>(1). The compiler automatically infers the type parameter based on the provided argument.

• A reflection can be used to get information about generic type at the runtime.

  💡

  To learn more about C# Reflection, check out my post at C# Reflection - Last Night Codes.

Reference

1. C# Generic – Microsoft

2. C# Generic Constraints – Microsoft

3. C# Generic Naming Guidelines - Microsoft

4. Pros And Cons Using C# Generic – Microsoft

Hello all, today I back with another C# topic, and today I will share what i learned about C# Reflection. I hope with this article you will know more about C# Reflection and use it on your project.

What It Is?

Reflection is a powerful feature that allows programs to inspect and interact with the metadata and structure of assemblies at runtime. It provides detailed information about a type, such as the names of constructors, fields, methods, and properties of a class. Additionally, reflection enables dynamic operations, such as creating class instances, modifying field values, instantiating generic types, and invoking methods.

Why Implement It?

There are several pros and cons to consider before implement reflection in our project. Here are some of them:

Pros

• It can be used to access private methods and members of a class, which is useful for unit testing and debugging.

• It can be used to build flexible systems like plugins, where types can be loaded and used easily.

Cons

• Could potentially increase code complexity.

• It may be challenging for new programmers to understand.

• It can pose security risks by revealing internal implementation details and sensitive data, as it can be used to access the private or protected members of a class.

• It can impact performance, especially in performance-critical applications, due to the overhead of runtime type inspection and dynamic invocation.

How It Works?

To understand how reflection works in the system, let's see how to use it. To use reflection in the code, import the System.Reflection namespace. In this implementation, reflection is used to create an instance of a class with Activator.CreateInstance<>, retrieve field values with .GetType() and .GetField(), and invoke methods using .Invoke(), as shown in the code below:

using System.Reflection;

namespace Lncodes.Example.Reflection;

public static class Program
{
    static void Main()
    {
        var abilityInstance = Activator.CreateInstance<BaneAbilityController>();
        FieldInfo[] fieldInfoCollection = abilityInstance.GetType().GetFields();
        MethodInfo[] methodInfoCollection = abilityInstance.GetType().GetMethods();

        foreach (var item in fieldInfoCollection)
            Console.WriteLine(item.GetValue(abilityInstance));

        foreach (var item in methodInfoCollection)
            item.Invoke(abilityInstance, null);
    }
}

In the code above, reflection is used to dynamically create an instance of the BaneAbilityController class, display all its field information, and invoke all its methods. Here's what will happen in the system once implementing reflection:

1. Obtaining the Type object is a crucial step in accessing the metadata of a type when using reflection. This can be done using methods like Assembly.GetType() or Type.GetType(). Once the Type object is obtained, it provides detailed information about the type, enabling the system to dynamically inspect and manipulate its members.

2. After obtaining a Type object, reflection methods like GetField(), GetMethod(), or GetProperties() can be used to inspect its members. These methods create FieldInfo, MethodInfo, or PropertyInfo objects, which provide details about the type’s members, including their names, types, access modifiers, and custom attributes.

3. After obtaining MethodInfo objects, the <info>.Invoke() method can be used to invoke the method. before invoking the method, the system verifies that the method is safe to call by ensuring the arguments are correct and that the method has the required security permissions to be invoked.

4. After obtaining FieldInfo or PropertyInfo objects, the <info>.GetValue() method can be used to retrieve the value of the field or property. Before retrieving the value, the system checks if the field or property is static, ensures that the type of the object matches, and verifies that the access modifier allows access to retrieve the value.

5. The Activator.CreateInstance() method can be used to dynamically create instances of types. Before creating an instance, the system checks if the type can be instantiated, selects the appropriate constructor, and verifies that the constructor is suitable for creating the instance.

Console Application

In my console application, I use reflection to create instances, retrieve field information, invoke methods, and check if a field has a specific attribute in the ability hero classes. Each hero ability classes has unique field information and unique methods name and implementation.

Below is a list of the classes I used to create this console application, along with a brief explanation of each class:

In the video above, the console application displays detailed information for each hero ability class. It shows the class name, field names with their values, and method names with their outputs. Additionally, fields marked with an 'Ignore' attribute will have their values hidden. All this information is gathered using reflection at runtime.

By using reflection, inspecting and interacting with type metadata at runtime becomes easier. Reflection provides access to the type information such as class names, field names, and method names, even when the types are not known at compile time. Reflection makes the code more adaptable to a variety of types encountered during runtime.

Additional Information

I have discovered some additional information about C# Reflection. If you have any additional information regarding C# Reflection that you'd like to share, please feel free to leave a comment.

Reflection Performance Tips

Reflection can significantly affect performance by dynamically inspecting and interacting with a type and its members at runtime. To enhance efficiency and minimize these performance costs, consider the following practical tips:

• Use reflection only on the specific parts of a type or assembly that are needed. This helps reduce the amount of metadata the system needs to inspect and process.

• Avoid using BindingFlags.IgnoreCase as it can potentially cause performance overhead. When this flag is used, the system needs to perform additional process by converting the member names of a type to a common letter case before comparing them.

• Use BindingFlags.ExactBinding whenever the argument type matches the method parameter type. When this flag is used, the system will throw an error immediately if the argument types don't match, which improves performance by bypassing the type coercion process.

  ℹ

  Type coercion is a process that changes one data type into another. This can occur either implicitly, where the conversion happens automatically, or explicitly, where the programmer specifies the conversion.

• Avoid using Type.InvokeMember because it is often less efficient and harder to maintain compared to specialized reflection methods. For better performance, clarity, and type safety, it's recommended to use dedicated methods like MethodInfo.Invoke, PropertyInfo.GetValue, or FieldInfo.GetValue.

Further Discoveries

Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of C# Reflection:

• The BindingFlags enumeration is used to determines which information want to retrieved from reflection. For example, using typeof(<class>).GetMethods(BindingFlags.Public) will return only the methods with a public access modifier from the specified class.

• Reflection can make typed programming languages, such as C# or Java, behave more like dynamic languages by allowing code inspection and manipulation at runtime.

• Use reflection wisely, as it breaks principles of typed programming languages, such as encapsulation and abstraction. It can bypass access restrictions and make the code more difficult to maintain.

• Since C# 6, the nameof keyword offers a more efficient way to obtain names for fields, methods, properties, and other code elements compared to reflection. For example, nameof(abilityInstance.Cooldown) is better than abilityInstance.Cooldown.GetType().Name for retrieving the field name.

• Since C# 6, the nameof keyword provides a more efficient alternative for obtaining field names compared to reflection. For example, use nameof(abilityInstance.Cooldown) rather than abilityInstance.Cooldown.GetType().Name to get the field name.

• Use expression trees instead of reflection for tasks that involve dynamic code creation and execution. Expression trees provide better performance and type safety by allowing code to be compiled and optimized at runtime, unlike reflection, which depends on inspecting metadata at runtime.

• Accessing metadata can increase the working set, leading to higher memory usage and more frequent memory allocations. This can result in more frequent garbage collection events to to handle the extra memory usage.

  ℹ

  Working set refers to the amount of memory a program is currently using. A larger working set means the program is using more memory.

Reference

1. C# Reflection – Microsoft

2. Binding Flags – Microsoft

3. Deep Dive C# Reflection – Microsoft

Hello all, today I back with another C# topic, and today I will share what i learned about C# Delegate. I hope with this article you will know more about C# Delegate and use it on your project.

What Is It?

A delegate is a type that holds a reference to one or more methods. As a 'method holder', it enables methods to be stored and called dynamically, making it ideal for callbacks and event-driven programming.

Why Implement It?

There are several pros and cons to consider before implement an delegate in our project. Here are some of them:

Pros

• Enhance code reusability.

• Enhance the clarity of the code flow.

• Minimize dependencies on other classes.

Cons

• It may be challenging for new programmers to understand.

• Having too many methods assigned to a delegate could potentially cause performance overhead.

How It Works?

To understand how delegate work in the system, let's implement it first. To implement a delegate, all you need to do is use delegate keyword. However, starting .NET Framework 3.5, you can also use an Action, Func or Predicate keywords which are found in the System namespace, as shown in the code below:

using System;

namespace Lncodes.Example.Delegate;

public sealed class InventoryController
{
    private readonly bool _isReachMaxInventoryCapacity = false;

    public void AddItem(Action successAddCallback, Action failAddCallback)
    {
        Console.WriteLine("Adding Item");
        if (_isReachMaxInventoryCapacity) failAddCallback();
        else successAddCallback();
    }
}

public static class Program
{
    private static void Main()
    {
        var inventoryController = new InventoryController();
        inventoryController.AddItem(SuccessAddCallback, FailAddCallback);
    }

    private static void SuccessAddCallback() =>
        Console.WriteLine("Successfully added item to the inventory.");

    private static void FailAddCallback() =>
        Console.WriteLine("Failed to add item to inventory as it has reached its maximum capacity.");
}

In the code above, I have created delegates as parameters of the AddingItem() method. These delegates are used as callbacks that get invoked every time an item is successfully added to the inventory or if it fails to be added. After implementing these delegates in the code, here's what will happen in the system:

1. When a method is assigned to a delegate, the delegate holds a reference to that method.

2. When assigning a method to a delegate, the method’s parameters and return type must exactly match the delegate’s, or it will cause a compiler error.

3. When a delegate is called, it calls all the methods assigned to it sequentially.

Console Application

In my console application, delegates are used to manage callbacks for inventory actions. Whenever an item is added or removed from the inventory, a delegate is called to handle the action.

Below is a list of the classes I used to create this console application, along with a brief explanation of each class:

In the video above, the console application displays four different statuses after adding or deleting items in the inventory. Each status represents the use of a different type of delegate. Below is a list of all the delegate types used in this console application, along with a brief explanation of each delegate:

By using delegates, managing and handling inventory action callbacks becomes more efficient. Different delegate types for various inventory action callbacks enhance code clarity and ensure type safety. They also make the code more flexible and easier to maintain.

Additional Information

I have discovered some additional information about C# Delegate. If you have any additional information regarding C# Delegate that you'd like to share, please feel free to leave a comment.

Naming Guidelines

When implementing delegates, following specific naming guidelines can help ensure code readability and consistency. Here are some naming conventions recommended by Microsoft:

• Do use 'Callback' suffix for delegates that returns void type e.g. Action successAddCallback.

• Do use 'Get' prefix for delegates that don't returns a bool type e.g. Func<int> getRandomItemId.

• Do use 'Is', 'Can', or 'Has' prefix for delegates that return bool type e.g. Predicate<int> canAddingItems.

• Don’t use 'Delegate' suffix for delegate names e.g. delegate void DeleteItemDelegate().

Action VS Func VS Predicate

Action, Func, and Predicate are all delegate types that offer similar functionalities for managing method references. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:

• An Action delegate is a delegate that returns no value (void), typically used for callbacks or situations where an action needs to be executed without producing a result. It's equivalent to delegate void OnComplete().

• A Func<TReturn> delegate is a delegate that returns a value with specified type, typically used for operations that produce a result. It's equivalent to delegate TReturn OnComplete().

• A Predicate<TInput> delegate is a delegate that returns a bool type, typically used for validating input or determining whether an item meets certain criteria. It's equivalent to delegate bool OnComplete(TInput input).

Further Discoveries

Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of C# Delegate:

• A delegate can be called using the Invoke method or directly as if it were a regular method.

• A delegate that holds more than one method is known as a 'Multicast Delegate'.

• Use the ?. operator to check a nullable delegate e.g. addingItemCallback?.Invoke();. This practice prevents runtime errors by ensuring the delegate is only called when it’s not null.

• Use the delegate keyword instead of Action, Func, or Predicate when creating a delegate with three or more parameters. This is because Action, Func, and Predicate don't allow naming their parameters, which can make the code harder to read. For example: Action<int, int, int> vs. delegate void(int health, int damage, int speed).

• Convert a 'Multicast Delegate' into an event if the methods assigned to it are defined outside the class declaration. Declaring it as an event ensures that the delegate can't be called from outside the class declaration, which enhances encapsulation and control over its usage.

  💡

  To learn more about C# Event, check out my post at C# Event - Last Night Codes.

Reference

1. C# Delegate – Microsoft

2. C# Action – Microsoft

3. C# Func – Microsoft

4. C# Predicate – Microsoft

5. C# Delegate Naming Guidelines – Microsoft

Hello all, today I back with another C# topic, and today I will share what i learned about C# Interface. I hope with this article you will know more about C# Interface and use it on your project.

What It Is?

An interface can be thought of as a contract. This term is used because a class or struct that implements an interface is obligated to provide implementations for all of its members. For instance, if an interface have a method called Attack(), any class or struct that implements this interface must provide its own implementation of the Attack() method.

Why Implement It?

There are several pros and cons to consider before implement an interface in our project. Here are some of them:

Pros

• Enhance code scalability.

• Enhance code reusability.

• Loose coupling between modules.

Cons

• Could potentially increase the amount of redundant code.

• It may be challenging for new programmers to understand.

• When adding a new contract, it's essential to implement it across all classes that inherit from it. This ensures that as more classes connect, the complexity of the system increases appropriately.

How It Works?

To understand how interface work in the system, let's implement it first. To implement an interface, all you need to do is create a class file. However, instead of using the class keyword, you should use the interface keyword, as shown in the code below:

using System;

namespace Lncodes.Example.Interface;

public interface IDamageable
{
    int Health { get; }
    event Action OnHealthRunsOut;
    void TakeDamage(int amountDamage);
}

In the code above, I have created an interface with a Health property, an OnHealthRunsOut event, and a TakeDamage() method. This interface is designed for any class that needs to handle damage-related interactions, such as, Enemy, Player, NPC. After implementing this interface in the code, here's what will happen in the system:

1. When a class or struct implements an interface, the system will generate an error if that class or struct does not implement all the interface members.

2. When creating an interface as a variable type, the system will allow assigning objects of all classes or structs derived from this interface to the declared type, such as IDamageable _damageable = new Enemy() or new Player() or new Npc().

Console Application

In my console application, interfaces are used to specify creature capabilities. One interface specifies which creatures can take damage, while another specifies which creatures can attack others. In this console application, both the player and the enemy can take damage and attack other creatures, whereas the NPC can only take damage.

Below is a list of the interfaces and classes I used to create this console application, along with a brief explanation of each interface and class:

In the video above, you'll notice that each creatures has its own unique default health points. Additionally, when the enemy or player attack there's difference implementation on how they attack, the enemy sometimes miss the attack but the player never miss the attack and the damage points they have are also different from each other.

By implementing interfaces, the behaviors and attributes of creatures are clearly defined and managed. Interfaces provide specific rules for what each creature can do and what properties it should have. This leads to more organized and maintainable code by establishing a consistent structure, which makes it easier to update or add new features.

Additional Information

I have discovered some additional information about C# Interface. If you have any additional information about C# Interface that you'd like to share, please feel free to leave a comment.

Naming Guidelines

When implementing interfaces, following specific naming guidelines can help ensure code readability and consistency. Here are some naming conventions recommended by Microsoft:

• Use adjective phrases, or occasionally nouns or noun phrases, when naming interfaces e.g. IDamageable, IPlayer.

  ⚠

  Nouns and noun phrases should be used rarely for interface names. Frequent use might indicate that the interface could be more appropriately represented as an abstract class or a regular class.

• Do use 'I' prefix when naming interfaces e.g. IAttacker, IDamageable.

Interface VS Abstract

Both interfaces and abstract classes offer similar functionality for enhancing code abstraction by defining contracts or blueprints for derived classes. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:

• Use an interface when its member functionality is designed to be used by multiple modules. For example, when creating an IDamageable interface, the functionality of its members is intended to be used across various modules, including player, NPC, and enemy modules. This inclusivity makes it ideal to use an interface rather than an abstract class.

• Interface can't have methods with default implementations, but abstract class can have methods with default implementations.

  ℹ

  Since C# 8, interface can have methods with default implementations. However, the object of the derived class can't call this method unless the derived class overrides it first.

• The only access modifier that can be used for the interface members is public. The private, protected, and internal access modifiers can't be used for the interface members. However, all access modifiers can be used in the abstract class members.

  ℹ

  Since C# 8, interface members can use the private, protected, or internal access modifier.

• Interfaces can't have variables as a member, but abstract classes can have them as a member.

• A class can inherit from multiple interfaces, but it can't inherit from multiple abstract classes.

• A struct can inherit from an interface, but it can't inherit from an abstract class.

Further Discoveries

Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of C# Interface:

• The interface can't be instantiated.

• Struct can inherit from an interface.

• Interface can only have method, property, or event as a member.

• If a class or struct implements an interface but does not fully utilize all of its contract, that interface needs to be divided into several smaller interfaces. This is necessary to avoid violating the Interface Segregation Principle (ISP), which is a key tenet of the SOLID principles.

• An interface can be explicitly declared in its derived class, for example: public int IDamageable.Health {get;}.

• Never create an interface if the interface doesn't have any members.

Reference

1. C# Interface – Microsoft

2. C# Interface Naming Guidelines - Microsoft

Hello all, today I back with another C# topic, and today I will share what i learned about C# Event. I hope with this article you will know more about C# Event and use it on your project.

What It Is?

In C#, an event is a specialized form of delegate. Unlike delegates, which allow methods from outside the class to be assigned using both = and += operators, an event restricts assignments to only using the += operator. Additionally, events can only be raised within the class where they are declared, ensuring that they are raised only in controlled circumstances.

Why Implement It?

There are several pros and cons to consider before implement an event in our project. Here are some of them:

Pros

• Enhance the clarity of the code flow.

• Minimize dependencies on other classes.

• Preventing direct invocation of a delegate from outside its declaring class reduces the risk of unintended side effects.

Cons

• It may be challenging for new programmers to understand.

• Could potentially cause performance overhead if there's too many method assign to it.

• Could potentially cause memory leaks If the event are not properly unsubscribed.

How It Works?

To understand how event work in the system, let's implement it first. To implement an event, all you need to do is add an event keyword in front of the delegate, there are two different types of delegate that can be used for an event:

1. Regular Delegates e.g. public event [delegate/Action/Func/Predicate] OnOpenButtonPressed;

2. Event Handler Delegates e.g. public event EventHandler CloseButtonPressEventHandler;

The implementation of these events is as shown in the code below:

using System;

namespace Lncodes.Example.Event;

public abstract class UIController
{
    public event Action OnOpenButtonPressed;
    public event EventHandler CloseButtonPressEventHandler;
}

In the code above, I have created events using the Action delegate and the EventHandler delegate. These events are designed to be triggered whenever the open or close button is pressed. After implementing these events in the code, here's what will happen in the system:

1. When a delegate is declared as an event, the system ensures that the event can only be raised within the class that declares it. Additionally, methods can only be assigned to the event using the += operator.

2. Assigning and raising an event is similar to working with a delegate. When you assign a method to an event, it references that method. Raising the event will then also invoke all methods that have been added to it.

Console Application

In my console application, an event is used to display a message when a button is pressed. This console application uses three different types of delegates: Action (a general delegate without arguments), EventHandler (a specialized delegate without specific arguments), and EventHandler<T> (a specialized delegate with specific arguments).

Below is a list of the classes I used to create this console application, along with a brief explanation of each class:

In the video above, the console application displays a message when the button is pressed. There are three different buttons, each representing a different type of delegate used to handle events. Below is a list of all the delegate types used in this console application, along with a brief explanation of each delegate:

By implementing events, managing and handling button actions becomes significantly more efficient. Additionally, using different delegate types for various events can further enhance action management. Each delegate type is designed to ensure that events are handled appropriately, leading to a more organized and effective event-handling process.

Additional Information

I have discovered some additional information about C# Event. If you have any additional information about C# Event that you'd like to share, please feel free to leave a comment.

Naming Guidelines

When implementing events, following specific naming guidelines can help ensure code readability and consistency. Here are some naming conventions recommended by Microsoft:

• Do use a verb or verb phrase when naming an event e.g., opening, closed, etc.

• Do use verb-ing for event names that are raised before an operation is performed e.g., opening, closing, etc.

• Do use verb-ed for event names that are raised after an operation is performed e.g., opened, closed, etc.

• Do use 'On' prefix for the regular delegate event names, e.g. public event Action OnOpenButtonPressed;.

• Do use 'EventHandler' suffix for event handler delegate event names e.g. public event EventHandler CloseButtonPressEventHandler;.

• Do use the 'EventArgs' suffix for class or struct names that are intended to be used as arguments for EventHandler e.g. public class CloseButtonEventArgs { }.

• Do use the 'On' prefix for method names that raise an EventHandler e.g. protected void OnOpenButtonPressed().

Regular Delegate VS Event Handler Delegate

Both regular delegates and event handler delegates have similar functionality to managing method references within an event-driven architecture. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:

• When using EventHandler, there are two default parameters: sender and eventArgs. In contrast, regular delegates do not include these default parameters.

• Use EventHandler when it’s important to know which object raised the event. For instance, in an inheritance architecture, EventHandler helps determine which child class is raising the event, thanks to its default sender parameter which provides the instance of the object that raised the event.

Event VS Delegate

Both events and delegates have similar functionality to manage method references and provide a way to register methods. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:

• An event is typically used to notify the subscribing classes when something occurs in the publisher class, while a delegate is typically used for callbacks or to pass methods as parameters.

• An event can only be raised within the class where it’s declared, while a delegate can be invoked from outside its declaring class. This restriction helps ensure that the event’s handling remains encapsulated within the class that declares it.

• Outside its class declaration, an event can only be modified by adding or removing event handlers using the += and -= operators. In comparison, a delegate can be can be assigned or modified using =, +, -, +=, and -= operators.

Further Discoveries

Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of C# Event:

• When using EventHandler and no additional arguments are needed, it's recommended to use EventArgs.Empty instead of null. This maintains consistency and prevents null reference errors at runtime.

• When using a static EventHandler, it's acceptable to pass null for the sender argument. However, for non-static EventHandler instances, avoid passing null as the sender argument.

• When using the EventHandler delegate for an event, it’s essential to define a method to raise the event, and this method should be marked as protected virtual. This allows subclasses to override the method and raise the event, which is essential for properly implementing event handling in an inheritance-based architecture.

• When an EventHandler that returns values is required, a custom EventHandler can be defined using a regular delegate, like public event Func<int, object, EventArgs> CloseButtonPressEventHandler.

• Since C# 2.0, the generic EventHandler<T> can be used to define the type of argument for an EventHandler. This approach is recommended when the EventHandler needs to pass an argument, as it eliminates the need to cast the EventArgs parameter to access the argument value.

Reference

1. C# Event – Microsoft

2. C# Event Handler – Microsoft

3. C# Event Design Guidelines – Microsoft

4. C# Event Naming Guidelines – Microsoft

Hello all, today I back with another C# topic, and today I will share what i learned about C# Abstract. I hope with this article you will know more about C# Abstract and use it on your project.

What It Is?

An abstract class acts as a blueprint for derived classes that inherit from it. By defining a class as abstract, you essentially create a class that is purely a design, without an actual implementation. This means that it's impossible to create an object of an abstract class, as the term "blueprint" suggests only represents the design and not the concrete implementation.

By defining a class as abstract, you can now create different derived classes that retain the same characteristics of the abstract class but with distinct implementations.

Why Implement It?

There are several pros and cons to consider before implement an abstract in our project. Here are some of them:

Pros

• Enhance code reusability.

• Enhance code scalability.

Cons

• Could potentially increase code complexity.

• Subclass tightly coupled to the abstract class.

• It may be challenging for new programmers to understand.

How It Works?

To understand how abstract work in the system, let's implement it first. To implement an abstract, all you need to do is add an abstract modifier to your class, method, or property, as shown in the code below:

namespace Lncodes.Example.Abstract;

public abstract class EnemyController
{
    protected abstract int Stamina { get; set; }

    public abstract void Run();
}

In the code above, I have created an abstract class for enemy. Within this class, I create an abstract property called Stamina and an abstract method named Run(). After implementing this abstract in the code, here's what will happen in the system:

1. When creating an abstract class, the system will allow the creation of either an abstract method or an abstract property within the abstract class.

2. When creating an abstract class, the system will prohibit the creation of an instance of that class.

3. When creating an abstract method or abstract property, the system will automatically attach a virtual keyword to it in the background. As a result, an override keyword is necessary to modify the method or property in the derived class.

4. When creating a method or property with an abstract modifier in the parent class, all derived classes are required to provide an actual implementation to that method or property. This is because methods or properties with abstract modifiers have no actual implementation.

Console Application

In my console application, an abstract class is used to create a blueprint for all types of enemies. Each enemy type will have different stamina points and unique implementations for how they perform run and rest operations.

Below is a list of the classes I used to create this console application, along with a brief explanation of each class:

In the video above, you'll notice that each enemy type has its own unique default stamina points. Additionally, the stamina points used while running and gained while resting are different for each enemy type.

By implementing an abstract class, creating a new types of enemies has become significantly easier, thanks to the established blueprint of the EnemyController class.

Additional Information

I have discovered some additional information about C# Abstract. If you have any additional information regarding C# Abstract that you'd like to share, please feel free to leave a comment.

Abstract VS Interface

Both abstract classes and interfaces offer similar functionality for enhancing code abstraction by defining contracts or blueprints for derived classes. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:

• Use an abstract class when the members functionality are exclusively used within a single module. For instance, when creating the EnemyController abstract class, we limited its functionality to be exclusively used within the enemies module, not for players or NPC. This exclusivity makes it ideal to use an abstract class rather than an interface.

• Abstract class can have methods with default implementations, but interface can't have methods with default implementations.

  ℹ

  Since C# 8, interface can have methods with default implementations. However, the object of the derived class can't call this method unless the derived class overrides it first.

• All access modifiers can be used in the abstract class members, but only the public access modifier can be used in an interface members.

  ℹ

  Since C# 8, interface members can use the private, protected, or internal access modifier.

• Abstract class can have variables as a member, but interface can't have them as a member.

• A class can't inherit from multiple abstract classes, but it can inherit from multiple interfaces.

• A struct can't inherit from an abstract class, but it can inherit from an interface.

Abstract Method VS Virtual Method

Both abstract methods and virtual methods offer similar functionality in providing flexible method implementations for derived classes. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:

• Use the abstract method when the majority of the methods in the derived class have different implementations. However, if only a minority of the derived classes requires a different implementation, use virtual instead of abstract.

• When using abstract method, it's mandatory to override the method in the derived class. Conversely, there is no requirement to override a virtual method in the derived class. This is because abstract method don't have implementation in the parent class but virtual method do.

Further Discoveries

Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of C# Abstract:

• The abstract class can't be instantiated.

• An abstract class can have a constructor, but never makes the constructor has a public access modifier because abstract class can’t be initialized. Instead use public access modifier make the constructor use protected or internal access modifier instead.

• An interface or an abstract class can inherit from another abstract class.

• Using a sealed modifier on the abstract class will not cause a compiler error.

  ℹ

  Since C# 8, the compiler will display an error message when a sealed modifier is used in an abstract class.

Reference

1. C# Abstract – Microsoft