The single responsibility principle, as mentioned in the previous post, should be thought of as nothing more than asking the following question:

A class should have only one reason to change.

The question is far simpler than the answer, though. And through this post and the next, I’m hoping to demonstrate exactly that.

But first, I want to mention that the context for this particular question is with a relatively simple API. This doesn’t mean that the result isn’t as beneficial. It does, however, make for quicker reading and more time to talk about the application of the principle.

Single Responsibility Principle: Submenu Items

According to the Codex, the API for this creating a submenu item requires add_options_page.

Single Responsibility Principle in WordPress: add_options_page

The description of the function is simple:

Add sub menu page to the Settings menu.

And the function accepts five parameters:

  1. The value for the title of the page,
  2. The value to for in the submenu,
  3. The capability required of user to access the submenu item and submenu page,
  4. The slug WordPress will use to identify the menu,
  5. The function for displaying the content on the associated submenu page.

For many, people will call this an administration page, an admin page, a dashboard page, or something similar. And in this example, I’m going to create a class and call it Dashboard. Note there are no comments, no prefixes, and it’s not namespaced,

That is to say that this code is not for production-level (or even really staging-level). Instead, it’s just meant for example and suitable for your local environment.

With that said, see the following gist:

Easy enough, right?

  • The class name is Dashboard
  • There’s a function that can be attached to a hook to initialize the submenu item (like $plugin->init())
  • And there’s a function for displaying the page

And it seems cohesive enough. Remember, though: Each options page may include settings or other information. I’ll talk about that more in the next post.

For now, though, it’s important to think about the single responsibility principle and to see if there are any cases in which this class could potentially change (in its current state or a more mature state).

What About The Options Page?

If you’ve worked with this particular API function before, then you’re aware that an options page is always associated with the submenu item, as well.

If you were to take the code above and plug it into an existing plugin, a new plugin, or some part of your theme, then you would see a new submenu item in the Settings page. Instead of seeing any options, though, you’d see a screen with nothing more than the phrase “Hello World.”

In the next post, we’ll create a slightly more mature version of the page, and we’ll look at how to apply the single responsibility principle to this code.

Category:
Articles
Tags:

Join the conversation! 5 Comments

  1. Hey Tom,

    please don’t get me wrong, … but is the code above to be seen as a positive example?

    In my opinion, this is (really) bad code – OOP-wise.

    You mentioned that there is a (slightly more) mature version to come, but you did not mention in any way that the code really has to be improved. That’s why I’m asking.

    Best,

    Thorsten

    • please don’t get me wrong, … but is the code above to be seen as a positive example?

      Not in the least. This is meant to show how we often see how recommending how to do this. I’m in the process of showing how to break this apart into a more object-oriented design.

      And that’s what I meant, in the final paragraph, in saying:

      In the next post, we’ll create a slightly more mature version of the page, and we’ll look at how to apply the single responsibility principle to this code.

      As for this point:

      You mentioned that there is a (slightly more) mature version to come, but you did not mention in any way that the code really has to be improved. That’s why I’m asking.

      The previous post (as this is a series of posts) defines the single responsibility principle then asks you to ask the question:

      “If this class was to change, what would need to be changed?”

      And then the next two posts walk through exactly how to do that and do so in an object-oriented perspective.

      See them here and here.

      Given more time, we could take this even further with namespaces, dependency injection, and all of that fun stuff, but it messes with the general point that I’m trying to convey.

      And this to define the single responsibility principle, ask the question when you’re writing any module, and then see what you can do to apply it.

      The rest of the stuff is tertiary improvements that are best suited to another post, I think :).

      Thanks for your comment — always happy to clarifying this kind of stuff!

  2. This is meant to show how we often see how recommending how to do this. I’m in the process of showing how to break this apart into a more object-oriented design.

    Alright. I guess I just would’ve expected some more prominent advertising the code having huge potential to get improved, in an object-oriented way.

    I mean, the code is MVC. Unfortunately, though, all of MVC — you have bootstrapping (even self-hooking), you have domain logic (i.e., model, data), you have output logic (i.e., your view).

    Looking forward to reading (and discussing) more OOP stuff. :)

    • In terms of advertising, I don’t really know what you mean. Can you clarify? In the post, I say that it’s the first of several in a series which is meant to explain more is coming. 

      I’m not sure what more I can offer beyond that.

      Also, this code isn’t particularly model view controller. At least not as far as I’m used to employing the design pattern, but it wasn’t mean to be that way, either. It doesn’t communicate with any two other types of entities in the system.

      It’s basically just breaking down a larger class into two classes each of which have a responsibility (or a reason to change).

      • In terms of advertising, I don’t really know what you mean. Can you clarify? In the post, I say that it’s the first of several in a series which is meant to explain more is coming.

        Well, I guess, I just misunderstood the (nature of the) post.

        Also, this code isn’t particularly model view controller.

        Exactly. ;)

        … it wasn’t mean to be that way, either.

        I just used MVC as a fairly well-known example for writing object-oriented code. With MVC in mind, the above class does things that should be separated into at least three (or even four) files/classes.

        Anyway, let’s just agree in that I didn’t grasp what you were trying to convey here. :)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.