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

Matthias Noback:
Final classes by default, why?
Sep 12, 2018 @ 12:08:54

In this post to his site Matthias Noback makes the argument that, during your normal development, classes should be final by default and only changed if there's a need to extend them.

I recently wrote about when to add an interface to a class. After explaining good reasons for adding an interface, I claim that if none of those reasons apply in your situation, you should just use a class and declare it "final".

[...] For a couple of years now I've been using the final keyword everywhere (thanks to Marco Pivetta for <a href="https://ocramius.github.io/blog/when-to-declare-classes-final/>getting me on track!). When I see a class that's not final, it feels to me like it's a very vulnerable class. Its internals are out in the open; people can do with it what they want, not only what its creator has imagined.

Still, I also remember my initial resistance to adding final to every class definition, and I often have to defend myself during workshops, so I thought it would help if I explained all about it here.

He starts off by talking about the alternative - non-final classes - and some of the issues that can come with it (and class extension). He makes the suggestion that "replacing is better than overriding" and creates less complexity overall. He also answers a question about the use of the "Template Method" design pattern that would allow for improvement from base "skeleton" logic designed to be extended. He covers "composition over inheritance", the use case of extension and how "final" is a better direction.

tagged: final class exposure extension opinion override template composition

Link: https://matthiasnoback.nl/2018/09/final-classes-by-default-why/

Matthias Noback:
When to add an interface to a class
Aug 28, 2018 @ 09:12:04

Matthias Noback has a tutorial posted to his site sharing his thoughts on when adding an interface to a class is useful. Here he's talking about using interfaces as a structure for your application, making it easier to understand and more structured.

I'm currently revising my book "Principles of Package Design". It covers lots of design principles, like the SOLID principles and the lesser known Package (or Component) Design Principles. When discussing these principles in the book, I regularly encourage the reader to add more interfaces to their classes, to make the overall design of the package or application more flexible. However, not every class needs an interface, and not every interface makes sense. I thought it would be useful to enumerate some good reasons for adding an interface to a class. At the end of this post I'll make sure to mention a few good reasons for not adding an interface too.

He then offers five suggestions of cases where an interface makes sense:

  • If not all public methods are meant to be used by regular clients
  • If the class uses I/O
  • If the class depends on third-party code
  • If you want to introduce an abstraction for multiple specific things
  • If you foresee that the user wants to replace part of the object hierarchy

For each item in the list he provides a summary of the suggestion and some code snippets to back it up. He ends the post with a recommendation about how to handle most other situations where you think an interface might be useful: use a "final" class instead.

tagged: interface class opinion structure top5 class tutorial

Link: https://matthiasnoback.nl/2018/08/when-to-add-an-interface-to-a-class/

Matthias Noback:
When to add an interface to a class
Aug 28, 2018 @ 09:12:04

Matthias Noback has a tutorial posted to his site sharing his thoughts on when adding an interface to a class is useful. Here he's talking about using interfaces as a structure for your application, making it easier to understand and more structured.

I'm currently revising my book "Principles of Package Design". It covers lots of design principles, like the SOLID principles and the lesser known Package (or Component) Design Principles. When discussing these principles in the book, I regularly encourage the reader to add more interfaces to their classes, to make the overall design of the package or application more flexible. However, not every class needs an interface, and not every interface makes sense. I thought it would be useful to enumerate some good reasons for adding an interface to a class. At the end of this post I'll make sure to mention a few good reasons for not adding an interface too.

He then offers five suggestions of cases where an interface makes sense:

  • If not all public methods are meant to be used by regular clients
  • If the class uses I/O
  • If the class depends on third-party code
  • If you want to introduce an abstraction for multiple specific things
  • If you foresee that the user wants to replace part of the object hierarchy

For each item in the list he provides a summary of the suggestion and some code snippets to back it up. He ends the post with a recommendation about how to handle most other situations where you think an interface might be useful: use a "final" class instead.

tagged: interface class opinion structure top5 class tutorial

Link: https://matthiasnoback.nl/2018/08/when-to-add-an-interface-to-a-class/

Larry Garfield:
PHP: Never type hint on arrays
Jul 30, 2018 @ 12:05:48

In a new post Larry Garfield makes an interesting suggestion related to the use of arrays in PHP. He suggests that you should never type hint arrays in your method definitions.

Let's be controversial: In modern PHP, you should never type-hint an array. Before you start throwing tomatoes, hear me out.

PHP allows you to specify the type of a function/method parameter or return value. These return values can be any legal PHP type. [...] PHP has a data type that it calls array, although it's not really an array as any other language would define it. [...] And you should almost never use array as a type hint. Why? Because there's always a better, more generic option.

He starts off talking about the use case where arrays are used as a "single complex value" and how,. more often than not, a class is actually a better option. He then covers the other main use of arrays: as an ordered sequence of values. To replace this he recommends a more structured collection that can apply some logic to its contents. With these other options out of the way, he then talks about what arrays are actually useful for and some other potential typehints to allow arrays and other potential inputs. He ends the post talking about array operations included in PHP and how, with a minimal amount of effort, they could be reproduced with simple methods for use on actual collection instances instead.

tagged: typehint array options class collection opinion

Link: https://steemit.com/php/@crell/php-never-type-hint-on-arrays

Matt Sparks:
PHP Reflection
Jul 02, 2018 @ 12:42:41

Matt Sparks has posted a tutorial to his site introducing one of the more powerful but often misunderstood parts of the PHP language: its Reflection functionality.

Beginning work on the Analyze PHP framework, specifically the container, brought reflection to my awareness. Before that I had maybe heard the term, but I definitely hadn’t used it intentionally. Although it sounds like a scary computer science concept, it’s not. It’s actually quite simple:

Reflection is the ability of a computer program to examine, introspect, and modify its own structure… That’s it.

He starts the tutorial by introducing some of the basics concepts behind reflection in PHP and what it has to offer. He then shares some code examples of it in action getting class properties and getting the constructor. He also shows the use of other built-in PHP functions getting the class methods and the class name.

tagged: reflection tutorial introduction class method name properties constructor

Link: https://developmentmatt.com/php-reflection/

Larry Garfield:
PHP: Use associative arrays basically never
Jul 02, 2018 @ 10:50:59

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

tagged: associative array never benchmark object class anonymous results statistics

Link: https://steemit.com/php/@crell/php-use-associative-arrays-basically-never

Mark Baker:
Using PHP Anonymous Classes as Package Private Classes
Jun 26, 2018 @ 15:09:36

Mark Baker has a post to his site about some of the interesting things you can do with anonymous classes, focusing on their use outside of testing (as he has in previous articles).

I’ve written before about the benefits of using PHP’s Anonymous Classes for test doubles; but Anonymous Classes also have potential usecases within production code as well. In this article I’m going to describe one such usecase that can be particularly useful within libraries, and that is replicating the access of Package Private (in Java), or Protected Internal Classes (as per C#).

He briefly explains what the package private/protected internal classes functionality entails before getting into his own use of the method with the PHPExcel/PHPSpreadsheet packages. He defines how he thinks the system should be structured and the isolation the anonymous classes would provide (without having to make whole separate classes just for that). He creates a class that has all public methods accessible but cannot be instantiated from outside the library. He shares some example code to illustrate his point, walking through each step to show what it's doing and how.

tagged: anonymous class package private class tutorial phpexcel

Link: https://markbakeruk.net/2018/06/25/using-php-anonymous-classes-as-package-private-classes/

Mark Baker:
Using PHP Anonymous Classes as Package Private Classes
Jun 26, 2018 @ 15:09:36

Mark Baker has a post to his site about some of the interesting things you can do with anonymous classes, focusing on their use outside of testing (as he has in previous articles).

I’ve written before about the benefits of using PHP’s Anonymous Classes for test doubles; but Anonymous Classes also have potential usecases within production code as well. In this article I’m going to describe one such usecase that can be particularly useful within libraries, and that is replicating the access of Package Private (in Java), or Protected Internal Classes (as per C#).

He briefly explains what the package private/protected internal classes functionality entails before getting into his own use of the method with the PHPExcel/PHPSpreadsheet packages. He defines how he thinks the system should be structured and the isolation the anonymous classes would provide (without having to make whole separate classes just for that). He creates a class that has all public methods accessible but cannot be instantiated from outside the library. He shares some example code to illustrate his point, walking through each step to show what it's doing and how.

tagged: anonymous class package private class tutorial phpexcel

Link: https://markbakeruk.net/2018/06/25/using-php-anonymous-classes-as-package-private-classes/

Tomas Votruba:
How to Turn Mocks from Nightmare to Solid Kiss Tests
Jun 13, 2018 @ 12:36:48

In a new post to his site Tomas Votruba shows you how to make your unit test mocks better with an easier and clearer way to use them. This simplification makes use of something PHP itself is already able to do: create anonymous classes.

At the time being, there is only 1 post about anonymous classes in tests (thanks to Matthieu!). Compared to that, there are many PHP tool made just for mocking: Prophecy, Mockery, PHPUnit native mocks, Mockista and so on. If you're a developer who uses one of them, knows that he needs to add proper annotations to make autocomplete work, has the PHPStom plugin that fixes bugs in this autocomplete and it works well for you, just stop reading.

This post is for developers who struggle with mocking and have a feeling, that they're doing something wrong.

He starts with an example of a test that creates a mock for an external request to the Heroku service using PHPUnit's mocking tools. He points out that this requires extra knowledge of the mocking methods and functionality to accomplish, potentially making it difficult to understand for those new to the tool. He then shares a refactor of the same test, this time making use of an anonymous class to mock out the needed findByCategoryId method and return a response. He ends the post pointing out that, as a side effect of this refactoring (and other interface refactoring) you'll create more SOLID code and it can help make it easier to maintain in the future.

tagged: tutorial mock unittest test anonymous class tool

Link: https://www.tomasvotruba.cz/blog/2018/06/11/how-to-turn-mocks-from-nightmare-to-solid-kiss-tests/

Matthias Noback:
Combing legacy code string by string
Apr 18, 2018 @ 09:15:59

In a new post to his site Matthias Noback takes a look at legacy applications and two things that most of them seem to have in common: classes that are too large and too generic methods. In this post he discusses these two topics and some of the tactics you can use to help refactor and resolve them.

I find it very curious that legacy (PHP) code often has the following characteristics:
  • Classes with the name of a central domain concept have grown too large.
  • Methods in these classes have become very generic.

He starts by tackling the "classes too large" problem, suggesting that it's usually just a matter of developers slowly adding to existing functionality rather than introducing large chunks of code all at once. Moving on to the "generic methods" issue, he lays out a common scenario showing how a method evolves over time to repurpose it for other uses thank its original intent. He recommends "taking a step back" and picking apart the code to make the functionality more specific in the places it's used.

tagged: legacy application generic method large class tutorial

Link: https://matthiasnoback.nl/2018/04/combing-legacy-code-string-by-string/