When I first set out to offer memberships on this site, I knew the first thing I wanted to tackle was an introduction to object-oriented programming.

It’s something that seems to be interesting to most people who are working in WordPress, but there’s a problem that either turns a lot of people away or generates poor results:

Object-oriented programming can get complicated fast. And this gets demotivating.

Here’s what I mean: Say you’re a WordPress developer who starts to research object-oriented programming. It starts off talking about classes and constructors and functions, and all seems well.

But then it quickly gets into:

  • private and protected methods,
  • inheritance,
  • polymorphism,
  • design patterns,
  • dependency injection,
  • repositories,
  • and so on.

It snowballs, doesn’t it? And that’s not at all how it has to be, but it’s hard to find a proper introduction save for a few resources that are out there.

With all of that said (and serving as a backdrop for where I’m headed), I wanted to set out to create a series of content for those who:

  • are genuinely interested in object-oriented programming,
  • aren’t sure where to start,
  • want to grow their skills,
  • want to start from ground-zero without escalating into more complicated material too quickly.

And that’s what I’m starting today and in the first major serious planned for members. With all of that said, let’s get started.

Specifically, let’st started talking about object-oriented programming, analysis, design, and why she should start there.

[restrict paid=”true”]

Object-Oriented Programming: Analysis

When it comes to writing code, there are currently three popular ways to do so:

Whenever we’re working with and reading WordPress code, you’re going to be reading a combination of procedural code and object-oriented code.

There are some reasons this is the case, but it’s outside the scope of our discussion.

This is because WordPress is built with both and because certain aspects of WordPress development can be written with procedural code, like plugins and themes, and others require object-oriented development like widgets.

Analysis and Design

So often, the first thing that we want to do, as developers (budding or not), is to get immediately into writing code. I get, too. It’s fun. We have an idea, we want to bring it to life, we want to begin using it, and we want to show it to other people.

Here’s the problem with doing that, though: We often skip right into writing code to try to make the project do what we want it to do.

If this is a simple (and I mean really simple) project, then it’s not such a big deal. Honestly, I’ve done that (and GitHub is proof of it). But when it comes to the work we do at Pressware; it’s a different story.

When it comes to projects like that, we want to do a bit of Analysis and Design before writing code.

Which raises the question, what is object-oriented analysis and design?


In short, think of it this way:

The analysis is the process of taking the idea that the client or that you have and excavating what really needs to be built.

This can help you determine what’s the coof to the application and what’s not necessary for the first version of the application. I like to label these as far as the “must-haves” and what are the “nice-to-haves.”

A good rule of thumb is this:

  • must-haves are the things that are core to the application and must go into the first iteration of the project,
  • nice-to-haves are the things that we can eventually build into it

Ultimately, this helps us work towards a strong first version for the client. Perhaps one example is for WordPress:

  • Did the first version of WordPress need to have a plugin API or did it just need to have the ability for people to write posts and publish them on the web?

If you’re building a platform for blogging, does it need to be extensible from the first version? This is nothing more than an example, but you get the idea.

What Makes Analysis So Hard?

I think it often has to do with personas.

For example, we, as programmers, think that a project should always do what the customer wants. The truth is, that’s not always the case.

I mean, eventually, it might be, but the first version of the project doesn’t necessarily need to be that way.

Furthermore, one of the object-oriented programming principles is that we don’t write a lot of duplicate code. But that can be very hard to do if properly analysis hasn’t been done.

Finally, those who are more experienced will say that good software will use tried and true principles – be it design patterns or not – but that it’s able to be amended easily over time. That, in a sense, grows organically.

So What Are We To Do?

In the next article, I’m going to talk about three things we can do, as developers, to make sure the software we’re building for ourselves or others takes us in the right direction.

I won’t say that it’s a silver bullet because I don’t believe that exists, but I will say that it’s a pretty strong approach that I’ve found others to use and well as myself and that it leads to a pretty good direction in terms of object-oriented analysis.

This will eventually take us to design. But we’re not there just yet.