On the TutsPlus.com site, they've posted a tutorial for those wanting to get started with object-oriented programming (OOP) in PHP. In this introductory article they cover the basics of objects, classes and several over OOP-related topics.

In this article, we're going to explore the basics of object-oriented programming in PHP. We'll start with an introduction to classes and objects, and we'll discuss a couple of advanced concepts like inheritance and polymorphism in the latter half of this article.

The tutorial starts with the basics, explaining some of the key terms involved in OOP and how they can be manipulated. From there they include code examples of classes, making instances of them as objects and accessing properties and methods. With those basics out of the way, they move on to more advanced topics: encapsulation, inheritance and the basics of polymorphism.

TutsPlus.com has continued their series covering object-oriented development practices in WordPress (plugins) with this third tutorial. In previous parts they set up the environment and introduced some of the basic concepts of OOP programming and getting the first classes and files defined.

In the last tutorial, we reviewed the original state of our autoloader and then went through a process of object-oriented analysis and design. The purpose of doing this is so that we can tie together everything that we've covered in this series and the introductory series.

Secondly, the purpose of doing this in its own tutorial is so we can spend the rest of this time walking through our class, seeing how each part fits together, implementing it in our plugin, and then seeing how applying object-oriented programming and the single responsibility principle can lead to a more focused, maintainable solution.

They start with a brief review of what they've covered so far and begin to build on the changes suggested in the previous part of the series. They've already broken it down into the different functional classes (according to the single-responsibility principle) and take the next step of including them and calling some example code to prove all is working as expected.

The TutsPlus.com site has posted the next tutorial in their "Object-Oriented Autoloading in WordPress" series - part two - expanding on the basics presented in the previous part of the series.

In the previous tutorial, we covered a handful of concepts, all of which are going to be necessary to fully understand what we're doing in this tutorial. Specifically, we covered the following topics: object-oriented interfaces, the single responsibility principle, how these look in PHP [and] where we're headed with our plugin.

[...] Ultimately, we won't be writing much code in this tutorial, but we'll be writing some. It is, however, a practical tutorial in that we're performing object-oriented analysis and design. This is a necessary phase for many large-scale projects (and something that should happen for small-scale projects).

First they briefly cover the environment you'll need to follow along (already set up if you followed along with part one). They then get back into the code, evaluating the current state of the custom autoloader and investigating how it can be broken down into a class and a set of methods instead of procedural code. They work through the different functional parts of the autoloader and how to break it down into classes with only one job (the "single responsibility principle"). They end up with the autoloader that uses NamespaceValidator, FileInvestigator and FileRegistry instances to get the job done.

The TutsPlus.com site has posted the next part of their series looking at autoloading in WordPress plugins. In this latest post the most from just the namespacing and setup into the actual code - creating some simple object-oriented classes that can be easily autoloaded.

I recently wrapped up a series in which I covered namespaces and autoloading in WordPress. If you're not familiar with either of the above terms, then I recommend checking out the series. [...] While working on the series, specifically that of the autoloader, I couldn't help but recognize a number of code smells that were being introduced as I was sharing the code with you.

This isn't to say the autoloader is bad or that it doesn't work. If you've downloaded the plugin, run it, or followed along and written your own autoloader, then you know that it does in fact work. But in a series that focuses on namespaces—something that's part and parcel of object-oriented programming—I couldn't help but feel uncomfortable leaving the autoloader in its final state at the end of the series.

They move away from just autoloading and namespacing quickly and move into OOP concepts like interfaces, implementing them, the "single-responsibility principle" and a few other helpful principles. They define the goals for the work ahead and move into the code, updating the current state of the plugin to use these new ideas.

On his Code in PHP site *Sarfraz Ahmed * has a post talking about coding to interfaces, how its done and why he thinks it's an essential part of any application.

One of the nicest things you can add to your programming skills is coding to interface.

One of the nicest things you can add to your programming skills is coding to interface. One of the five principles of S.O.L.I.D is Dependency inversion principle which states: [...] High-level modules should not depend on low-level modules. Both should depend on abstractions [and] abstractions should not depend on details. Details should depend on abstractions.

He elaborates on this "pretty formal definition" with an example MySQL wrapper class used in a User class, making them tightly coupled to each other. He also points out the same with a `UserController. As a solution to this tight coupling problem, he suggests using dependency injection (inversion of control) to pass in instances of the classes rather than creating them internally. This still couples them, though a bit more loosely, so he suggests using an interface for the dependency instead of a concrete class. This way any number of potential classes could be passed in and the class internally knows how to use them.

On the Acquia blog Adam Weingarten has shared some tips for writing good (and modern) object-oriented code in PHP:

Recently I began working on a D8 module, but this isn't a story about a D8 module. The work I did provided me an opportunity to get back to my pre-Drupal object oriented (OO) roots. Writing OO code in PHP presented some curve balls I wasn’t prepared for. Here are some of the issues I encountered:

His tips touch on things like:

• Using a code structure that can be autoloaded via PSR-4
• Namespacing your classes
• Working with types and type hinting
• Using docblock comments for autocomplete in IDEs

There's also a few other quick topics he finishes the post out with: the lack of enums in PHP, working with associative arrays, no functional overloading and assigning responsibility to classes.

On Scotch.io today they've posted a tutorial about SOLID, the "first five principles of object oriented design". SOLID is an acronym made from the first letter of several principles that can help make your OOP code well-architected and easier to test.

S.O.L.I.D is an acronym for the first five object-oriented design(OOD) principles by Robert C. Martin, popularly known as Uncle Bob. These principles, when combined together, make it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development. Note: this is just a simple “welcome to S.O.L.I.D” article, it simply sheds light on what S.O.L.I.D is.

They start with a basic overview of what the letters in SOLID stand for and then work through each, providing basic code examples to help make the point clearer.

The Full Stack Radio podcast has released their latest episode today - Episode #3: Ruby, PHP, object oriented design, testing and other crap with Matt Machuga, with host Adam Wathan.

In this episode, Adam talks with Matt Machuga of Think Through Math about being a Rubyist who still writes PHP and the differences between writing PHP like a Rubyist vs. writing PHP like a Java developer. They also talk about common struggles when learning new things, and trying to remain pragmatic while still pushing the boundaries of what you know.

Links in the show notes include Matt's personal website, DHH on dependency injection and a book on Domain Driven Design. You can check out this episode either using the downloading the mp3. If you enjoy the episode, be sure to subscribe to their feed.

In his newest post Anthony Ferrara looks at some of the things he calls the foundations of object-oriented design, as set of three things (and principles) to keep in mind when working on OOP applications.

It's quite easy to mix up terminology and talk about making "easy" systems and "simple" ones. But in reality, they are completely different measures, and how we design and architect systems will depend strongly on our goals. By differentiating Simple from Easy, Complex from Hard, we can start to talk about the tradeoffs that designs can give us. And we can then start making better designs.

He starts with the "simple vs easy" concept and how sometimes making the two meet can be difficult. He includes an example of interdependent interfaces and how they add complexity (and, in turn, make them less easy to use). He also talks about accidental versus essential complexity and how, sometimes, "accidental" isn't always a bad thing. Finally, he wraps it up with a few principles to remember in your development including recommendations to reduce (accidental) complexity and keeping the target developers in mind, making it easiest for them to use.

Mathias Verraes has a new post to his site today with an interesting idea when it comes to handling the architecture of an application: using objects as the contracts for behavior. He suggests that the objects themselves define how other pieces of code should interact with them, not necessarily external services. He illustrates with an invoice and appointment example.

Of course invoices do not pay themselves, but that’s not what an object model is trying to do. An invoice exposes the behaviour of being able to be paid. That ability is in fact essential to what it means to be an invoice. The behaviour is an inherent property of an invoice. If an invoice doesn’t have the ability of being paid, there’s no point in issuing invoices at all. In other words, the contract of an invoice object declares that its interface includes payment as a feature. Its promise to the outside world is that it allows an outsider to pay for it. Encapsulation of state and behaviour is the core idea behind objects.

He wonders why, if this is more true to the "object-oriented programming" ideals, the idea of encapsulating procedural code as objects is so widespread. He suggests a lack of education on the subject or maybe even confusion from spoken languages themselves.