Freek.dev

On the Bugsnag blog, Graham Campbell, wrote a guest post on the basics of creating a Laravel package. If you've ever wanted to create a package, this is a good starting point.

Laravel is a massively influential PHP framework, and its simple but powerful design means that it’s easy to utilize packages in your application. In this blog post we will look at the basics of creating and installing Laravel packages.

https://blog.bugsnag.com/designing-laravel-packages/

Read more

This a video of a great lecture Bob Martin gave a couple of years ago. Even if you know the solid principles it's great to hear him talk about the origin of Objective C, what makes object orientation (not) special and so much more.

Read more

Matthias Noback explains the value of singleton objects: when used properly they can make your code more developer friendly.

I'm not advocating the use of façades and helper functions per se. I assume they may have good use in specific parts of your application (just as the Laravel documentation states, by the way). My point is that, as long as you build into your libraries both options, you can offer a great developer experience, providing an out-of-the-box working solution of a useful service, which can still be used in a project that uses dependency injection everywhere.

https://php-and-symfony.matthiasnoback.nl/2017/05/the-case-for-singleton-objects-facades-and-helper-functions/

Read more

In a new post on his blog Taylor Otwell gives a nice example on how real time facades can make code more testable.

Recently, I worked on some code that surfaced my most common use-case for Laravel 5.4’s “real-time” facades. If you’re not familiar with this feature, it allows you to use any of your application’s classes as a Laravel “facade” on-demand by prefixingFacades to the namespace when importing the class. This is not a feature that is littered throughout my code, but I find it occasionally provides a clean, testable approach to writing expressive object APIs.

https://medium.com/@taylorotwell/expressive-code-real-time-facades-41c442914291

Read more

Nicola Malizia wrote a short blog post on how Laravel's handy Macroable trait can be used and how it works under the hood.

If you check the Laravel codebase I’m sure that you can observe that Laravel makes use of traits.There is one trait in the source code that pulls my attention. I’m talking about the Macroable trait. ... The purpose of this trait is to extend (not in an OOP sense) a class at run-time. This way, you can add behavior without editing the original class source code.

https://unnikked.ga/understanding-the-laravel-macroable-trait-dab051f09172

Read more

In a new post on his blog Adam Wathan explains his thinking on the meaning of having a method on an object.

The fundamental misunderstanding here is thinking that methods are things an object can do.

If you believe that the methods on an object represent the abilities of that object, then of course an Announcement having a broadcast() method sounds silly.

But what if methods weren't the things an object could do? What if they were the things you could do with that object?

If methods were the actions an object afforded us, then it would make perfect sense to be able to broadcast() an Announcement, wouldn't it?

https://adamwathan.me/2017/01/24/methods-are-affordances-not-abilities/

Read more

PHP does not support method overloading. In case you've never heard of method overloading, it means that the language can pick a method based on which parameters you're using to call it. This is possible in many other programming languages like Java, C++.

So, under normal circumstances, you can't do this in PHP:

class Foo
{
   function bar(A $baz)
   {
      ...
   }

   function bar(B $baz)
   {
      ...
   }
}

However, with some clever coding, Adam Wathan made a trait, aptly called Overloadable, that makes method overloading possible. It works by just accepting any parameters using the splat operator and then determining which of the given functions must be called according to the given parameters.

Let's rewrite that example above using the Overloadable trait.

class Foo
{
    use Overloadable;

    function bar(...$arguments)
    {
        return $this->overload($arguments, [
            function (A $baz) {
               $this->functionThatProcessesObjectA($baz);
            },
            function (B $baz) {
               $this->functionThatProcessesObjectB($baz);
            },
        ]);
    }
}

Pretty cool stuff. In a gist on GitHub Adam shares a couple of examples, the source code of the trait and the tests that go along with it. Check it out!

https://gist.github.com/adamwathan/120f5acb69ba84e3fa911437242796c3

Read more

In an older post on his blog Adam Wathan shared an interesting approach on how to prevent API drift between a test mock and an actual implementation.

One of the risks of writing your own test doubles is that the API of the double can fall out of sync with the API of the real implementation.

In this screencast I walk through an example that explains:

• How interfaces can provide a false sense of security
• Why tests make better contracts than interfaces
• How to run multiple implementations against a shared set of contract tests

If you’ve ever had issues with API drift, try this approach and let me know how it works for you.

https://adamwathan.me/2016/02/01/preventing-api-drift-with-contract-tests/

Read more

Jarek Tkaczyk wrote a blogpost on the usage of accessors in Eloquent. He demonstrates what could go wrong when using accessors on certain fields.

The moral of the story is, that data handling and its presentation should not go into the same bucket. And the model is that bucket – instead of creating accessors, traits or god knows what for this task, better use decorator (like) pattern where you can do all the necessary work for preparing your data to be displayed in your view, without touching actual values anywhere else.

https://softonsofa.com/they-can-bite-how-not-to-use-accessors-in-eloquent/

Keep this in mind when you should use my pragmatic approach for presenters. Watch out for conflicting names.

Read more

At the heart of many modern PHP application there is an IoC Container, short for inversion of control container. When people talk about a "dependency injection container" or a "service container" they mean the same thing. It's purpose is to manage class dependencies. Though the concept is relatively simple, it can come across very confusing if you've never worked with one.

In a new post on his blog Matt Allan builds a simple one from scratch. Check it out if you're struggling with understanding how the IoC container works.

If you are writing modern PHP, you will run across dependency injection a lot. Basically all dependency injection means is that if an object needs something, you pass it in. ... Dependency injection makes your code more flexible and easier to test.

http://mattallan.org/2016/dependency-injection-containers/

EDIT: mattalan.org seems to be down, but you can still view the post in Google's cache.

Read more

Mark Baker tried creating an Anonymous Class Factory.

I was intrigued by a request to find a way of dynamically applying Traits to a class at run-time. With time on my hands as I was sitting in the airport, I considered the problem; and my first thought was to build an Anonymous class, extending the requested class (so that it would still contain all the base properties and functionality, and could be type-hinted, but also applying the requested Trait or set of Traits.

https://markbakeruk.net/2016/05/03/in-search-of-an-anonymous-class-factory/

Read more

This is a technique that I recently found useful. Eloquent models allow you to specify a custom collection object to be returned – which sometimes can be a great place to put some business logic.

Read more

Over at Envato Tuts Alireza Rahmani Khalili wrote a good article on Laravel Facades.

Sweet syntax, which Laravel uses, makes writing code cleaner and easier to understand. Laravel facades are actually the syntactic sugar for service location.

Let’s take a look at Laravel Facade and the way it functions.

Read more

The database model behind WordPress doesn’t follow several good database design rules and conventions. When we’re designing a database for a specific purpose, knowing all its desired functionalities in advance, we can follow all of those rules. But WordPress needs to cover anything that anyone could have in mind, so sacrificing foreign keys and using EAV is something that must be done.

Read more

Tony Messias on the madewithlove-blog:

The other day I was listening to the FullStackRadio episode 34 which is about dealing with dependencies in Active Record models. This is a very interesting topic and they suggest a few solutions for it. I liked the suggestions and I tried to implement it differently (first try and second try).

After that, I decided to talk to my colleagues about the design implementations. And they asked “why not implementing it as a command?”. At first sight I was a bit reluctant, because I’m starting to think applications are getting more complex then it really needs. Then I decided to implement it and the end result was the best one to us. Let’s discuss it a bit.

Read more

Matthias Noback continues his highly interesting series of posts with programming guidelines. Part four is about messages.

Besides having a type and a particular value, messages can also be categorized:

• A command message is a request for change. One object wants to make the other object do something.
• A query message is a request for information. One object wants to get something from the other object.
• A document message is the response from the other object, based on the query that was sent to it.

Read more

Matthias Noback posted the third part of his "programming guidelines series".

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.

Read more

Sandi Metz on her blog:

If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is incorrect. It may have been right to begin with, but that day has passed. Once an abstraction is proved wrong the best strategy is to re-introduce duplication and let it show you what's right. Although it occasionally makes sense to accumulate a few conditionals to gain insight into what's going on, you'll suffer less pain if you abandon the wrong abstraction sooner rather than later.

Read more

Most outlets of technical information (whether high profile developers, companies, etc…) focus on architectural patterns and there’s never any talk about organizational patterns. In other words, does the architectural pattern that you choose fit your organizational pattern?

Read more