Coupling and cohesion in WordPress and beyond

A concept that comes up a lot while doing object-oriented design is coupling. We use it to describe how connected the different parts of your code are to one another. But, even explained like that, the concept of coupling can still be a hard to grasp.

On top of that, we often pair it with another concept called cohesion. We use cohesion to describe how well the different parts of your code fit together. This tells us whether everything was well-designed or not.

In fact, this is why coupling and cohesion are so important. There’s a strong relationship between them and the quality of your code. Code that doesn’t have any major coupling or cohesion problem is more often of higher quality. It’s more maintainable, reusable and less prone to problems.

That’s why you want to keep these two concepts in the back of your mind when programming. But that’s easier said than done when these concepts aren’t well understood. That’s why we’ll demystify them today.

Defining coupling and cohesion

The introduction only did a small overview of both concepts. But before we proceed any further, we need to take a longer look at both coupling and cohesion. Once we understand them better, we can look at how they relate to each other.

Coupling

If we could resume the concept of coupling to a single word, it would be “interdependence”. Coupling is a way to measure how parts of your code are dependent on other parts of your code. In object-oriented programming, coupling looks like this:

Each arrow in this diagram is a dependency that your class has with another class. The more dependencies a piece code has, the more coupled it is. And the more coupled a piece of code is, the more likely it is to break when you make changes.

That’s because your piece of code is vulnerable to changes from all its dependencies. Let’s imagine that you make a change to the C class. Well, that change could break something in the A class since it depends on the C class.

Types of coupling

So far, we’ve described coupling as a dependence on another piece of code. In reality, coupling can be a dependence on anything. It’s about the external information that your code depends on to work.

If we take our earlier diagram as an example, it describes coupling in an object-oriented programming context. In that context, you can couple your code to classes and/or interfaces. It’s often the context where you hear about coupling for the first time.

That said, coupling isn’t something that you only see with object-oriented programming. For example, you can couple your code to data or global variables. (More on that later!) Those types of coupling don’t require object-oriented programming to happen.

There are also terms to describe these different types of coupling. But you won’t see them used much in practice. Instead, we tend to just say, “This code is coupled to X.”

How to describe coupling

What we tend to focus more on is the amount of coupling that a piece of code has. We use a scale to describe it. You can see a diagram of it below:

On one side, you have code that has a lot of coupling. On the other, you have code with little to no coupling. We use two terms to describe the two sides of this scale: tight and loose.

Tight coupling

When your code is tightly coupled, it means that it requires a lot of external information. In the coupling diagram earlier, most of the classes had dependencies on other classes. This created a lot of tight coupling because classes needed to know about other classes to work.

Tight coupling is something you want to avoid as much as possible. It’s the source of the code quality issues that we brought up earlier. It makes your code more brittle, harder to maintain and less reusable.

Loose coupling

On the opposing side, we have loose coupling. Loosely coupled code doesn’t need a lot of external information to do its job. Most of what it needs is already on hand.

The C class was the most loosely coupled class in our earlier diagram. It had no dependencies whatsoever. When a piece of code has no need for any external information like that, we say that it’s fully decoupled or has no coupling.

It’s ok to have a bit of coupling

You shouldn’t make it your goal to make all your code fully decoupled. It’s a nice-to-have if you can do it, but it isn’t necessary. There are diminishing returns as you remove coupling from your code.

Removing all coupling from your code can be a lot of work. More often than not, it’s more work than maintaining it with a few dependencies. But how many dependencies should your code have?

The reality is that there are no set rules when it comes to this. There’s just no way to calculate the amount of dependencies that your code can or should have. It’s something that you have to keep evaluating all the time.

That’s because coupling will grow and evolve with your code. (It’s like weeds growing in your beautiful code garden!) The two are inseparable from one another. So you have to be vigilant about it.

As your code grows and evolves, you’ll need to check for new dependencies in it. And, when you find these new dependencies, you’ll have to determine if you need to remove them or not. This cycle will continue as long as you keep working on your code.

Cohesion

Now that we’re familiar with the concept of coupling, we can move on to its partner concept: cohesion! Like coupling, we can also resume cohesion to a single word: belonging. Cohesion measures how well various parts of your code belong together.

But what do we mean when we talk about various parts of your code belonging together? Well, let’s imagine that we have code that we’ve grouped together inside a class. (In theory, it could also be in something larger like a plugin.) Cohesion would measure how well this code works together as a cohesive (ha ha!) unit.

Cohesion is a lot like coupling in terms of how we describe it. Like coupling, there are different types of cohesion that we don’t use much in practice. Instead, we tend to describe the amount of cohesion in a block of code using the terms low and high.

Low cohesion

Let’s go back to our hypothetical class that we used to group code together. If we said that this class had a low cohesion, what would that mean? It would mean that the code that we grouped together inside it doesn’t work well as a unit.

The MyPlugin_Utilities class above is an example of a WordPress class with low cohesion. There’s no strong relationship between the is_plugin_active and get_web_server methods. We grouped them together because they didn’t quite fit anywhere else.

Classes with low cohesion suffer from similar issues as those with tight coupling. They’re often difficult to maintain, test and/or reuse. That’s because the low cohesion makes it hard to understand what those classes are doing. (The MyPlugin_Utilities class name also reflects this difficulty in understanding what the class does.)

High cohesion

Meanwhile, a class with high cohesion is one where all the code inside it works well as a unit. A class with high cohesion often has the opposite properties as one with low cohesion. It’s more reliable as well as easier to test and reuse.

Not only that, but a class with high cohesion also tends to be smaller and more focused than one with low cohesion. This results in a class that’s less complex. And, in turn, this makes it easier to understand what the class does.

These are all desirable properties that we associate with high-quality code. They’re also the same properties as classes with loose coupling. But, while they share the same properties, they have different reasons for having them.

A self-reinforcing relationship

This brings us to the great mystery surrounding these two concepts: their relationship! Why are coupling and cohesion related to one another? It’s because both concepts are self-reinforcing.

The diagram above attempts to illustrate how that’s happening. As we saw earlier, coupling measures how much external information a class depends on to work. The less it needs, the better.

Now, when a class has few dependencies, it means that it has everything on hand to do its job. This increases the likelihood that the class has high cohesion. All the code inside works well as a unit and that’s why it doesn’t have a lot of dependencies. (And that’s how high cohesion promotes loose coupling.)

If we look at it from the opposite direction, we can see how tight coupling leads to low cohesion. The more dependencies a class has, the less likely it is that the class works well as a unit. So, in both directions, the relationship between coupling and cohesion is self-reinforcing.

Coupling in the wild

Now that we have a better understanding of coupling and cohesion, we can look at some examples. It’s worth pointing out again that coupling doesn’t only happen in object-oriented programming. Your code can depend on external information even in regular PHP functions.

Coupling to global variables

Due to its age and focus on backwards compatibility, WordPress still relies a lot on global variables. In fact, there’s even a codex page dedicated to all the global variables that WordPress uses. For example, you can only access the wpdb class through the global variable that stores it.

The my_plugin_search_posts_by_title function above is an example of a function that uses the wpdb global variable. But, by using it, it also became coupled to the wpdb global variable. my_plugin_search_posts_by_title cannot work without it.

This is the main reason why you shouldn’t use the global keyword. When you use it, your code now depends on the global state to work. This almost always leads to serious code quality issues. (It’s also why it’s one of the worst forms of coupling.)

This code quality issue becomes obvious when you want to test the my_plugin_search_posts_by_title function. Because the function uses the wpdb global variable, there’s no way to isolate and test the code inside the function. This makes it harder to test because you must also ensure that the wpdb global variable exists and works.

How to reduce coupling to global variables

Coupling to global variables is a problematic issue to deal with. it’s often a fundamental part of the design of an application. (For example, WordPress can’t work without its global variables.) This makes it a challenging exercise to code in a way that avoids coupling to global variables.

In practice, you can’t remove all coupling to global variables. That said, you can still mitigate the impact it has on your code. The primary way to do that is to limit the coupling to a single function.

Here’s our previous example that we modified to use this strategy. We created the my_plugin_get_wpdb helper function to fetch the global wpdb object. It’s now the only function that depends on the wpdb global variable.

We then replaced the global variable in the my_plugin_search_posts_by_title function with a call to the my_plugin_get_wpdb function. Because of this change, we can now test the my_plugin_search_posts_by_title function. We can mock the my_plugin_get_wpdb to return a mock of the wpdb class.

Greedy coupling

Another way that we create coupling is by being greedy. In the context of coupling, being greedy is when we ask for more external information than we need. It’s often something that we do without intending to.

This is why the following example is interesting. It’s from another article on this site. (We all make mistakes!) It’s a great example of this greedy type of coupling. (The technical term for it is “stamp coupling“.)

Above, we have the WPMemeShortcode_Shortcode class with a dependency on the WPMemeShortcode_Options class. The problem is that we only use a single option from it: size. We don’t use the class for anything else and that’s why it’s a greedy dependency.

Often, we create this type of coupling because we’re trying to protect our future selves. We expect that we’ll need more than one option in the future so we ask for the WPMemeShortcode_Options class now. But all we did in practice is create coupling to meet a hypothetical need.

Removing greedy coupling

Fixing this type coupling is pretty straightforward. We know that we asked for too much information. So all that we need to do is change our dependencies to be less greedy.

Here’s the fixed WPMemeShortcode_Shortcode class. The dependency on the WPMemeShortcode_Options class is gone. We replaced the options internal variable and constructor parameter that we used for it.

Instead of the WPMemeShortcode_Options class, we use an integer. It represents the default size of a meme generated by the shortcode. We store it in the default_size internal variable.

Coupling through inheritance

One of the most important features of object-oriented programming is inheritance. It’s the feature that lets you create a class that extends another class. When you create a class that way, it comes with a relationship to the class that it extends.

The diagram above illustrates this relationship. We have the derived class (also known as a child class or subclass). This class extends a base class (also known as parent class or superclass).

This relationship between the base class and the derived class is also a type of coupling. The derived class needs information from the base class to work. In fact, if the base class wasn’t designed with this relationship in mind, it can be a real problem.

In that situation, changes to the base class can break a derived class. When that happens, it means that there’s a tight coupling between the two classes. We call this form of tight coupling “subclass coupling”. The common consequence of it is something called the “fragile base class problem“.

Strengthening a base class

There are a couple of solutions to this coupling problem. One of them is just to trust your fellow developers to extend your classes as you intended them to. You’d want another developer to extend (ha!) the same courtesy.

That said, the world isn’t black and white. You might not want to rule with an iron fist. But you might still want to deal with this type of coupling in some situations. So let’s do that!

But first, let’s start by creating an imaginary base class. We’ll call it MyPlugin_Base. (I know it’s quite the original name!)

The MyPlugin_Base has a constructor that accepts the variable parameter. It sanitizes it using filter_var before assigning it to the variable internal variable. There’s also the get_variable method that returns the value stored in variable.

Now, this is just the MyPlugin_Base class. Without a derived class extending it, it’s hard to know what problems the MyPlugin_Base class has. So let’s look at derived classes that modify it in problematic ways and what we can do about it.

Securing a base class using encapsulation

The MyPlugin_Derived class shown above might look innocuous to you. After all, how much damage can the set_variable method do? Well, a fair bit.

The set_variable method doesn’t sanitize the new variable that it gets. This breaks the expectation that the MyPlugin_Base class has. It expects that it will always deal with a sanitized variable. This can have some serious security consequences depending on what your code does.

So how do we fix this? One possible solution is to leverage encapsulation and method visibility. This lets the MyPlugin_Base class control what variables and methods derived class has access to.

Above is our secured MyPlugin_Base class. We achieved that by changing the visibility of the variable internal variable. We switched it from protected to private.

Doing this prevents a developer from creating a method like set_variable. There’s no way for the MyPlugin_Derived class to access the variable internal variable anymore. It can only get it through the get_variable method.

Finalizing elements of a base class

Now, let’s say that we’re dealing with a clever developer. They really want to add that set_variable method! They could create a MyPlugin_Derived class like this:

The MyPlugin_Derived class now has a derived_variable internal variable. The developer uses it to hijack the variable internal variable in MyPlugin_Base. They then create their own get_variable and set_variable methods using derived_variable.

This is a more drastic (and maybe less realistic) example. But it’s always something that someone could do. (I might have done this a few times…) If you’re not careful, you can introduce a lot of bugs extending a class that way.

That said, as the developer of the MyPlugin_Base class, what can you do? Well, you can use the final keyword. This lets you prevent the MyPlugin_Derived class from overriding elements of the MyPlugin_Base class.

Above, we modified the MyPlugin_Base class and made the get_variable method final. This blocks the MyPlugin_Derived class from overriding the get_variable method. And, as a result, the MyPlugin_Derived class can’t hijack the variable internal variable anymore.

Compromising with an interface

The solutions to strengthening a base class can be pretty extreme. (And they also tend to go against the spirit of open source.) There’s often no need to do something that drastic in practice. Well, that’s unless you’re trying to favour composition over inheritance.

That said, you might still want to reduce coupling through inheritance. But what can you do without resorting to the extreme options seen above? You could use an interface!

Creating an interface for our base class

Let’s go back to our MyPlugin_Base class and create an interface for it. Keeping with our original naming scheme, we’ll call it MyPlugin_BaseInterface. You can find the code for it below:

The MyPlugin_BaseInterface has a single method: get_variable. This is the method that we want the contract to enforce. Now, let’s have the MyPlugin_Base implement it.

As you can see, we reverted the MyPlugin_Base class to its original state. All that we did is add the implements operator at the top. This formalizes the relationship between the MyPlugin_Base class and the MyPlugin_BaseInterface interface.

Coupling through type hinting

So why does an interface create less coupling than a class? A good way to show you why is using a feature of PHP called “type hinting“. It lets you enforce the type of a parameter that function or method accepts.

The my_plugin_get_base_variable function above requires that the base parameter be an instance of the MyPlugin_Base class. The function uses the get_variable method to get the variable stored in base. It then makes changes to the variable and returns it.

Now, type hinting is a good practice. It saves you the need to add guard clauses to your function. You’re always sure that base is an instance of MyPlugin_base.

Favour interfaces with type hinting

That said, we also created a pretty tight coupling between the two in the process. In reality, we only needed the type hint to use the get_variable method. Were we greedy once again? (Uh oh!)

No, this isn’t greedy behaviour like we saw earlier. We didn’t ask for the MyPlugin_Base class because we wanted more external information than we needed. We asked for it because it was the only way to ensure base had the get_variable method. We had no other choice.

But that’s why you should always try to use interfaces with type hints. An interface, like the MyPlugin_BaseInterface interface we created earlier, is only a contract. It doesn’t contain any behaviour like the MyPlugin_Base class does.

Here’s the updated my_plugin_get_base_variable function. It hasn’t changed much from the previous version. We changed the type hint from MyPlugin_Base to MyPlugin_BaseInterface. That’s it.

But this small change is enough to reduce the coupling in the my_plugin_get_base_variable function. Now, the function doesn’t need to always get an instance of MyPlugin_Base. It just needs an object implementing the MyPlugin_BaseInterface interface. This still ensures that the get_variable method is there.

Cohesion and your class’s job

Wow, so we’ve talked a lot about coupling. But what about increasing cohesion? What can we do about that?

Well, increasing cohesion is a much more natural process than decreasing coupling. That’s why it doesn’t get talked about as much. With object-oriented programming, it all comes down to the job of a class.

This is something that comes up over and over in object-oriented design. You always want to ensure that a class has a job. This gives it purpose, but it also ensures that the code in it doesn’t have a low amount of cohesion.

But it’s also something that you have to keep reviewing. You code will evolve over time and a class can lose cohesion as a result. When that happens, there’s a good chance that it’s because your class now does too much.

The solution is to break up your class into separate classes. This should create classes with higher cohesion than the original class. Not only that, but your new classes should also have less coupling than the original class as well. That’s because we spread the dependencies throughout the new classes.

The never-ending battle

As you might have noticed by now, coupling and cohesion are huge topics. This only scratches the surface of it. There are design principles and philosophies based on these topics as well.

But what defines these two topics is their longevity. You’re never going to be done with them. The only way to be done with them is if you stop coding. (And we know you don’t want to!)

This is due to an idea called software entropy. It states the following:

  1. A computer program that is used will be modified.
  2. When a program is modified, its complexity will increase, provided that one does not actively work against this.

This means that, as your code matures, coupling and cohesion will grow in importance. You’re going to worry about them more and more. That’s why it’s crucial to know about it.

  • I love the topic of Coupling and Cohesion. I learned about it during a programming seminar in 1989, and learned so much I kept the course materials all these years!

    Several comments on your post.

    1.) You mention that high cohesion promotes loose coupling. That is definitely true when you are talking about external coupling, but it is helpful to note that high cohesion correlates strongly with high internal coupling and vice versa. That is one of the hallmarks of encapsulation. I find it helpful to explain this as I have had students assuming all coupling is bad, which is not the case.

    2.) Another comment is about your removal of greedy coupling. While I agree that including WPMemeShortcode_Options $options is flawed because of coupling. You chastise the approach as being to future sighted, and I agree, but your solution of replacing it with $default_size its itself too short-sighted. Replacing an container as the first parameter to the class constructor with a single scalar value trades one sin for another.

    Your single scalar value establishes a signature for instantiating the class which then becomes coupled to code that instantiates instances of the class, but you cannot be sure that were will not be a parameters that need to be passed more frequently than size as your class evolves. You then must add arguments which, over time, can result in unwieldy instantiations like new Foo( null, null, null, 5 ) or worse updating the instantiation signature breaking prior working code.

    Much better to use Structural Typing and accept any object or array as the parameter to your example class constructor where one of its properties/elements could be $size.

    But if you find it extremely important to have a type-hinted constructor — as I expect you might — you can create a factory method such as ::new_with_size( $size ), ::from_size( $size ) or similar, depending on your preferred naming convention. These can then call __construct() passing it a properly structured object or array, and you can have the best of both worlds; the flexibility of Structural Typing and the enforcement of type hinting.

    3.) Lastly, I'll comment to say that your recommended use of interfaces is actually a counter-example for coupling, and it is why I choose to avoid using interfaces in my WordPress-related architectures. Yes, definitely, type hinting your interface is less coupled than type hinting the class, but type hinting with object and then using method_exists( $base, 'get_variable' ) to guard against misuse is even less coupled.

    The above is one of the main ways to implement Structural Typing in PHP, which I favor over interfaces. Why? Because interfaces require you modify and/or implement a container class for exiting classes when in fact you might already have a class that has the requisite properties and/or methods. And being able to use classes that do not have to first be decorated is especially helpful when you are using someone else's code, code which does not give you the luxury of replacing their class with your own.

    A perfect example is the WP_Post class in WordPress and its to_array(), filter() and get_instance() methods. To understand the concern, try setting $GLOBAL['post'] to an instance of your container class at the top of a theme template and watch how quickly WordPress reverts it back to being of class WP_Post.

    Anyway, JMTCW.

    • Thanks for the input Mike! This was a challenging article to write for me. I think there’s some weaknesses to it, but this is the best I could do at this point in time lol

      #1
      I think this is a great point! I’m not sure how I’d approach it without muddying the waters too much. I already felt I was navigating a minefield trying to keep the topic approachable lol

      #2
      I think, outside the philosophical debate between using structural typing or not, the example is simple. Was it really that bad to use the WPMemeShortcode_Options class? I don’t think so. The point was to show the line of questioning that you should have.

      Your example kinda highlights this idea. If you have a constructor that looks like new Foo( null, null, null, 5 ), that’s a code smell.

      Why do you have 3 out of 4 arguments that are null? Is my class doing too much? Is it asking for the wrong information? Should we pass it a value object? Those are all questions that I feel relate to this greedy coupling.

      I’m a huge fan of custom constructors like the ones you mentioned! I think it really depends on the context whether you should use them or not. I just don’t think they justify using an array as your only constructor argument. But I think that’s more of a philosophical debate than a right or wrong thing lol

      #3
      I think that’s another philosophical debate. I like typing through interfaces. It forces you to think in terms of a public API.

      Duck typing and structural typing make some assumptions that I don’t feel as comfortable with. For example, the fact that an object implements get_id (or some other generic variable name) doesn’t tell me much about it. In some situations, it doesn’t matter. But, if I need a post ID and only a post ID, then it doesn’t help me because I could be getting the ID of anything. I just know that it implements the get_id method.

      Having a public API through an interface at least ensures certain expectations. That’s why I prefer it to a more structural approach. That said, it’s definitely the more popular way of doing things in the WordPress world. I think it does make it easier to maintain the level of backwards compatibility that WordPress wants.