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

Paul Jones:
A Factory Should Create, Not Retain
Jul 08, 2015 @ 08:45:31

Paul Jones has posted his thoughts about factory behavior in PHP applications (well, really any kind of application as it's a pan-language concept). He suggests that factories should only create the objects requested and not persist them.

In a recent Reddit conversation, some of us went off on a tangent about factories. I maintained then, and do now, that a “factory” always-and-only returns a new instance. If you have a “factory” that returns anything other than a new instance, it’s not a factory alone. In the case of factory methods, it is a factory + accessor; in the case of factory objects, it is a factory + registry. A “factory” (whether a factory method or factory object) is one way to separate object creation from object use.

He gives an example of a case where an object needs to be created for a "doSomething" method. His first example shows the creation of the "Item" inline, mixing the creation and use of the object into the same place. He replaces this with a "factory" class/method that only returns the new "Item" requested. He points out that a factory method that retains the object (like as a class property) has the same problem as the first example - retention. Instead he suggests an intermediate "collaborator" that splits out the creation and retention once again.

tagged: factory retain create object method collaborator example

Link: http://paul-m-jones.com/archives/6161

Evert Pot:
PHP's callable typehint too loose?
May 07, 2015 @ 10:19:56

In his latest post Evert Pot wonders if the current implementation of the "Callable" type in PHP is too loose when it comes to what it will accept as a valid callable resource.

PHP got support for closures in version 5.3, and in PHP 5.4 we got support for a callable typehint. [...] All these little changes make it feel more comfortable to apply functional programming concepts to PHP, but occasionally we need to drop back to using less aesthetically pleasing code.

In his examples of "less aesthetically pleasing code" he shows a few different methods that work that aren't the typical closure or object arguments (like passing in an array of object+method name). He also shows an interesting option where you can use a string with a static method call (ex: "MyClass::method") and it will still be accepted. He points out that for this to work correctly in all situations, the call_user_func method should be used, not just calling the input directly.

tagged: callable typehint loose object method array variable iscallable calluserfunc

Link: http://evertpot.com/on-callables-and-closures/

Marc Morera:
Behat and Data-test
Apr 27, 2015 @ 09:55:08

In a new post Marc Morera makes a suggestion for a testing practice to add to the use of the popular BDD PHP testing framework Behat - a "data-test" option to help with decoupling the tests from implementation.

Tests should be as robust as possible. I think you will agree with me with that phrase. If your tests are too coupled with your implementation, a simple modification of your code will need the modification of your tests, and that’s so annoying, right? [...] My question is… should the frontend of your website be aware of the how your Behat tests are built? In my opinion, nope. Your tests should live in a simple layout on top of your application, emulating some cases and ensuring that your users will be able to do what they should be able to.

He points out the main problem with the current testing methods, mainly that the real issue is in the hard-wiring of the test functionality to the name/id/type of the interface elements. He also brings up the aspect of translations and ensuring that your tests take into account that the text may not always be in English. He also mentions Symfony forms and how they define their own structure and naming, not necessarily what you manually generate. He instead proposes a "data-test" property that could be added to elements both indicating that they're used by the testing process and can help in locating the elements during the testing process.

tagged: behat bdd datatest property markup testing method opinion

Link: http://mmoreram.com/blog/2015/04/25/behat-and-data-test/

Snack Overflow:
Unit testing static calls without refactoring the world in php
Feb 27, 2015 @ 11:55:06

The "Snack Overflow" blog (from tech.graze.com) has a recent post sharing some suggestions to help unit test static calls without having to "refactor the world" away from them.

Imagine you have a situation [using a static method call] in some legacy code. Currently we can't unit test this as we can't mock out the doSomethingElse() call. So what do we do? Well we have two options really [...] neither of which is very appealing. [...] There is, however, a third option that gains us the ability to unit test Foo without having to touch Bar at all.

This option involves creating a "proxy" object of the "Bar" class that's non-static and only returns the result of the previous class' static method. You can then correctly mock that class and return the result in a more self-contained way. He lists a few caveats with this method including the fact that it could lead to a lot of proxy objects if there are a lot of static methods to replicate.

tagged: unittest static method refactor proxy object mock tutorial

Link: http://tech.graze.com/2015/02/26/unit-testing-static-calls-without-refactoring-the-world-in-php/

Create a Custom Payment Method in OpenCart: Part 3
Jan 21, 2015 @ 10:20:44

NetTuts.com has continued their series showing how to integrate a custom payment method into your OpenCart instance with part three of the series. In this tutorial they focus more on the frontend aspects, creating controller and model handling for the new method.

If you've been following along with this series, you should be familiar with the kind of file structure we set up for our custom payment method in the back-end. [...] We'll use a similar kind of file setup for the front-end section as well.

He starts with the controller, building a handler for the Custom method, doing some data filtering and getting the order information. He walks you through what each of the lines are doing and shows how to output the result back to a view. He also includes the model code needed for the custom payment method as well as language/template files to display the form needed to gather the necessary data.

tagged: opencart part3 series custom payment method tutorial

Link: http://code.tutsplus.com/tutorials/create-a-custom-payment-method-in-opencart-part-3--cms-22464

Joe Watkins:
Mocking PHP
Jan 19, 2015 @ 12:23:39

In his latest post Joe Watkins talks about mocking PHP. No, not making fun of the language but rather mocking internal PHP functions and methods as a part of unit testing your application.

I work on a vast PHP code base, it is 3M LOC of PHP alone. It's somewhere between legacy and modern, work is ongoing. [...] When I joined the current project there were many many tests, they relied upon the kind of unholy magic that runkit allows you to perform, for the most part this worked okay for a while. However, runkit inexplicably caused many of the tests to fault, either at shutdown, or at random.

[...] So we were in a bit of a jam, I've always found runkit to be quite awkward, and now I'm staring its source code in the face knowing it represents a road block to my goal of running the latest stable versions of PHP, with the first decent optimizer that ever existed for Zend. I tackled the problem with code, code which I was allowed by my gracious employer to open source (the uopz extension).

He goes on to talk about what the actual root problem he was trying to solve was (dodging code with built-in functions), the "obvious" way to solve it using runkit or the more modern solution that uses the uopz extension. He provides an example of it in use mocking the fopen function with a "uopz_function" wrapper.

tagged: mock internal method function extension uopz unittest

Link: http://blog.krakjoe.ninja/2015/01/mocking-php.html

Refactoring Legacy Code - Part 10: Dissecting Long Methods with Extractions
Sep 19, 2014 @ 09:41:54

NetTuts.com is back with the latest part of their "Refactoring Legacy Code" series for PHP. In this latest article (part 10) they work on pulling apart longer methods into smaller, more manageable chunks.

In the sixth part of our series we talked about attacking long methods by leveraging on pair programming and viewing code from different levels. We continuously zoomed in and out, and observed both small things like naming as well as form and indentation. Today, we will take another approach: We will assume we are alone, no colleague or pair to help us. We will use a technique called "Extract till you drop" that breaks code in very small pieces. We will make all the efforts we can to make these pieces as easy to understand as possible so the future us, or any other programmer will be able to easily understand them.

This "extract 'till you drop" mentality (from Robert Martin) has you look at a piece of code and find the logic and lines that can be split out and isolated without removing functionality and interaction. They include some random code from a Stack Overflow post (checking if a number is a prime) and show how to split it out, making the logic and structure less complex and more understandable. They start with a unit test to ensure the result is the same post-refactor and fixing a few bugs along the way. They split it out into two different methods and move it from a more linear approach to something recursive.

tagged: tutorial refactor legacy code part10 series extract method

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-10-dissecting-long-methods-with-extractions--cms-22182

SitePoint PHP Blog:
Asset Access Restriction Methods – Block Unwanted Visitors
Sep 05, 2014 @ 10:11:45

In a new tutorial from the SitePoint PHP blog today Jeroen Meeus looks at a way to protect parts of your application from being used and abused. He shows you how to protect various parts of you site, including images and actual pages, with the help of either your web server or bits of code.

When building an awesome web app or website, we sometimes want people to be able to embed parts of our web app/website into their own. That could be an iframe holding a ‘like’ button, a simple image that they want to reuse or even our entire app embedded in an iframe. But how do we control who has access, who is allowed to use up our bandwidth and query our service? We define the problem as controlling access to assets. By assets we mean: anything that can be queried from our site.

He talks about the problem of "lifting" content and how to fall back to a "deny all, allow some" mentality. He starts with examples of Apache configurations that use mod_rewrite to only allow requests that come from the current domain (trusted) and the "files" directive coupled with Deny/Allow. He also includes an nginx example, showing the same request handling. The code examples show how to use PHP and Javascript to prevent access the same way.

tagged: asset protection method webserver configuration code tutorial

Link: http://www.sitepoint.com/asset-access-restriction-methods-block-unwanted-visitors/

Refactoring Legacy Code: Part 6 - Attacking Complex Methods
Jun 27, 2014 @ 13:17:37

The NetTuts.com site has posted the sixth part in their "Refactoring Legacy Code" series, this time with a focus on the more complex methods. They look at simplifying their contents and testing their various parts (better code coverage). The post is based completely on the contents of the previous five in the series, so if you haven't read up on those do that before starting.

In our previous five lessons we invested quite a lot of time in understanding our legacy system, in writing tests for whatever testable piece of code we could find. We reached a point to where we have quite a few tested methods but we still avoided the complex, hard to understand logic. It's now time for some serious coding.

The start with one of the more complex methods (roll) and work through it line-by-line to figure out what it's being given, how it's handling the data and what kinds of things it might return or modify inside. The break it down into to "parts" and figure out the right tests to write for each. With the method fully tested, they then start in on the refactor, teasing out various parts of the method into other methods and property changes. There's also a section at the end talking about pair programming and how it relates to good testing practices.

tagged: refactor series tutorial part6 complex method unittest phpunit

Link: http://code.tutsplus.com/tutorials/refactoring-legacy-code-part-6-attacking-complex-methods--cms-21522

Mathias Verraes:
Named Constructors in PHP
Jun 13, 2014 @ 09:42:15

Mathias Verras has a new post to his site about an idea he calls "named constructors". This method uses static factory methods to simulate the idea of a constructor and initialize the object.

PHP allows only a single constructor per class. That’s rather annoying. We’ll probably never have proper constructor overloading in PHP, but we can at least enjoy some of the benefits. Let’s take a simple Time value object. Which is the best way of instantiating it? The only correct answer is “it depends”.

His example shows the typical constructor creation with variable arguments, but points out that this can get messy quickly. His other method, the factory methods as "constructors", can make for a cleaner interface and makes the class more flexible. They make the object able to be initialized with different types of values and even satisfies the Single Responsibility Principle. He goes through a few examples using his "Time" class, showing how different "constructor" methods can be used to handle inputs ranging from a normal hour/minute format out to a "from minutes since midnight" value.

tagged: named constructor factory method static tutorial time

Link: http://verraes.net/2014/06/named-constructors-in-php/