In the first post in this series, I talked all about how I wanted to tackle about an introduction to object-oriented programming within the context of WordPress.
There are some great resources for object-oriented programming but they can use contrived examples, or they can move too quickly for those who are just looking to get started.
In an attempt to keep this from happening, I think talking about OOP in WordPress anchors us to a strong foundation and using practical examples will always be better than using generic examples that are difficult to translate to the domain in which we’re working.
For those who’ve yet to join or who haven’t caught up just yet, the first post hits on the following topics:
- Object-Oriented Analysis,
- Determining Must-Haves versus Nice-To-Haves,
- And Why Is It Hard?
And that’s where this post is going to pick-up.
Object-Oriented Programming: More Analysis
I know: When it comes to writing code, the first thing we want to do is to sit down and start writing code. What’s better than make something happen on the screen?
And when you’re doing this for yourself, it’s not that big of a deal but when you’re writing code that’s going to be:
- maintained by a team of people,
- for sale,
- or for all of the above
It makes a difference. Because good analysis can lead to good organization which can lead to good maintainability.
Otherwise, you’re cobbling something together to ship, and it’s not going to scale well with future versions. And this is is something we’ll be talking about in-depth throughout the series.
But what’s a good way to summarize doing good analysis in three easy steps? This isn’t necessarily a bullet-proof answer, but it’s what we try to do whenever we’re working on projects:
- Make sure the code does what the client wants,
- Apply good object-oriented practices,
- Aim for a maintainable design.
All of this sounds good in theory, but without taking a deeper dive into each, how do we know if we’re doing this right? In other words, this is where we often find books, resources, and other utilities making it hard to become a better object-oriented programmer.
That’s precisely what I want to avoid, so I’m going to dig into each point a little bit deeper.
1. What The Client Wants
This can be one of the most challenging aspects of the entire project often because we, as developers, speak a different language the customer.
Not only will they often use terminology that we wouldn’t use, they often think that what they want on the screen is the best way to go about it. This makes it sound really condescending and wrong to try to correct them, doesn’t it?
I mean, imagine trying to tell someone you know what you want, and they correct you. Handling this with care is something that can gain great relational equity but it takes a certain amount of time to “excavate” what it is they really want versus what they say they want.
And we’re going to dive down into this more in a future post.
2. Object-Oriented Practices
Obviously, this comes from knowing what the good object-oriented practices are and that’s something that I plan to cover.
Many people will say things using things such as:
- the SOLID principles,
- DRY code,
- dependency injection,
- and so on
Are all important to following good object-oriented practices.
And maybe this isn’t a popular thing to say, but I’m of the mindset that trying to use all the things all the time is not always a good idea. That is, you definitely don’t want to have code repeated throughout your code base, but do you have to have inheritance in your codebase?
There are times when principles should be applied and when they can be ignored. But knowing them, when they are best used, and when to use them are key for using said practices properly.
3. Maintainable Design
Simply put, applying patterns and principles to your software when writing it is what will make it much easier to use and to maintain in the future.
But, again, this is contingent on:
- fully understanding what the client wants,
- knowing what practices exist, when to apply them, and when to avoid them.
And to do all of the above, we need to look at each point within its context before taking a step back to look at the bigger picture.
What Does The Client Want?
Obviously, there’s a lot of ground to cover when it comes to the above three points. But if you want to write good, maintainable software within the WordPress economy, it’s important to understand how all of this fits together.
So rather than jumping ahead into writing code or jumping ahead into working on a project, the next thing we’re going to look into is how to take what the customer wants and then decipher that into a set of requirements that allow us to create a statement of work.
This way, we’ll ultimately have a working document of what the customer wants and what we’re going to build, and we’ll all be on the same page.