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

Stoimen Popov:
PHP: Don’t Call the Destructor Explicitly
Jun 27, 2016 @ 12:52:39

In a new post to his site Stoimen Popov makes the recommendation to not call the destructor explicitly in your code and provides some alternatives.

PHP 5 introduces a destructor concept similar to that of other object-oriented languages, such as C++” says the documentation for destructors. [...] Well, as you can not call the constructor explicitly [...] so we should not call the destructor explicitly. The problem is that I’ve seen this many times, but it’s a pity that this won’t destroy the object and it is still a valid PHP code.

He talks about __destruct and it's role in PHP's set of "magic methods" and what they exist to do. He then gets into a few examples of what code could look like that uses a destructor and the difference between normal handling calling the destructor explicitly. The main differences is that calling it explicitly does not destroy the object, it's basically like calling any other method. He does include an interesting method for destroying the object - setting it to null - and notes that the destructor fires then too. He also points out a few interesting things about cloning objects and how object references work when setting nulls as in the previous example.

tagged: destructor explicit call object destroy null tutorial

Link: http://www.stoimen.com/blog/2011/11/14/php-dont-call-the-destructor-explicitly/

Andrew Carter:
PSR-7 Objects Are Not Immutable
May 24, 2016 @ 10:28:05

Andrew Carter has written up a new post about PSR-7 objects (the PHP-FIG defined standard for handling requests and responses in PHP applications) and how the objects themselves are immutable.

What’s happening [in the provided example] is that the Zend Expressive framework is rendering the error page to the same object that you wrote your message to. Whilst the actual message object itself is immutable, the body stream that it references is not. Even when this object is cloned or “modified” (to become a new object) it will still use the same stream.

He explains a bit about what this means in a more practical sense and why the PSR-7 standard and why this happens (as defined after much discussion). Then he gets into a more recent debate happening in the PHP-FIG about PSR-7 middleware and the proposal for a standard structure in its creation. He points to some of the thoughts from Anthony Ferrara on the topic and an example from Woody Gilk showing an exception handler and how having the stream always appending content is a bad thing in that particular case.

tagged: psr7 object immutability output zendexpressive middleware stream

Link: http://andrewcarteruk.github.io/programming/2016/05/22/psr-7-is-not-immutable.html

Mark Ragazzo:
Immutable objects
May 04, 2016 @ 13:55:42

In a post to his site Mark Ragazzo looks at immutable objects - what they are and how they can be used in a PHP application with some "final" functionality.

In this short article we will see what immutable objects are and why we should consider to use them. Immutable object is an object that does not change its state after it was created. Immutable objects usually are very simple. You may already seen them as enum types or primitives like DateTimeImmutable.

Further in this article you will learn that making simple objects immutable may save significant amount of your time by making impossible to make certain types of mistakes.

He starts with a list of a few things to remember when implementing immutable objects (like using the "final" keyword) and problems that can come without them. He then gets into some examples, showing how to create immutable Address and Money objects and how to use them when you need to update/get values from the object. He also covers some common "accidental mutability" cases like leaking internal object references and inheritance problems.

tagged: immutable object introduction example mutability accidental tutorial

Link: https://ragazzo.github.io/immutability/oop/2016/05/03/immutability.html

Ibuildings Blog:
Programming Guidelines - Part 4: Messages
Feb 17, 2016 @ 11:19:17

Ibuildings has posted the fourth part of their "Programming Guidelines" series to their blog, sharing even more helpful hints and tips you can apply to your everyday development. In this new post author Matthias Noback talks about messaging in your application, not in output to the user but in the communication between parts of your system.

In the previous parts of this series we looked at how to get rid of complexity at the level of algorithms. After discussing the problem of nulls in your code, we looked at object lifecycles and how to encapsulate them properly. Now that we have objects that can be constructed and changed only in valid ways, we need to look at how they communicate with each other and how we can improve our code with regard to that aspect.

He then breaks up the rest of the article into a few sections:

  • Object communication
  • Message categories
  • Command/Query Separation Principle
  • Implementing commands
  • Queries
  • Documents
  • Command query responsibility segregation
  • Events

For each section a description of the topic is provided and a bit of sample code is included to help illustrate the change/functionality.

tagged: programming guideline part4 series message object tutorial

Link: https://www.ibuildings.nl/blog/2016/02/programming-guidelines-part-4-messages

Ibuildings Blog:
Programming Guidelines - Part 3: The Life and Death of Objects
Feb 02, 2016 @ 11:42:05

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".

tagged: oop object detail introduction validate immutable valueobject revive lifecycle tutorial

Link: https://www.ibuildings.nl/blog/2016/02/programming-guidelines-part-3-the-life-and-death-objects

How to Validate Data
Nov 10, 2015 @ 10:18:52

In this post to thePHP.cc site Sebastian Bergmann looks at validation data, both in the sense of user input and the contents of objects you're application is currently working with.

Validating data seems to be one of the most important tasks of an application. After all, you cannot trust data from external sources. So let us have a look at how to efficiently implement data validation.

He gives an example of a user profile with requirements on the data it should contain. He focuses on the email address property as it's one of the easier options to validate (or is it). He walks through the usual progression from controller injection to setter injection of the value but wonders when the validation should happen to keep the Profile object from becoming invalid. He points out that simply having a validate method perform the checks isn't enough as it may not always be called correctly, leading to potentially invalid objects. Instead he recommends an alternative - using a validator object/tool in the setters of your object instance as the values are set. This prevents the object from getting into an unknown state and provides immediate feedback to the developer when something's wrong.

tagged: data validation object recommendation setter business rules

Link: https://thephp.cc/news/2015/11/how-to-validate-data

Full Stack Radio:
28: Jeffrey Way and Dave Marshall - "Don't mock what you don't own"
Oct 29, 2015 @ 09:32:52

The Full Stack Radio podcast, hosted by Adam Wathan, has posted their latest episode featuring guests Dave Marshall and Jeffrey Way. In this latest show they suggest you "don't mock what you don't own".

n this episode, Adam talks to recurring guests Jeffrey Way and Dave Marshall about "don't mock what you don't own". They talk about how to design code that needs to work with external services, how you should test that code, and the pitfalls you run into when you use mocks incorrectly in your test suite.

Topics mentioned include this paper suggesting you mock roles not objects and an opinion piece on why integration tests are a scam. You can listen to this latest episode either through the in-page audio player or by downloading the mp3. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for information about when the latest shows are released.

tagged: fullstackradio podcast jeffreyway davemarshall mock object testing

Link: http://www.fullstackradio.com/28

SitePoint PHP Blog:
Flyweight Design Pattern and Immutability: A Perfect Match
Oct 22, 2015 @ 11:56:32

The SitePoint PHP blog has a tutorial they've posted (from author Andrew Carter) looking at the Flyweight design pattern and immutability, how they're a "perfect match". The flyweight pattern makes it possible to reuse objects after they've been created with one requirement: they must be immutable.

The fundamental principle behind the flyweight pattern is that memory can be saved by remembering objects after they have been created. Then, if the same objects need to be used again, resources do not have to be wasted recreating them. [...] You can think of the flyweight pattern as a modification to a conventional object factory.

One important feature of flyweight objects is that they are immutable. This means that they cannot be changed once they have been constructed. This is because our factory can only guarantee that it has remembered the correct object if it can also guarantee that the object it originally created has not been modified.

The post includes code examples of how to implement the pattern with a simple File object that fetches data from a file when created. He then creates the factory class, with a getFile method that takes in the path and creates the immutable File object from it. It's then stored in an internal array for potential reuse later. He also talks about how the pattern could be useful for handling enumeration objects and how you can use it to build out "type" objects.

tagged: flyweight designpattern immutable object factory tutorial type enumeration

Link: http://www.sitepoint.com/flyweight-design-pattern-immutability-perfect-match/

Lorna Mitchell:
PHP: Calling Methods on Non-Objects
Oct 19, 2015 @ 10:53:57

In a quick post to her site Lorna Mitchell describes a small difference in error messaging that's changed between PHP versions when trying to call methods on non-objects between versions 5.5, 5.6 and the upcoming PHP 7.

PHP has subtly changed the wording of this error between various versions of the language, which can trip up your log aggregators when you upgrade so I thought I'd give a quick rundown of the changes around the "call to member function on non-object" error in PHP, up to and including PHP 7 which has an entirely new error handling approach.

She includes examples of the error messages for PHP 5.5 and 5.6, differing only in how they report back the type of the variable the method was called on (one gets more specific). In PHP 7, however, the message is different because of the major overhaul that error handling has gotten. The new Error inheritance model still has it throw a fatal but it also notes it's an uncaught error which can be caught with the same try/catch as any other exception.

tagged: object error message version php5 php7 example output uncaught

Link: http://www.lornajane.net/posts/2015/php-calling-methods-on-non-objects

Bernhard Schussek:
Value Objects in Symfony Forms
Sep 10, 2015 @ 11:35:20

Bernhard Schussek has posted a tutorial on his Webmozart.io site talking about the use of value objects in Symfony forms. By nature value objects don't allow the use of "setters" to assign/change values but he shows how to use a custom data mapper to work around the problem.

Many times, Symfony developers wonder how to make a form work with value objects. For example, think of a Money object with two fields $amount and $currency. [...] Can you write a form type for this class without adding the methods setAmount() and setCurrency()? In this post, I will show you how.

He starts with a bit of an overview on what value objects are and how the concept of immutability comes into play. He shows examples of potential issues if setters are allowed to change data and what should be done when a value change is actually needed. He then gets into the heart of the matter, integrating the forms handling with simple value objects. He goes through building a simple form and the use of the empty_data option to create a new value object with the form values. This works fine but breaks down if you need to update an object. Instead he creates a custom data mapper that sets up two methods, mapDataToForms and mapFormsToData, that allow for both interactions to work correctly.

tagged: value object symfony form tutorial custom data mapper emptydata

Link: https://webmozart.io/blog/2015/09/09/value-objects-in-symfony-forms/