In a new post to his site Leonid Mamchenkov talks about complex arrays in PHP and links to two articles offering different opinions on their use.

Now that PHP 7+ sorted out a whole bunch of problems with type-hinting of parameters, return values, variables and properties, we turn our attention to somewhat deeper issues.

Array is a native citizen in PHP. Arrays are very convenient and are widely used. However, if you stop and think about the times where you had to figure out somebody else’s code, I’m pretty sure complex arrays will come to mind at some point.

The first article takes the positive approach, showing you how to create better handling for complex arrays in your applications. The second takes the opposite approach, showing how to avoid complex data structures in your code, opting for classes and objects instead. He notes that he thinks both articles have their good and bad points and references another blog post of his that provides yet another way to solve the need for complex data structures.

Junior Grossi has a tutorial posted to his site for the Laravel (well, Eloquent) users out there showing how to work with querying and eager loading complex relationships to access the data from your database.

Laravel is a PHP framework that uses Eloquent, a powerful and amazing ORM that allows you to do complex SQL queries in a very easy way. But sometimes you need more, and here I’m gonna give you an interesting tip that can bring you a lot of flexibility.

He sets up the situation where, as an application grows its needs for interaction with the data evolves and becomes more complex. Laravel (Eloquent) comes equipped with some tools that can help with this. To illustrate, he outlines a basic "blog" application with Post and Comment types and their relations. While it's simple to get the comments for a post, querying them can get a little more complex. He provides some examples using whereHas/orWhereHas but points out an issue with the results (all comments are returned, not just the ones matching the queried posts).

The solution he proposes is to eager load them instead. His example code still uses the whereHas but adds the comments to a temporary variable which is then filtered via a with on the query.

Robert Basic has written up a new tutorial for the unit testers out there showing how to do some complex argument matching in Mockery, a popular testing tool that offers an alternative to PHPUnit's own mocking functionality.

This past weekend I did some issue maintenance and bug triage on Mockery. One thing I noticed going through all these issues, is that people were surprised when learning about the Mockery::on() argument matcher. I know Mockery’s documentation isn’t the best documentation out there, but this still is a documented feature.

He starts with a simple mock example, mocking out AClass and defining two method criteria (one with a once and another with a never). He points out that things are not always that simple and sometime more complex argument matching is required. The Mockery:on handler allows you to pass in a closure and do more complex evaluation of the values passed in. He includes an example of this, evaluating the result of a set of arguments passed in and ensuring they're all set.

On the Full Stack Radio podcast host Adam Wathan is joined once again by Jonathan Reinink to follow up their previous show and talk more about complex validation.

In this episode, Adam and Jonathan continue their discussion about forms from episode 54, this time focusing on the complexities of validation.

Topics mentioned include form requests in Laravel, a forum post about a possible bypass of CVC and ZIP checks with Stripe and HTML5 form validation. You can listen to this latest show either through the in-page audio player or by downloading the mp3 directly. If you enjoy the episode, be sure to subscribe to their feed and follow them on Twitter for updates on when new shows are released.

In this post to his site Marc Scholten talks about something that's become a side effect of using the inversion of control design pattern in PHP applications (specifically related to dependency injection): added accidental complexity.

Modern PHP development favors the use of inversion of control to keep software more configurable and flexible. This leads to the problem that one now has to create a big graph of objects to use the application. As a solution to avoid redundant setup code, service containers like the symfony2 dependency injection component are used.

The goal of a service container is to centralize the construction of big object graphs. [...] Simple, right? Actually it’s not. Commonly used service containers are complex solution for simple problems.

He illustrates with an example using the Symfony services container, a piece of the framework that allows the definition of dependency relationships via a YAML formatted file. While this configuration seems simple enough, he points out that more complex dependencies (ones that could easier be set via a "set" method) become more difficult to define when limited by the service container config structure. He also points out that it makes static analysis of the code much more difficult with dependencies being dynamically fetched from the container instead of directly related. He offers an alternative to this complex container setup, however: a simple method (or methods) inside of a factory class that creates the objects, injects the required dependencies. This makes it much easier to call from the service container instance and configuration and even a "create container" call to set all of the dependencies up at once. He ends the post with some advantages of this approach and a takeaway or two to keep in mind when managing your object dependencies.

Matt Stauffer has kicked off a new series on his blog about some of the new features in Laravel 5.2 and how to use them effectively. In this first part of the series he looks at form array validation and using it on more complex form submissions.

Form array validation simplifies the process of validating the somewhat abnormal shape of data HTML forms pass in when the array syntax is used. If you're not familiar with it, a common use case is when you allow a user to add multiple instances of the same type on one form.

[...] But how do we validate this? Prior to 5.2, it's a bunch of manual work. Now, Laravel understands this nesting structure and can validate against it uniquely.

He compares the new validation handling with a standard validator (for a single text string) and shows how a "dot" (period) notation can be used to define the more complex rules. You can even use asterisks for wildcard making at any level. Definitely a nice addition to the validation handling in the framework.

On the SitePoint PHP blog, there's a new tutorial that introduces you to the Meedoo library, a tool to make working with databases even easier. In this tutorial Wern Ancheta walks you through some of the basics of the tool and shows you how to use it with a Pokemon-based example.

In this article I’m going to walk you through Medoo, a lightweight database abstraction library for PHP. Its main features include: support for multiple databases, being secure and easy to use. [...] While Medoo is nothing revolutionary, and the fact that it sports a very small filesize matters little to few, it’s still an interesting project that went from being outright dismissed to vaguely accepted, as evident in these threads. It’s on its way up, and that’s our reason for taking a look at it.

Once installed (he recommends using Composer) you can follow along with his examples showing how to connect to the database, make a simple select and define something a bit more complex (like multiple other requirements in the SQL statement's "where"). He shows how to execute manual queries and handling more complex operations like joins. He then gets into the other parts of the usual CRUD handling - inserting new data, updating data and deleting data.He finishes the post by mentioning aggregate functions and some of the debugging options the tool includes.

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.

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.

The NetTuts.com site has posted the third part of their series sharing some tips for refactoring the code in a legacy application. In part one they looked at the "Golden Master" and in part two about moving away from magic strings and constants.

Old code. Ugly code. Complicated code. Spaghetti code. Gibberish nonsense. In two words, Legacy Code. This is a series that will help you work and deal with it. I like to think about code just as I think about prose. Long, nested, composed sentences with exotic words are hard to understand. From time to time you need one, but most of the time, you can just use plain simple words in short sentences. This is very true for source code also.

Continuing on with this "prose" theme, he gives an example of simplification and reducing the amount of validation needed before completing the task. He compares this to complex conditionals and shares something called the "extract method" to help simplify them. He also looks at directory and file structure and suggests cleanup there as well. The tutorial finishes with a few other suggestions, things like cleaning up "runner functions" reworking negative conditionals.