Nuffing.com

The efforts of officials to confiscate military-style firearms in Massachusetts ran into trouble recently when armed militia groups confronted a government raid to seize a stockpile of guns and ammunition and arrest leading anti-government activists rumored to be in a small town outside of Boston.

The government forces were initially met by a small number of militia members in Lexington. After their show of force, the militia leader ordered his men to stand down and allow the government’s troops to pass. They were in the process of dispersing when a shot rang out. No one is sure just who fired that shot, but in response government troops opened fire, killing eight and wounding several others before their officers could regain control of the situation. Government forces then proceeded west towards their original destination of Concord, Massachusetts.

At Concord, the government troops spread out through the community searching for banned goods and the individuals they had been instructed to arrest. One group headed toward William Barret’s farm where it was reported that a stockpile of guns and ammunition was being collected. Meanwhile, some prohibited items were found in the town and set on fire in a vacant lot. However, the fire soon spread to a nearby building and the resulting smoke led some militia leaders that had assembled their men in the area to believe the town was being deliberately burned down. They began advancing and confronted a group of government troops at a bridge on the north side of the town. A brisk exchange of gunfire resulted in about a dozen casualties and government forces retreating back towards the center of town.

At this point, the raid’s leaders decided it would be best to return to Boston rather than continuing on their mission. During the subsequent retreat, an estimated seventy troops were killed and about two hundred were wounded as thousands of militiamen from the area rushed to confront the retreating government forces.

Following the abortive raid, an investigation was launched into why it had failed. The raid had been planned in the utmost secrecy, with the troops and leaders learning of their mission only at the last possible moment. Still word leaked out, probably by someone that overheard the planning of the raid at the governor’s mansion. Knowledge of the potential raid quickly spread to militia leaders but the exact target of the raid was not known. The individual that leaked the information about the raid was never identified.

This most recent raid was part of a trend that started last year when a law was passed banning the importation of military-style firearms and ammunition into the state. Subsequently, government forces began conducting warrantless searches for guns and ammunition. A successful raid was conducted on September 1, when a stockpile of ammunition was seized from a site about six miles northwest of Boston. A similar effort to seize ammunition stockpiles occurred in Williamsburg, Virginia. Rumors quickly spread that the government was deliberately trying to deny citizens the ability to acquire ammunition. Hoarding and shortages soon followed.

These initial successful efforts led the Massachusetts and Virginia governors to order further raids. A second attempt to seize illegal guns and ammunition was aimed at the Salem community. This one failed when local citizens learned of the raid and took efforts to block roads and bridges, preventing government officials from reaching the town.

Gun control efforts in Massachusetts increased in response to protests in Boston resulting from raising taxes and harsh treatment by government officials. This latest series of protests turned violent a few years ago when government officials opened fire on a crowd, killing five, including one black man. A couple of years later another group of protesters seized control of an embargoed shipment of goods pending payment of import taxes. Although the protest was non-violent, several thousand dollars in goods were destroyed. In an effort to restore order, Massachusetts’ governor imposed martial law in the area immediately around Boston and ordered the confiscation of firearms and ammunition.

In response to the governor’s action, Massachusetts gun rights leaders pointed to a resolution that was voted on almost ten years ago that stated every citizen was entitled to possess a firearm for their own personal protection and to defend the state from outside attack. They said that the government’s latest efforts fly in the face of long-standing tradition that people have the right to defend themselves.

[Author’s Note: You probably have not heard about these incidents in any of the major news outlets. However, they all happened, just not recently. Instead they occurred in the late eighteenth century and involved the events surrounding the Boston Massacre (1770), the Boston Tea Party (1773), and the Battles of Lexington and Concord (1775). Even then, gun control was used in an attempt to control the rights of citizens to protest government actions.]

My sustainable homestead is evolving—and the new addition to the ever-growing project involves using rain barrels to provide my chickens with drinking water, irrigate my garden, and keep my compost pile moist.

Luckily for me, my local municipality teamed up with our state college to offer residents classes and incentives to help grow our community’s conservation effort (you can check with your local government to see if they offer anything similar). Through the program, I was able to purchase a 55-gallon rain barrel for just $37—a deal so good I opted to purchase three barrels. The barrels were guaranteed to be food-grade, which meant I avoided the toxic residuals that might have been lurking in any old barrel. Instead, my barrel had been used exclusively to store juice, so it was actually designed to withstand both the pressure and weight of 55 gallons of liquid, which weighs roughly just under 500 pounds.

The sweet juice residuals meant I needed to clean the barrel out with a solution, though. You can use a solution of one ounce of bleach to five gallons of water or, as I did, opt for a vinegar and baking soda alternative. However you get the job done, you’ll want to make sure the barrel is fresh and clean before you start collecting water in it.

Here are a few things I’ve learned throughout the process:

• You don’t need a water pump to get the water out if you use gravity to your advantage and place the barrel on a raised base.
• You want your base to be level and balanced.
• 55 gallons of water is very heavy.
• You’ll need to use fine mesh as a barrier at every entry point you create; otherwise, debris can clog everything up, and bugs are attracted to the water.
• It’s important to avoid placing your barrel in direct sunlight because algae will grow inside it. You can also paint your barrel to keep the light out.

The build itself is rather simple: Rain barrels have inlets into which you direct a water source—you can direct the water from your gutter system by modifying your downspout to pour directly into the inlet, for example. Add another hole toward the top of the barrel for overflow and plan to direct that water away from your foundation—or into another barrel.

Next, you’ll need to cut a hole toward the bottom of the barrel and install a spigot. From the spigot, you can use a garden hose to direct the water to wherever you want it to go. How high you place the barrel will determine how much pressure you are going to get.

Introduction

In software and web development, it’s always important to write code that is maintainable and extendable. The solution that you first create will likely change over time. So, you need to make sure you write your code in a way that doesn’t require a whole rewrite or refactor in the future.

The strategy pattern can be used to improve the extendability of your code and also improve the maintainability over time.

Intended Audience

This post is written for Laravel developers who have an understanding of how interfaces work and how to use them to decouple your code. If you’re a little unsure about this subject, check out my post from last week that discusses using interfaces to write better PHP code.

It’s also strongly advised that you have an understanding of dependency injection and how the Laravel service container works.

What Is the Strategy Pattern?

Refactoring Guru defines the strategy pattern as a “behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.”. This might sound a bit scary at first, but I promise that it’s not as bad as you think. If you want to read more into design patterns, I’d highly recommend checking out Refactoring Guru. They do a great job of explaining the strategy pattern in depth as well as other structural patterns.

The strategy pattern is basically a pattern that helps us to decouple our code and make it super extendable. In fact, you probably use it every day with Laravel without even noticing whenever you use the Storage and Cache facades (and a few other places too). Let’s say that you use this code:

Cache::put('name', 'Ash Allen', 600);

The code above is resolving a class from the service container by using the facade. I won’t get into how facades work as it’s not really the purpose of this article, but the important bit to know is that the Cache facade here is binding an interface (Illuminate\Contracts\Cache\Factory to be specific) to a class and using it. It is then storing the word ‘Ash Allen’ under the key ‘name’ for 10 minutes.

As you’ll have probably noticed in the Laravel documentation and in your project’s config, Laravel supports a few different drivers for caching, including: Redis, DynamoDB, Memcached and the database. So, for example, if we were to set our cache driver in our .env file to CACHE_DRIVER=redis, when we run our code snippet above, the data would be stored in our Redis cache. However, if we were to change the driver to be CACHE_DRIVER=database, this would result in data being stored in the database instead.

Each different cache driver has it’s own respective class that deals with how the framework interacts with the cache. So, when we change the driver in our .env, Laravel needs to know which driver to use. This is where the strategy pattern steps in. Under the hood, whenever we use the Cache facade, Laravel is actually resolving an Illuminate\Contracts\Cache\Factory interface from the service container. It does this by checking the config value (e.g. redis, database, etc.) and then mapping that interface to a class. For example, whenever we have our cache driver set to CACHE_DRIVER=redis and we try to resolve the Factory interface, we will get a class that specifically interacts with the Redis cache and nothing else.

As you can see, the strategy pattern can improve the extendability of your code. For example, if we wanted to create our own custom cache driver, we could just create the implementation and then let Laravel know that it is available for using. For a bit more context, check out the Laravel documentation to see an example of how you can add your own driver.

Using the Strategy Pattern in Laravel

Now that we have a basic idea of what the strategy pattern is, let’s look at how we can use it ourselves in our own Laravel application.

Let’s imagine that we have a Laravel application that users can use for getting exchange rates and currency conversions. Now, let’s say that our app uses an external API (exchangeratesapi.io) for getting the latest currency conversions.

We could create this class for interacting with the API:

class ExchangeRatesApiIO
{
    public function getRate(string $from, string $to): float
    {
        // Make a call to the exchangeratesapi.io API here and fetch the exchange rate.

        return $rate;
    }
}

Now, let’s use this class in a controller method so that we can return the exchange rate for a given currency. We’re going to use dependency injection to resolve the class from the container:

class RateController extends Controller
{
    public function __invoke(ExchangeRatesApiIO $exchangeRatesApiIO): JsonResponse
    {
        $rate = $exchangeRatesApiIO->getRate(
            request()->from,
            request()->to,
        );

        return response()->json(['rate' => $rate]);
    }
}

This code will work as expected, but we’ve tightly coupled the ExchangeRatesApiIO class to the controller method. This means that if we decide to migrate over to using a different API, such as Fixer, in the future, we’ll need to replace everywhere in the codebase that uses the ExchangeRatesApiIO class with our new class. As you can imagine, in large projects, this can be a slow and tedious task sometimes. So, to avoid this issue, instead of trying to instantiate a class in the controller method, we can use the strategy pattern to bind and resolve an interface instead.

Let’s start by creating a new ExchangeRatesService interface:

interface ExchangeRatesService
{
    public function getRate(string $from, string $to): float;
}

We can now update our ExchangeRatesApiIO class to implement this interface:

class ExchangeRatesApiIO implements ExchangeRatesService
{
    public function getRate(string $from, string $to): float
    {
        // Make a call to the exchangeratesapi.io API here and fetch the exchange rate.

        return $rate;
    }
}

Now that we’ve done that, we can update our controller method to inject the interface rather than the class:

class RateController extends Controller
{
    public function __invoke(ExchangeRatesService $exchangeRatesService): JsonResponse
    {
        $rate = $exchangeRatesService->getRate(
            request()->from,
            request()->to,
        );

        return response()->json(['rate' => $rate]);
    }
}

Of course, we can’t instantiate an interface; we want to instantiate the ExchangeRatesApiIO class. So, we need to tell Laravel what to do whenever we try and resolve the interface from the container. We can do this by using a service provider. Some people prefer to keep things like this inside their AppServiceProvider and keep all of their bindings in one place. However, I prefer to create a separate provider for each binding that I want to create. It’s purely down to personal preference and whatever you feel fits your workflow more. For this example, we’re going to create our own service provider.

Let’s create a new service provider using the Artisan command:

php artisan make:provider ExchangeRatesServiceProvider

We’ll then need to remember to register this service provider inside the app/config.php like below:

return [
    
    'providers' => [
        // ...
        \App\Providers\ExchangeRatesServiceProvider::class,
        // ...
    ],
	
]

Now, we can add our code to the service provider to bind the interfaces and class:

class ExchangeRatesServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->bind(ExchangeRatesService::class, ExchangeRatesApiIO::class);
    }
}

Now that we’ve done all of this, when we dependency inject the ExchangeRatesService interface in our controller method, we’ll receive an ExchangeRatesApiIO class that we can use.

Taking It Further

Now that we know how to bind an interface to a class, let’s take things a bit further. Let’s imagine that we want to be able to decide whether to use the ExchangeRatesAPI.io or the Fixer.io API whenever we’d like just by updating a config field.

We don’t have a class yet for dealing with the Fixer.io API yet, so let’s create one and make sure that it implements the ExchangeRatesService interface:

class FixerIO implements ExchangeRatesService
{
    public function getRate(string $from, string $to): float
    {
        // Make a call to the Fixer API here and fetch the exchange rate.

        return $rate;
    }
}

We’ll now create a new field in our config/services.php file:

return [

    //...

    'exchange-rates-driver' => env('EXCHANGE_RATES_DRIVER'),

];

We can now update our service provider to change which class will be returned whenever we resolve the interface from the container:

class ExchangeRatesServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->bind(ExchangeRatesService::class, function ($app) {
            if (config('services.exchange-rates-driver') === 'exchangeratesapiio') {
                return new ExchangeRatesApiIO();
            }
		  
            if (config('services.exchange-rates-driver') === 'fixerio') {
                return new FixerIO();
            }
		  
            throw new Exception('The exchange rates driver is invalid.');
        });
    }
}

Now if we set our exchanges rates driver in our .env to EXCHANGE_RATES_DRIVER=exchangeratesapiio and try to resolve the ExchangeRatesService from the container, we will receive an ExchangeRatesApiIO class. If we set our exchanges rates driver in our .env to EXCHANGE_RATES_DRIVER=fixerio and try to resolve the ExchangeRatesService from the container, we will receive an FixerIO class. If we set driver to anything else accidentally, an exception will be thrown to let us know that it’s incorrect.

Due to the fact that both of the classes implement the same interface, we can seamlessly change the EXCHANGE_RATES_DRIVER field in the .env file and not need to change any other code anywhere.

Conclusion

Is your brain fried yet? If it is, don’t worry! Personally, I found this topic pretty difficult to understand when I first learnt about it. I don’t think I started to really understand it until I put it into practice and used it myself. So, I’d advise spending a little bit of time experimenting with this yourself. Once you get comfortable with using it, I guarantee that you’ll start using it in your own projects.

Hopefully, this article has given you an overview of what the strategy pattern is and how you can use it in Laravel to improve the extendability and maintainability of your code.

If you found this post useful, I’d love to hear about it in the comments.

Keep on building awesome things! 🚀