DEV Community: Hamsheed Salamut

Hands-On: Strategy Design Pattern in .NET Core

Hamsheed Salamut — Thu, 11 Mar 2021 12:25:21 +0000

About Patterns

Design patterns were introduced in Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides’s seminal work Design Patterns: Elements of Reusable Object Oriented Software.

Design patterns provide a high-level language of discourse for programmers to describe a system and to discuss solutions to common problems. The proper and intelligent usage of patterns will guide a developer into designing a system that conforms to well-established prior practices, without stifling innovation.

The Strategy Pattern

The Strategy Pattern is one of the original patterns described in the famous Design Patterns book. It is a behavioral design pattern that allows us to implement different functionalities in separate classes and make their objects interchangeable.

Put simply, we have a main Context object that holds a reference towards a Strategy object and delegates it by executing its corresponding functionality.

Without any further ado, let's dive into the Strategy Pattern Design implementation.

This post is organized into the following sections:

Strategy Design Pattern Structure
Implementation of the Strategy Pattern
Common usage of the Strategy Pattern
Takeaways and Final Thoughts

Strategy Design Pattern Structure

As emphasized above, the strategy design pattern consists of a Context object which holds a reference towards the Strategy object. For an exhaustive implementation, we need the Strategy object - Interface to define a mechanism for the Context object to execute the strategy and the Concrete Strategies objects which implement the Strategy Interface.

The Participants

The Strategy declares an interface which is implemented by all supported algorithms.
The ConcreteStrategy objects implement the algorithm defined by the Strategy.
The Context maintains a reference to a Strategy object, and uses that reference to invoke the algorithm defined by a particular ConcreteStrategy.

Implementation of the Strategy Pattern

For this article, let's model this pattern by talking about some different ways to cook food.

A Delicious Example

Being an eat-meater, there's often more than one way to cook meats under safe eating temperatures.

For instance, a meat can be roasted, deep-fried or broiled. Each of these methods will get the item cooked, just via different processes. These processes, in object-oriented code can each be their own class.

In our example, we will assume that we will ask the user what method they would like to use to cook their food, and then implement that method using the Strategy design pattern.

To start, let's write up the Strategy participant, the Interface ICookStrategyService.

    public interface ICookStrategyService
    {
        void Cook(string food);
    }

Each strategy implements the method Cook() which indicates how a food item shall be cooked. Let's implement a few of those strategies - also referred to as ConcreteStrategy participants.

    public class GrillingService : ICookStrategyService
    {
        public void Cook(string food)
        {
            Console.WriteLine($"Cooking {food} by grilling it");
        }
    }

    public class RoastingService : ICookStrategyService
    {
        public void Cook(string food)
        {
            Console.WriteLine($"Cooking {food} by roasting it");
        }
    }

    public class DeepFryingService : ICookStrategyService
    {
        public void Cook(string food)
        {
            Console.WriteLine($"Cooking {food} by deep frying it");
        }
    }

In a typical ASP.NET Core application, we shall leverage the built-in dependency injection mechanism to register the services as follows:

services.AddTransient<ICookingStrategyService, GrillingService>();
services.AddTransient<ICookingStrategyService, RoastingService >();
services.AddTransient<ICookingStrategyService, DeepFryingService>();

We would then inject these instances in the constructor of a class to use these services. However, when we ought to run the application, we will observe that all three parameters are instances of type DeepFryingService because DeepFryingService has been injected last.

To overcome this limitation, we will use an IEnumerable collection of services to register the services and a delegate to retrieve a specific service instance.

Use a delegate to retrieve a specific service instance

Consider the following enum that contains integer constants that correspond to the three types Grill, Roast, and Fry.

public enum CookingType
{
   Grill,
   Roast,
   Fry
}

We then declare a shared delegate:

public delegate ICookingStrategyService ServiceResolver(CookingType cookingType);

The ConcreteStrategies are then registered as Transient services in the Startup.cs file.

services.AddTransient<GrillingService>();
services.AddTransient<RoastingService>();
services.AddTransient<DeepFryingService>();

Return instances based on service type at runtime

The following code snippet shows how we can return instances of the GrillingService, RoastingService, and DeepFryingService classes depending on the service type selected at runtime.

services.AddScoped<ServiceResolver>(serviceProvider => key =>
{
      switch (key)
      {
         case CookingType.Grill:
              return serviceProvider.GetRequiredService<GrillingService>();
         case CookingType.Roast:
              return serviceProvider.GetRequiredService<RoastingService>();
         case CookingType.Fry:
              return serviceProvider.GetRequiredService<DeepFryingService>();
          default:
              throw new KeyNotFoundException();
       }
});

When to use Strategy Pattern

Where different variations for some functionalities in an object and we want to switch from one variation to another in a runtime. Furthermore, if we have business applications that may have many different possible strategies in play, the strategy pattern should be the right choice for us.

Takeaways and Final Thoughts

The strategy pattern achieves decoupling by encapsulating variable parts of a behavior behind an abstract interface. This abstraction can make working with a family of related algorithms easier, and it lets us postpone introduction of new ConcreteStrategies. In addition, the strategy pattern allows for different behaviors to be implemented and tested individually.

Happy Coding! 💻

Introduction to Simple Queue Service (SQS) with Amazon Web Service (AWS)

Hamsheed Salamut — Tue, 25 Aug 2020 15:47:39 +0000

Overview ℹ️

Amazon SQS is a fully managed message queueing service offered by Amazon Web Services (AWS). Before cloud-based message queueing services existed, we often needed to create our own message queue solution. Amazon SQS helps to eliminate the overhead and the complexity of trying to create your own managed queueing solution. When using Amazon SQS, we can more easily decouple and scale our microservices and serverless applications. Amazon SQS allows you to send, store and receive any volume of messages between software components securely without worrying of losing any of the messages.

Amazon SQS provides two types of queues namely:

Standard: It is fully managed, scales from 1 message per second to 10,000s per second. Default retention of messages: 4 days, maximum of 14 days and no limit to how many messages can be in the queue. It has low latency (<10 ms on publish and receive) and horizontal scaling in terms of number of consumers.
FIFO: It is referred as First-In-First-Out delivery and exactly-once processing. The order in which messages are sent and received is strictly preserved and a message is delivered once and remains until consumer processes delete it. Duplication is not allowed in FIFO and it is limited to 300 transactions per second.

If your application is cloud-native, large-scale, or distributed, and does not include a messaging component, that’s probably a bug! Tim Bray – AWS Senior Principal Engineer

Benefits

Amazon SQS provides several benefits:

Reduce administrative overheads – AWS manages all the ongoing operations and the underlying infrastructure that is required to provide the highly available and scalable messaging service. AWS has taken the need to install and configure any messaging software.
Reliably deliver messages – We are able to transmit any volume of data and any level of throughput to our Amazon SQS queue without any worry of losing any messages. When using Amazon SQS, we can increase the fault tolerance of our system by decoupling our application components, which basically means creating components or services so that they run and fail independently. We can have a service which is unavailable and still processes messages.
Messages are stored redundantly across multiple availability zones – which makes messages always available when we need them.

Common Usage of SQS

TV Voting System

Suppose you are watching a TV show that allows you to vote for a winner after a performance. At the end of the performance, 5 to 50 million viewers are all voting at the same time. How are you are going to handle a large spike of traffic in such a short space of time? One solution would be to build a significant web server tier and database back-end that could manage millions of messages per second but that would be costly to scale, as you would have to pre-provision for maximum expected workload and at the same time, it might not be fault-tolerant due a database failure or throttling. Consequently, this may cause a loss of votes.

As a solution to address this problem is to make use of a queueing mechanism to decouple the voting application system from the service where the vote queue will be highly scalable. This will allow to adequately absorb 10 messages/sec or 10 million messages/sec. Eventually, you would have a consumer tier which will be responsible to pull the messages from the queue as fast as possible to tally the votes. The queuing system will provide us with a more resilient system, and handle parts of our system being down.

Amazon SQS Architecture

Amazon states that there are three main parts in a distributed messaging system. First, there are the components or services which generally send or receive messages from our SQS queue. The second part is the SQS queue itself. The third part is the messages inside our queue.

An important concept to understand is where and how our messages are being stored. Whenever a message is sent to our SQS queue, there are redundantly stored across multiple Amazon SQS services. By distributing the same message across different SQS services, AWS can guarantee safe and successful storage of our messages. In our example, you can see messages A, B, C and D are stored in different AWS services to ensure that if anything goes wrong on AWS’s side, we are still guaranteed that we receive our messages that we have sent to our SQS queue.

The diagram below illustrates the architecture of Amazon SQS.

Wrapping Up 📢

In this article, we learnt that SQS can be used to efficiently manage messages that flow through queues, and how they are consumed. The architecture of Amazon SQS illustrated in this article explains the underlying mechanism of how messages are stored and processed. In a next article, I shall demonstrate how to create, configure Amazon SQS and consume a message.