There are many ways of architecting software. There are many ways of organising code. When an architect (in this case Software engineer or programmer) decides to create a plugin, he/she must decide how they’re going to organise the logic of the code. In the Single Responsibility principle, we should write classes or modules to cover the responsibility of a single part of the software.

With WordPress, the Single Responsibility pattern is one where you break up the code into classes for each page, setting, functionality to cover a single part of the entire plugin. So each admin page may have its own class, or each config page may have its own class, or functionality to create Products can have its own class (as an example).

I created a WordPress plugin for a company called Whitespark this last week based on the Single Responsibility Principle. I was given permission to put the plugin on GitHub and add it to my portfolio. You can view it here Citation CP Repo.

I broke the structure of this plugin down like this:
/main-folder
– assets
—css
—-style.css
– classes
—admin
– …pages for admin page
– … classes related to the different functionalities
– mainfile.php

I have decided to place the initiating functionality in the main plugin file. I’m using WordPress hooks to decide when something is initiated. In the version I have created so far, I didn’t use this, but in the future (maybe by the time you read this?) I will be adding code that autoloads all the classes so I don’t need to require every single class. In this plugin, in hindsight I have seen some other things I will be updating also, but these things I would update have more to do with keeping the code clean rather than violating the principle. There are some classes that have HTML mixed in with the PHP code, which makes it look sloppy. I will be moving these to template parts, which are smaller files with chunks of HTML that you can include with the get_template_part function.

I wanted to create one class that dealt with displaying a table of content, and I wanted this table to be displayed using a shortcode. In the class above, I have the function called output. In another kind of plugin, I would make this class much more flexible in what kind of tables/content it would output. I have the html content mixed with PHP code in this class, and this is the class I will probably re-structure different where there is no HTML code in the output function. What I’m hoping to show you with all the classes I have created in this plugin is how you might use the single responsibility principle. When you break up all your code into classes that deal with one part of the functionality, it will make it much cleaner and easier to read.

The shortcode class simply gets initiated, and creates a new shortcode. In this shortcode class I can add several others because that’s the whole purpose of this class, and then I can tie the shortcodes to their individual classes so those classes get instantiated when used. I also have a Custom post class that deals entirely with creating custom posts, and this class gets called every time you load a page because it’s using the WordPress ‘init’ action hook.

If you want to have a plugin or software architecture created where you can deal with individual classes for each part of the software functionality, I would suggest you go with the Single Responsibility Principle. There are many principles someone can choose to use when creating anything software related, the only thing you can do is choose the best one that suits the job.