What is a memory leak? A quick analogy

This is something that came up in conversation, some friends and I were discussing deploying code, that runs in the background, to production environments.

One of the things I raised was what can happen with daemon processes, should you have a very small inefficiency, given enough time to run (usually by the time it gets to production) it can, and will, destroy live servers.

I then realised that, at this point in the conversation, a description of what a memory leak is, had become an appropriate thing to explain.

Anybody who knows me, knows I love an analogy; so this is the analogy I gave, to give a really simple explanation as to what a memory leak is:

Every morning, you go to a fast food drive through.

You order a meal, eat it, and throw the paper bag with some leftovers into the passenger footwell.

At the end of the day, you arrive at home. You pick up the bag of rubbish, and put it into your bin. Without realising it, you drop a single french fry in the car.

In development and testing you run this same process 50 times, dropping a single french fry each time. The fries are not visible, they’re under the passenger seat, or with the momentum of the car have ended up in the back.

When you go live, the process runs more frequently, and instead of a single meal you’re buying 10 at a time.

Very quickly, those single french fries culminate in an unusable car, because you can’t fit in a Honda Civic if it has 1,000,000 festering french fries inside.

Matt “Johno the Coder” Johnson, on a cold winter morning

So there it is, a quick explanation of what a memory leak is, in an easy to understand analogy.

I’ve been asked to do walk throughs on practical implementations on daemons and a few other topics, so I am going to write those up soon.

Practically, what might it look like?

Imagine your daemon script looks something like this…

// Store the jobs that have been processed
$jobsProcessed = [];

// This is a daemon script, it needs to run, forever
while(true){

// This is just for demonstration purposes!
$job = getNewJob();

// Do whatever you need to, to handle the job

// Let's store the job we've processed
$jobsProcessed[] = $job;

}

This all looks fairly innocent right. In testing there are probably, at tops, a few thousand test jobs. In production, when this is running forever, that very small array, can become very big. That’s the bit that could cause a server to topple.

For reference, if you do need to keep this information, store it somewhere, anywhere, else. A log file is usually a good shout (as long as you’re periodically cleaning out your log files), perhaps a database (I’d recommend a MyISAM table for this, as you’re dumping a whole load of plain text data). If you keep this information in a variable in your script, it’ll hold in memory, which is exactly where you don’t want it.

So there it is, a quick and easy analogy, with an (overly) simplified example of what it might look like.

Beware, the Anti Pattern!

In this article I am going to cover the application of patterns within your… application. In short, I am going to show you how to use design patterns in a logical manner.

Patterns are always sometimes awesome!

The first thing here is that all design patterns have a purpose, every design pattern has its place. Whilst I’m talking about design patterns the same can be said of development methodologies, database designs, and really any other kind of concept.

The proper application of design patterns can take a frustrating piece of software, and make it easy to maintain, or hyper-secure, or crazy performant.

The bad application of a design pattern will do the exact opposite.

But, why would you ever not use a pattern?

Well, when it’s not the right time to use it. Every pattern has its place, but not every pattern should be used everywhere, it’s a bad idea.

Don’t take my word for it, let’s look at some practical examples and experiences that really demonstrate what I am saying here.

I’m going to be deliberately controversial here, and I’m going to pick stuff that all developers seem to love and then prove where it will ruin your application.

I’ve heard of Patterns, what is an Anti Pattern?

An anti-pattern is a pattern. Subjectively an anti-pattern is when you take a pattern and either apply it in the wrong circumstances, or implement it badly.

The consequence of the application of an, otherwise great, pattern, causes adverse impacts (usually for maintainability, or for performance etc). Now, it is an anti-pattern.

Model View Controller (MVC)

Well all love MVC, right? I mean, what’s not to love? CodeIgniter, CakePHP, Laravel, Angular, and Joomla all follow this pattern. It is arguably one of the most used design patterns of recent times.

For good reason, it’s awesome! Because it’s awesome, developers are pretty darn impassioned about using it everywhere, and they are right, in the vast majority of cases.

So when, I hear you ask, would this not be a good idea? When could it be an anti-pattern?

What about if I am writing a daemon, which is going to continuously monitor the usage of the mounted hard drives on a server and, in certain scenarios, send an email to a system administrator?

Don’t need models – we’re not handling any data. We don’t have anything, not even a CLI output, so no need for views. Realistically there’s not a controller it’s a standalone script. MVC would be a bit overkill, in this instance, wouldn’t it?

That’s a bit of a drastic example though, let’s look at something more subtle.

Single Responsibility Principle

Ah, right. Let’s get controversial then, shall we?

A class should only have one reason to change

Single Responsibility Principle, SOLID Principles

Everyone loves this, and likes to really preach about it. It is crazy controversial, widely adopted, and I personally think that it’s a good idea.

The Single Responsibility Principle is like the best song in the world, that you hear 1,000 times per day on every music channel and radio station. It is best practice, yes. But sometimes, it’s okay to break it!

Oh Gosh, quick, get the smelling salts and a wet flannel, they’ve feinted!

The whole point of the SOLID principles are to make well structured, easy to maintain code.

So, time for a real-life example. I have a class, it is an Eloquent Model. It is responsible for some mission-critical, core functionality. This class has a method within it. This method is 150 lines long (probably 50 lines of code, once you take out empty lines and code comments).

This method, in of itself, could (and maybe even should) be abstracted into it’s own class. For some context it is a static method, responsible for fetching records, based on a set of arguments.

Every part of the Single Responsibility Principle dictates this method should be abstracted to its own class, perhaps even a set of classes.

Internally, I have had this code reviewed, and to quote the developers who have checked (and indeed worked on) it, it is “exceptionally easy to follow” and “super easy to add and change the functionality”.

It is, essentially, a set of if statements. Based on the outcome of those if statements, the Eloquent Query is modified, then returning either limited, or paginated, results.

So, I hear you scream, “why won’t you abstract it?!” – well I could. But following conversations with the development team, the code would actually be harder to follow if I were to abstract and refactor it.

In this instance, the code can be easily found, easily changed, and is incredibly stable.

Following Single Responsibility to the letter, this time, would be an anti-pattern. Rather than making life easier, it would make life more difficult. Abstraction can be bad! If it has no performance, functional, or security perks. It makes the code more difficult to maintain and follow; then abstracting it would not make any sense. Except to follow a pattern for the sake of following a pattern, at this point, it becomes an anti-pattern.

Dependency Injection

Oh God. I’ve been here before. It is bad. I remember the flames, vividly. As the Reddit Hellfire engulfed my computer. Just kidding, but this one does really evoke emotional reactions.

Just quickly and very simply, dependency injection is parsing an object (dependency) into another object on which the latter depends. Thus, injecting the dependency. It usually looks (forgetting containers and autowiring) something like this.

class Calculator{

public function __construct(
AdditionServiceProvider $addition,
SubtractionServiceProvider $subtraction
){
$this->additionService = $addition;
$this->subtractionService = $subtraction;
}
}

The point here is that I can control the services that the Calculator is using. So if I were, at a later date, wanting to swap out my AdditionServiceProvider for AcmeIncAdditionServiceProvider (assuming they implement the same interface, or extend the same base class) then I could, and the rest of the class would work as expected.

However, I have, several times, seen things like this.

class PaymentsIncorporatedWrapper{

public function __construct(
PaymentsInc\Payer $payer,
PaymentsInc\Refunder $refunder
){
$this->payer = $payer;
$this->refunder = $refunder;
}

}

Right, this makes sense, doesn’t it? Wire up the payer and the refunder, then drop them into your Wrapper. As I said above, take the dependency injection container side of it; whenever I want to do something with the PaymentsIncorporatedWrapper I have to do something like

$payer = new PaymentsInc\Payer($apiKey, $somethingElse);
$refunder = new PaymentsInc\Refunder($apiKey, $somethingElse);
$wrapper = new PaymentsIncorporatedWrapper($payer, $refunder);

That’s a kind of annoying amount of code to write, to instantiate a class. “But the container does that for you!” I hear you scream. Yes, yes it will.

But why? You don’t know, at the time of instantiation, that I need the refunder. I might just be querying a payment. Why do I need the refunder? I don’t. Ah, maybe this is an anti-pattern.

Also, this set of classes is specific to the PaymentsInc integration. So it’s not like I’m going to swap in another payment provider (otherwise this would all make sense).

In this instance, when I couldn’t possibly want to swap anything else in/out, perhaps this would make more sense?

class PaymentsIncFactory{

public static function getPayer() : PaymentsInc\Payer
{
$factory = new static();
return $factory->getPayer();
}

private function getApiKey() : string
{ ... }

private function getSomethingElse() : string
{ ... }

public function getPayer() : PaymentsInc\Payer
{ ... }

...

}

class PaymentsIncoporatedWrapper{

public function takePayment(float $amount)
{
$payer = PaymentsIncFactory::getPayer();
$payer->takePayment($amount);
}

}

Anybody who is passionate about Dependency Injection will argue this is wrong, and they will probably cite Unit Testing as the reason. But, to my knowledge, unit testing isn’t justification for using Dependency Injection.

In fact, I have implemented both Unit Testing, and Test Driven Development, without unnecessarily using Dependency Injection. Of course, Dependency Injection was used, just only where it was truly necessary.

And the point of those tales was….

Just because a pattern is the best thing since sliced bread, doesn’t mean you should apply it liberally, everywhere, without thinking about it.

In the above I’ve taken three of the most beloved patterns we possess, and given you three good places where perhaps those pattern were best not applied.

So think about the patterns you’re using, never blindly use it because someone on [insert social website or influencer here] said is is amazing.

The key, as with all things, is to genuinely understand the pattern, its application, its benefits, and its constraints. And then think, and make a decision, about whether it makes sense to apply it in your use case.

Further Reading / Sources

  1. Model View Controller (MVC) – Wikipedia
  2. Single Responsibility Principle – Wikipedia
  3. Dependency Injection – Wikipedia

Layering Software Design

This is a quick-ish article about layering software design, and how to achieve layering in ways which are consistent and useful for the maintainability of your source code. I have seen it done badly I have also seen it done very well, but I thought it was worth covering. Throughout my career I have seen lots of software designs, great. Flow charts and diagrammatic representations of software designs. At this point I think “Great, I can follow this!” – and then I see the code, and the layering is impossible to decipher, and is seemingly only existent in the designer/architect’s head.

Consequently, I thought I would do a quick article on layering your software. I appreciate there are lots of articles around the SOLID principles, and various other related topics, and I urge you to read about spaghetti code and lasagne before reading this article.

This article is aimed at people who have a decent understanding of Object Oriented Programming, but who are in the process of learning about software design and separation of concerns. Alternatively, it may also help those who have large, unorganised code bases to manage, or large projects to design and build.

Quick notice: I’ll keep code samples to a minimum and as concise as possible for the purposes of readability, but said code will be in PHP

The Problem

What we are trying to do, when creating layers of software, is create manageable code, the concerns of which are as separated as possible. Often we are trying to achieve this by defining parts of our application, usually referred to as layers.

Then a professional of some description (software engineer, web developer, systems architect, etc) creates a drawing of the different components to the software and how they should interact with one another. “Excellent!” they exclaim, and off the various developers go to work on their layers. Unless you’re in a strict environment quite often the developers work in isolation, and agree on integration points (or these are predetermined, or predefined).

In my experience, what normally happens at this point is that we have a load of principles designed, and off the team go to carry out the development on the product itself begins. Let’s make the assumption we’re talking about a content management system.

Then the code happens, bug fixes, amendments, changes in specification, and then, eventually… The product is finished! And by this point the design and architecture are forgotten, balls! Nowhere to be seen throughout the codebase.

The Solution

If you’re already in this situation you have a slightly harder job, because you need to understand the intended layering first, and then where you need to get it to. In its simplest form, given these kinds of problems I would be creating layers as they’re required (ones that do not exist) or modifying all code within them, and its usages, to fit into layering practice.

An Example

Let us say that we have a CMS, which currently has a whole bunch of mail() (for non PHP-readers the mail function is documented here), PHP function calls; and we need to enhance the emailing functionality. The specification at the time of creation:

  • CMS must be able to send emails at appropriate times (fulfilled, it does send emails when it needs to)

The new specification:

  • CMS must be able to send emails at appropriate times (fulfilled)
  • We must take new GDPR regulations into account and only send emails to the users which they have approved
  • We must categorise emails at high or medium priority, medium priority messages must not be sent outside of 8pm and 7am, whereas high priority messages must be sent immediately

Likely future specification:

  • In the same instances, we may wish, based on user requirement, to send SMS instead

The way I would look to solve this problem:

  1. Create a Notifications layer through which all systems notifications are sent (end user code sample below), this notification will understand context, so that decisions can be made with regards to type of delivery
  2. Find every instance of mail() in the codebase, and replace it to use my new notifications layer

Userland Code Example

// Create an instance of the notification
$notification = new MessageReceivedNotification($currentUser);

// Set the message which the user has received
$notification->setMessage($theMessage);

// I would normally chain this on, but have not done so for the purposes of readability for those who do not write PHP 
$notification->send();

The Outcome

Now I have a layer in place for all notifications, the next thing to do is make sure that all developers working on the system are aware of this layer, that it is well documented, and everybody knows not to use the mail() function. All notifications now go through the new layer, and injecting new functionality into that section of functionality is a much easier process.

The Prevention

Ideally, you don’t want to end up in that situation in the first place. What you need for this is not only a design of how the layering works, but also a set of rules or standards which ensure that the layering is used in a way which prevents this issue in the first place.

We’ll take the example of a CMS again, with some examples of layers which are required:

  • Notification Service
  • Data Layer
  • Permissions Layer
  • Controllers

And here are some ways that you might introduce that layering, so that functionality can be easily implemented throughout your design.

Interface Facading

Particularly on the Permissions Layer you might want to use the facade design pattern to give a simple interface to interact with the Permissions Layer, this could be further facaded to use helper functions (code samples below). This means that all functionality relying on the facaded layer only ever need to worry about the facade, with no knowledge of how it works, but also that in order to check the permission status you will always use the layer, preventing the problem described above. You may decide that, for the purpose of this shared functionality, you want to make this layer interface through a singleton, particularly if the class itself is doing very little besides providing anaemic functionality to other classes.

class PermissionChecker
{
    public function checkPermission(string $permissionName) : bool
    {
        //  Return true/false based on whether or not this user can carry out this permission
    }
}

function checkPermission(string $permissionName) : bool
{
    $checker = new PermissionChecker();
    return $checker->checkPermission(string $permissionName);
}

Inheritance

Another common way of managing this layering is to ensure that all appropriate functionality extends a base class (inheritance), which encapsulates all the layers shared functionality, again this could facade through to a library of classes. A good example of this would be a Notification Service or Data Layer.

abstract class Model
{
    public static function find($recordId)
    {
        // At this point I am going to fetch a record based on its ID, I can choose to implement caching or other functionality here
    }
}

class Post extends Model
{
    // This class specifically represents the post records, if we're assuming the active record design pattern
}

Data layering is the most obvious to introduce, particularly as most frameworks will have already included this. The important part of the layering process is to understand what else needs to be layered, and consequently how this should occur.

How do I know what I need to layer?

This is impossible to answer really, as you could be programming a blog, or the software behind the next space shuttle launch! The following are not hard and fast rules, but a guideline which you could choose to follow. I personally would consider layering if:

Don’t forget, layers can exist within layers. Your data layer may have layers for caching and database transactions, for example.

  1. When the functionality is reusable (like models)
  2. When the functionality could require modification, which would need to affect everything within its remit (like notifications and adding user preference functionality)
  3. When the functionality is grouped, and might need modification or replacement later (like cart calculations functionality in a commerce system)

How should I invoke my layering?

That very much depends on your use case, personally I tend to consider it like this:

  1. I use inheritance when each instance makes sense to be its own entity (such as a notification, or a record in the model)
  2. I use facading when I am hiding a library of functionality (access permissions works in this case, as you may have a number of functionalities in here, such as super-admin-detection, permissions grid management, IP whitelisting, and infinite possibilities in terms of security management)

Hard Fast Rules (which don’t exist)

Of course, hard fast rules do not exist and every use case has the potential to need to not follow these guides. However, I follow these rules to layer my code properly and ensure it is truly layered/modular.

  1. Do not directly interface with any class which is part of the package/library, that is not the interface or Facade itself
  2. If working within a modular system, never use code which belongs to one module within another (unless it is predefined that this module is dependent on the other)
  3. Particularly within modular systems, having code in separate repositories and IDE projects can help ensure you don’t accidentally use code which is within another module
  4. The moment you think “Gosh, I hope I don’t have to change this later!” you either need to reconsider your base design, or you need to introduce layering there
  5. Follow DRY (don’t repeat yourself) – if you’re copy and pasting code you could almost definitely do with encapsulation, at the very least, but potentially your code should be in its own layer with an interface to allow your modification

Summarised Points to Take Away

  1. If you draw a design, and you have a layer, ensure some kind of physical representation (base class, interface, facade, etc) of that layer exists
  2. Ensure if you’re using layers they’re well documented, and everybody knows they need to use your layer, and how
  3. Layers are important for injecting new functionality later, and preventing the duplication of code

Thank you for reading!

Bringing OOP functionality into WordPress

So if, like me, you’re an object orientated programmer and are suddenly asked to build functionality into WordPress it can feel like you’re trapped into procedural code and functions. Consequently; I thought I would whip up a little tutorial of how to work within WordPress, whilst maintaining your OOP integrity. The reason this is important is quite simple, if you’re building complex functionality into WordPress, you want to be able to use OOP principles and methodologies.

Don’t worry or get confused, themes vs plugins

Essentially, these are the same thing! They use the same library of code, the APIs you can use within WordPress are the same. You could be asked to implement the code in either, and you’ll do it the same way. The real difference is whether you want the functionality to be exposed if the website changes theme, if that’s the case you’ll move the code into a WordPress.

PSR-4 Autoloading

The first thing you’ll want to do is get some PSR-4 autoloading running so that you can use your classes without having a huge set of require, require_once or include statements which can be a nightmare to maintain. If you’re working in a theme put this code into your functions.php – if you’re in a plugin then I would advise you do this in the registration file which might be wp-contents/plugins/yourplugin.php or it might be wp-contents/plugins/yourplugin/functions.php. If in doubt, look for the declaration of the plugin – which will be a PHP code comment as seen here.

I will use JohnoTheCoder as my vendor name and PluginTutorial as the project namespace. The file we’re putting this code into is called whenever WordPress is loaded (because the theme is initialised, as are the plugins) – so you’ll want something like this

/*
    Declare the autoloading - you can repeat this for all your different namespaces if you wish, for example if you're bringing in code from other repositories
*/
spl_autoload_register(function ($class) {

    // The classes I want to autoload are within the JohnoTheCoder\PluginTutorial namespace
    $prefix = 'JohnoTheCoder\\PluginTutorial\\';

    // The class being loaded is not within my namesapce, return early
    if (strncmp($prefix, $class, strlen($prefix)) !== 0) {
        return;
    }

    // All we're doing here is saying that your namespace classes are found within the src subdirectory
    $file = __DIR__ . '/src/' . str_replace('\\', '/', str_replace($prefix, "", $class) . '.php';

    // If the file does not exist - throw an exception with a helpful message
    if (!file_exists($file)) {
        Throw new Exception("Class [$class] not found in expected location [$file]");
    }

    // The file does exist, so require the file
    require_once($file);

});

What this means now is that you can reference JohnoTheCoder\PluginTutorial classes, and they will be looked for within your plugin, for example JohnoTheCoder\PluginTutorial\Subspace\MyClass would be found in plugin-directory/src/Subspace/MyClass.php – of course you can modify this to follow the naming conventions you have in place.

That’s it for this short tutorial – I’ll do some more “OOP in WP” tutorials in the future, to enhance maintainability and help encourage true OOP development within WordPress plugins and themes.

PHP Interfaces, Traits, and Inheritance, how and when to use them

Hi all

So this one is going to be fairly short and simple, I hope! What I am going to cover, and this does assume so prior knowledge, is what interfaces, traits, and inheritance are; and some different use cases for them.

So the first one, and maybe the easiest one to cover, first:

Inheritance

In its simplest term, and I’m going to try and keep things simple in this article. In very brief terms, inheritance is about extending something which exists. Of course, you may well have created this base on which you’re extending.

Simple use case: User class, extended by an Administrator class. This would be because that an Administrator can do everything a user can do, but a User can’t necessarily do everything an Administrator can do.

The way you would do this in PHP would look like:

class User
{
    // Regardless of whether you're a standard user or an administrator you would have access to this method
    public function getUserId() : int
    {
        return $this->id;
    }
}

class Administrator extends User
{
    // Only administrators can delete users
    public function deleteUser(int $userId)
    {
        // Do something here
    }
}

Of course, there are a million ways of using this, but essentially what you’re doing here is following a single line of inheritance, each extension gaining its own functionality. Something else of note is that you can override (except where the final keyword is used) methods and classes.

There are many ways you might want to do this, including several layers of inheritance, or multiple classes extending the same base.

Interfaces

This is concept defines a set of interfaces (or integration points), though the key theme here is that an interface can be applied to anything. You’re specifying very little, except that the class implementing this interface must abide by the rules laid out.

interface Notifiable
{
    public function getEmailAddress() : string;
}

Now the thing to note here is that the interface simply doesn’t care how you retrieve that email address, but you must have a way of doing it, and any class this is applied to must follow those rules.

The easiest use case for an interface, that I can think of, is something like the above. Notifiable, anything within your system could be notifiable. An instance of the system, a user, an organisation, a team or department. It doesn’t matter, applying the interface means that it could be parsed and handled, through a notification service.

Traits

I’ve tried to explain this one recently, and the use case for it. The easiest way I found of explaining it recently has been: An interface lets you define the input and output of some methods, inheritance lets you gain functionality from parent classes. Traits are for where you don’t want to use parent classes (because you can only extend one class at a time), but want to bring the “meat” of some methods across.

At the risk of causing some controversy here (again) I’m going to say the easiest use case to explain with traits is a logging class, which might look something like

trait Logger
{
    // PSR-3 compliant functionality here
}

class MyThingDoer
{
    Use Logger;
}

All this does is allows the MyThingDoer class to do anything that the Logger trait specified.

In Summary

I’m not necessarily advocating the use of these three sets of functionality, or how they should be used, or anything like that. I’m simply documenting their existence and usage in a way that those moving from PHP procedurally into a structured OOP environment might understand it.

I understand there are dependency injection arguments regarding traits, and I think that is a conversation for another day.

So, in a sentence. When you want to have a base class, and things which logically make sense to be extensions – use inheritance. When you want to ensure conformity to a set of rules, so that objects can be parsed into service providers, use interfaces. When you want to simply share functionality across multiple classes, use traits.

I hope this has helped, of course, if you have anything to add, anything you’d like to say or anything to contribute, stories, personal experiences, etc. as always feel free to drop it in the comments.