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.

Brandon Savage has a tutorial posted to his site covering the use of setter injection, some of the issues that can come with using it and how to avoid it.

PHP more or less has two kinds of dependency injection available: constructor injection, and setter injection. Constructor injection is the process of injecting dependencies through the constructor arguments. The dependencies are injected via the constructor, on object creation, and the object has them from the very beginning.

Setter injection is different; instead of providing the dependencies at construction time, the dependencies are provided via setter methods, once the object has been constructed. This allows the flexibility to configure the object during the runtime, rather than at construction.

He goes on to point out two flaws with setter injection: "half-baked" objects and the injection of potentially unused objects/resources. He spends the remainder of the post covering each of these topics more specifically and wraps it up with a recommendation to avoid it if possible and opt for useful, "fully baked" objects injected via the constructor instead.

Brandon Savage has a tutorial posted to his site covering the use of setter injection, some of the issues that can come with using it and how to avoid it.

PHP more or less has two kinds of dependency injection available: constructor injection, and setter injection. Constructor injection is the process of injecting dependencies through the constructor arguments. The dependencies are injected via the constructor, on object creation, and the object has them from the very beginning.

Setter injection is different; instead of providing the dependencies at construction time, the dependencies are provided via setter methods, once the object has been constructed. This allows the flexibility to configure the object during the runtime, rather than at construction.

He goes on to point out two flaws with setter injection: "half-baked" objects and the injection of potentially unused objects/resources. He spends the remainder of the post covering each of these topics more specifically and wraps it up with a recommendation to avoid it if possible and opt for useful, "fully baked" objects injected via the constructor instead.

On his site, Daniel Gomes has written up an article that makes a suggestion about working with objects in PHP. In it, he suggests performing a deep copy of them rather than just cloning them into a new variable.

As you know, PHP has a well-known clone keyword that shallow copy all of the object’s properties. So under the hood what it does is to create a new Object with the exact same values of that object properties – unless you change its behavior by implementing the __clone() function in your class.

This behavior seems what we expected. However, it might give “weird” results if the object that you are cloning contains properties that are objects.

He gives an example of this "weird" result when cloning an object that has a model property containing an instance of a CarModel class. He shows the hash IDs for the objects (different), the model properties (the same) and how changing one changes the other. This could lead to some unintended consequences so he suggests a deep copy instead using a handy library. He finishes the post with example code using this library and the resulting hashes/value differences.

Matt Sparks has an interesting post to his site sharing something he'd like to see in PHP 8 (quite a ways off in the future but still worth thinking about): scalar objects.

Recently, I read an interesting article from Andrew Carter entitled Make PHP Great Again [cheap plug: this link was included in my most recent Newsletter]. In it Andrew brought up the topic of scalar objects. If you’re not familiar with scalar objects, they represent a single value (integer, boolean, string, etc.) that you can perform operations on*.

He shares an example of what it might look like in PHP and his response to a tweet from Nikola Posa about what features they'd like to see. He then spends the remainder of the post making his case for the inclusion of scalar objects and how it can help clean up some of PHP's own naming and functional inconsistencies.

In a new post to his site Matthias Noback makes an interesting suggestion about working with objects in PHP: that they should all be made in one, and only one, place.

Consider the following rule: "When you create an object, it should be complete, consistent and valid in one go."

It is derived from the more general principle that it should not be possible for an object to exist in an inconsistent state. I think this is a very important rule, one that will gradually lead everyone from the swamps of those dreaded "anemic" domain models. However, the question still remains: what does all of this mean?

He shares an example of an object (GeoLocation) that can be created with only the latitude value but points out that this leaves it in an invalid state. He updates this example to show a more complete implementation, one that prevents an object with partial setup from happening. He then talks about the aggregation of child entities and a "paper" metaphor. This metaphor - imagining a "paper purchase order" - helps him wrap his head around the structure of the objects and how they interact.

In a new post Larry Garfield suggests and interesting approach to arrays in PHP: stop using associative arrays (or at least "basically never").

The other day I was working on some sample code to test out an idea that involved an object with an internal nested array. This is a pretty common pattern in PHP: You have some simple one-off internal data structure so you make an informal struct using PHP associative arrays. Maybe you document it in a docblock, or maybe you're a lazy jerk and you don't. (Fight me!) But really, who bothers with defining a class for something that simple?

But that got me wondering, is that common pattern really, you know, good? Are objects actually more expensive or harder to work with than arrays? Or, more to the point, is that true today on PHP 7 given all the optimizations that have happened over the years compared with the bad old days of PHP 4?

So like any good scientist I decided to test it: What I found will shock you!

He starts by describing his test environment (a local environment, not a cloud one) and the code for his baseline tests. The code generates an array of one million items where each item is an associative array of an integer/string combo. He wants to see what kind of memory consumption is involved in the creation and processing of this data set via sorting. His second test evaluated the serialization size (again, code provided) again checking the memory consumption. He shares the results of these tests and then moves on to similar tests on:

• stdClass instances
• objects with public properties
• objects with private properties
• anonymous classes

The post ends with a summary showing the results of all tests side-by-side with some interesting results (but you'll have to check out the post for yourself if you want to see those).

Matthias Noback has a new post on his site with his thoughts about the design of value objects. He makes use of an example he recently saw in the code he was working with: the idea of "quantities" of items.

I recently came across two interesting methods that were part of a bigger class that I had to redesign. [...] What happens [in the methods] is: we have an order line, which keeps track how much of a certain product has been "ordered", and then how much of it has been "delivered" so far. It also keeps track of how much is currently still "open". Changes to these "delivered" and "open" quantities happens when we "process" a delivery, or "undo" a delivery.

I was reminded of a recent blog post by Nicolò Pignatelli where he quoted a question from another programming website. Adopted to the situation at hand: "Which variable type would you use for representing a quantity? Integer, Float or String" It's a trick question, because all the answers are wrong. Nicolò advises not to use a primitive type value, but to design a value object that can represent a quantity.

He then walks through the process for refactoring this quantity handling out into a value object replacing the current float handling. He recommends applying more thought to how the object will be used and how the different types (open, ordered and delivered) relate to each other. He also includes examples of how to replace the add/subtract operations in the original code while still using value objects as immutable constructs.

In this new tutorial on the TopTal.com site author Agustin Villalba takes an in-depth look at how objects and references are handled in memory by the PHP language.

In this article, I will talk about how object and variable references are controlled in memory, since this is an issue that can generate discussion and differing opinions. One question to ponder is: “By default, are objects passed by reference or by copy in PHP?” I’m going to talk first about what references are not in PHP; secondly, I’ll discuss what they are, and finally, I will examine how the garbage collector works in PHP.

He starts with a quick comparison between objects and references (since they're slightly different). He then covers what things are and aren't references in PHP and some examples showing what they are in either case. Code examples and visuals are included showing how things relate. The post wraps up with a look at how garbage collection works with objects/references and a few closing thoughts about how the collector chooses which to clean up.

Alejandro Celaya? has a post to his site sharing some of his experience and advice about how to properly pass data from the outer layers of an app to the "use case" layer. In this situation, the "use case" layer is where most of the processing is happening (versus controllers, views, etc).

Lately, I've been digging a lot in different ways of improving software architecture. Mainly subjects like Clean Architecture, Domain Driven Design, and such.

Those topics cover a lot of advanced and complex practices, but today, I want to talk about a simpler subject. What is the best approach to pass data from outer layers of the application (actions, controllers, async jobs, CLI commands...) to services that are part of the use case layer, by taking advantage of some of the practices promoted by those subjects.

That's a task which is present in any kind of application and is very important to get properly done. You usually need to get data from different origins (a HTTP request, the input of the command line...), filter and validate it, and then use it to perform some kind of task.

He starts off by talking about some of his own previous attempts, starting with a tweet asking where filtering and validation should happen in applications. He then talks about a better approach that makes use of value objects for moving data between service layers. He then walks through a more real-world example (case study) making use of these value objects to handle a user password change.