Over the last few posts, I’ve walked through the process of taking an idea from concept to prototype.

Granted, there are some things that you might change (and there are some things I’d change regarding organizing classes). But the point of the series isn’t to walk through all of the various object-oriented techniques that can be used to create a solution.

Instead, it’s about taking a prototype and converting it into something a little more professional. There’s still one thing that we need to do, though.

Right now, we include all of our files through require statements. And this works alright for small files, but introducing autoloading in conjunction with namespaces can make the application even cleaner.

And that’s what we’re going to do.

Continue reading

The previous post demonstrates a lot of work in taking something that was once a rapid prototype and taking that prototype to code. If you haven’t been following along, we’ve done the following:

1. talked about and built a prototype for a plugin,
2. diagrammed out one object-oriented approach may work,
3. and refactored our prototype to actual code.

At this point, there are a few more things we can do to improve our code. Namely, we can introduce the concept of namespaces. This takes the organization a step further and can pay dividends for larger projects.

So here’s a look at how this plays out in our current project.

Continue reading

As far as rapid prototypes and WordPress are concerned, we’ve done two things thus far:

1. planned the plugin,
2. sketched out a diagram for how the code can be organized

At this point, we’ve done enough work to warrant beginning to refactor our code. That is, we’re going to start converting the prototype to code. But this is something that’s going to need to be done in two phases.

First, we’re going to simply introduce classes that represent the diagrams from the previous post and that encapsulate the responsibility of each project.

After that, we’ll look at organizing the code into namespaces and packages. Before we can do that though, we need to make sure the code is object-oriented and remains functional. So that’s what’s going to happen in this post.

Continue reading

In the previous post, I started walking through the process of taking the idea for a plugin that rapidly prototyping it into something that works within WordPress. And though it works, it doesn’t necessarily follow any object-oriented principles, nor is it in a place that we can easily continue to add features.

No, this isn’t an argument for why object-orientation is better. It happens to be my preferred way of writing code so I’m approaching it this way.

I know that the example code I’m giving is simple and I know that a case can be made that something like this can be left as it is. But the point of this is to show how to take a concept, prototype it, and then move it into something that follows object-oriented principles.

And, in my experience, it’s much harder to do that with a complex example from the outset. if you lose readers from the beginning, then what hope is there for them to understand what’s coming?

So with that said, we’re going to take a look at the code from the previous post and do a bit of a concept analysis on it to see what might work well within a class and how we might begin to organize it using classes, namespaces, and so on.

Continue reading