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.

In a post to his site Kevin Smith wonders "what's so great about OOP?". In it, he goes back to the basics of OOP (object-oriented programming) and keeps it simple, avoiding more advanced OOP-related topics.

One of my core responsibilities as a senior software engineer is mentoring the junior engineers and interns at work. [...] Recently a question came up with our new interns while talking through the design of a feature: What is object-oriented programming? How is it different from what we're doing now, and why should we write code that way?

I wanted to find a fundamental explanation to send them for later, but nearly everything I came across immediately jumped into SOLID or design patterns or advanced concepts of some kind.

He starts from the beginning, where most PHP developers cut their teeth with the language: procedural programming. He provides some (non-OOP) examples of this, making use of simpler functions rather than objects and methods. He then moves on to compare this with OOP. He talks about how it's more than just a different syntax (a shift in thinking really). He refactors his previous example to use objects and methods. He finishes up the post answering one of his original questions: what's the real benefit of OOP over procedural programming.

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.

In response to a few other posts about the use of "final" in PHP development, Freek Lijten has posted some of his own thoughts and some of the things he came to realize about its use in his own development.

I read a blog by Brandon Savage a couple of weeks ago and it triggered some thoughts. He refers to a blog by Marco Pivetta which basically states "Final all the things!". Brandon comes back with a more mild opinion where he offers the notion that this approach might be overkill. Since both posts got me thinking I tried to organise my thoughts on this in the following post.

Freek talks about a pretty common trend in the PHP world: the very rare use of "final". He suggests that "extension" of classes is a bad idea (or at least should be used a lot less) and how he has seen it commonly misused. He then shares two reasons why he thinks "final" is a good idea, mostly centering around how easy it is and how the Open/Closed principle applies. In the end, he notes that he'll be trying to use more "final" in the future and see where it takes him and his code.

The Ibuildings blog has posted the latest part of their series looking at some general programming guidelines and principles that can help you in your own development work. In this latest article Matthias Noback talks about the "life and death of objects" in more detail including creating, updating and how they "die".

In the first part of this series we looked at ways to reduce the complexity of function bodies. The second part covered several strategies for reducing complexity even more, by getting rid of null in our code. In this article we'll zoom out a bit and look at how to properly organize the lifecycle of our objects, from creating them to changing them, letting them pass away and bringing them back from the dead.

He starts with a brief list of things that are true about objects (they live in memory, they hide implementation, etc) and some of the issues with poor object handling. He then gets into some of the basics: creating objects (meaningful & different ways), validating the input to constructors and methods and changing them to update properties and related objects. He also suggests preferring immutable objects and talks about value objects to help towards this goal. Finally he talks about the death of objects and some of the ways you can possibly "bring them back to life".

For those working to move from procedural PHP into a more object-oriented world but may be having some trouble with the transition, the Star Tutorial site has a great beginner OOP in PHP guide you should check out.

They cover all of the basics you'll need to get started with objects in PHP including:

• classes versus objects
• visibility
• inheritance
• polymorphism
• interfaces versus abstract classes

Each section is a quick definition and a bit of code to help illustrate the point. This isn't going to be a hand-holding kind of tutorial showing you each step to making an OOP application. Instead, it provides quick, high level summaries of the main OOP concepts to get you on the right road.

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.