Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

TutsPlus.com:
Object-Oriented Autoloading in WordPress, Part 3
Dec 01, 2016 @ 11:15:35

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.

tagged: oop wordpress tutorial series objectoriented programming plugin part3

Link: https://code.tutsplus.com/tutorials/object-oriented-autoloading-in-wordpress-part-3--cms-27515

TutsPlus.com:
Object-Oriented Autoloading in WordPress, Part 2
Nov 30, 2016 @ 09:33:08

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.

tagged: oop objectoriented wordpress part2 series refactor singleresponsibility principle

Link: https://code.tutsplus.com/tutorials/object-oriented-autoloading-in-wordpress-part-2--cms-27431

TutsPlus.com:
Object-Oriented Autoloading in WordPress, Part 1
Nov 18, 2016 @ 13:57:08

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.

tagged: oop objectoriented wordpress part1 series interface singleresponsibility principle

Link: https://code.tutsplus.com/tutorials/object-oriented-autoloading-in-wordpress-part-1--cms-27381

Sarfraz Ahmed:
Coding to Interface
Dec 29, 2015 @ 09:27:48

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.

tagged: code interface dependency injection ioc solid principles objectoriented coupling

Link: http://codeinphp.github.io/post/coding-to-interface/

Acquia Blog:
Quick Tips for Writing Object Oriented Code in PHP
Jul 13, 2015 @ 10:58:14

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.

tagged: oop tips objectoriented code modern psr4 namespace typing docblock missing

Link: https://www.acquia.com/blog/quick-tips-for-writing-object-oriented-code-in-php/09/07/2015/3285651

Scotch.io:
S.O.L.I.D: The First 5 Principles of Object Oriented Design
Mar 19, 2015 @ 10:30:47

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.

tagged: solid oop design principles introduction objectoriented

Link: https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

Full Stack Radio:
Episode 3: Ruby, PHP, OO design, testing & other crap with Matt Machuga
Nov 17, 2014 @ 12:15:57

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.

tagged: fullstackradio podcast ep3 ruby objectoriented design testing mattmachuga

Link: http://fullstackradio.com/episodes/3/

Anthony Ferrara:
Foundations Of OO Design
Oct 30, 2014 @ 09:36:24

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.

tagged: foundation oop objectoriented design complex simple developer opinion

Link: http://blog.ircmaxell.com/2014/10/foundations-of-oo-design.html

Mathias Verraes:
Objects as Contracts for Behaviour
Sep 29, 2014 @ 11:10:33

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.

tagged: objectoriented programming oop contract expose behavior property

Link: http://verraes.net/2014/09/objects-as-contracts-for-behaviour/

Brandon Savage:
Using objects doesn’t make an application object oriented
Jul 16, 2013 @ 12:22:34

In this recent post Brandon Savage suggests that just using objects in your application doesn't mean that it's truly "object oriented development." There's other criteria that need to be met to really fit this description.

Lots of developers understand that object oriented code offers advantages over procedural programming. And so, they begin working on creating objects in their own projects, and eventually feel pretty good about what they’ve done. After all, if they’re using objects, their code must be object oriented, right? Well, not exactly.

He breaks it down into three main points that developers should consider when working with OOP in their apps: splitting responsibilities between classes, being polymorphic and using dependency injection. There's no code samples to back up the concepts here, but it's a decent list to think about. There's plenty of tutorials out there about SOLID development and dependency injection in PHP apps, so you might check some of those out to help with these concepts.

tagged: oop objectoriented development responsibility polymorphic dependencyinjection

Link: http://www.brandonsavage.net/using-objects-doesnt-make-an-application-object-oriented