A few years ago I was working on a WordPress-powered web application that used several custom post types, each of which required a different class to query it. The classes included a lot of repetitive code because the queries and a lot of other things I was doing was different.
Somewhere during this project, I noticed that the pattern I established and cut and pasted across four different classes was very wrong. I recently came across my first Carl Alexander article on polymorphism in PHP, which introduced me the concept of abstract classes in object-oriented PHP.
I re-read the article a few times and put it to use. I fixed the bad pattern, and, instead of repeating it four times, I made an abstract class and extended it four times. The next time I needed to make a change to that code, I made the change once — and the other four classes inherited it. We call this leveling up.
It was not the first time I leveled up thanks to Carl. Since then I have recommended a lot of Carl’s article to other developers and have leveled up several more times.
I had the pleasure of meeting Carl in person at WordCamp US, where we talked about PHP and WordPress development. I recently spoke to him again about ways that we as WordPress developers can improve our PHP chops. This article highlights some of the takeaways from our conversation.
Read More Source
I’ve long been an advocate of learning by reading source code from other developers. To learn how to better utilize the WordPress REST API without any documentation, I read the source.
I didn’t just do it to write the article or learn how to do something. I did it because the WordPress REST API is really well written and I wanted to learn by studying how they made it work.
Carl agreed. He told me that reading other’s source code is “the secret sauce for improving your coding skills.” He also gave me some really helpful questions that we should be asking ourselves when reading other developer’s code to make sure we get the most out of it:
- What problem are they trying to solve?
- What are they doing to solve it?
- What do I need to do to make their solution work for me?
This type of thinking will improve your skills as a developer because you’re not just copying and pasting code. You’re actually emulating the developer who wrote it by putting yourself in their shoes and thinking like them.
Software design is about patterns. We constantly re-use common patterns to accomplish specific goals. One of the reasons we read code is to learn patterns and to see how they get used in real life. That said, there are two patterns commonly used in WordPress that Carl feels are misused.
These two patterns are the singleton pattern and the pattern of putting hooks in the class constructor. These two issues are related.
The singleton is a design pattern that is used to ensure that there is only one instance of a class. It is helpful when a class is only used in an application where there is one single object of that class that all other classes and functions share.
The singleton pattern is generally accomplished using a private constructor and a static method to get a class instance. For example:
Since the construct method of this class is private, instantiating the class directly will cause an error. We instead want to use the public static method to call any other methods, therefore always working on the same single instance of this class.
This is great when used properly. But according to Carl, and I agree, it's overused.
"The main reason [the singleton is] popular with WordPress developers is because of the plugin API," Carl Said. "It's hard to use object-oriented programming with it. To solve that problem, they tend to put all their hooks inside the class constructor. But this creates a new problem.
Now, all those hooks get registered whenever there's a new instance of that class. At that point, they feel compelled to use the singleton pattern to lock down the constructor.
But the real solution isn't the singleton pattern. It's to not register those hooks inside the constructor."
I would add that this is often a symptom of classes that have too many responsibilities. Carl has a great article on the single responsibility principle. Similarly, Tom McFarlin's article on the same subject had a huge impact on me and led to me writing smaller classes with a lot less going on in each.
Composer And Cross-Pollination
Speaking of small reusable classes. Composer and relying on an autoloader, which I use Composer for as well, has enabled me to write more reusable code. Carl sees Composer as not just a software tool, but an enabler for collaboration across projects, languages, and more.
"The PHP community has embraced that idea a lot over the last few years," Carl said. "I can't give enough credit to Composer for helping share code between PHP projects. That said, the package manager, the idea behind Composer, isn't new. It's just a cross-pollinated idea from other languages like Python and Ruby.
You learn a lot as a developer by looking at how others solve problems. This is something I wish the WordPress community promoted more. We don't spend enough time outside our own borders. That's the biggest difference I see between WordPress developers and other developers."
If you reading PHP from non-WordPress developers, you will quickly notice that they are less likely to be concerned about supporting out of date versions of PHP. One major advance in PHP since 2009 is anonymous functions.
"On the surface, anonymous functions might not look like much to you," Carl said. "But there are a lot of cool things that you can do with them. In some situations, they can even make you rethink how you write your code.
That's because they act as a disposable functions. You can use them once or even pass them around in a variable. But, like a variable, they don't exists beyond the scope where you defined them.
This lets you do things that were a lot harder or impossible to do before. It also lets you cleanup your code by removing functions that you used only once. Instead, you pass anonymous functions as your callbacks."
You can learn a lot from reading tutorials and articles from developers like Carl, Tom McFarlin, Micah Wood, and others. If you're not already reading Carl's posts I encourage you to sign up for his mailing list and read his back catalog.
If there is a writer who has helped you level up your PHP skills please share their name and a link to one of their posts in the comments below. While I'm going to keep reading everything Carl writes in 2016, I'm also going to make it a point to head his advice to read more non-WordPress PHP code and seek out articles written about PHP by non-WordPress developers. I hope you will too.