News Feed

News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way
Clean Architecture
December 23, 2014 @ 10:37:28

In an article on Tristan Roussel introduces you to some of the concepts behind Clean Architecture based on a talk he recently attended at a local Symfony user group.

One particular talk retained my attention and I want to tell you about it. Let me warn you first, this is just an introduction, and I'm not going into much detail, don't hesitate to post comments if you feel something is not clear, or deserves a better exposure! [...] So. What is Clean Architecture? It's so fresh that it doesn't even have a Wikipedia article.

He starts off with what the idea of Clean Architecture is trying to accomplish and where some of the ideas have evolved from. He includes some of the objectives and guiding principles as well as a diagram of how this architecture might be laid out. He gets into an actual use case for this type of structure and where abstract entities, controllers and presenters fit into the picture. He links to some of the code as provided as part of the presentation and some of the things to consider when trying it out for your application.

0 comments voice your opinion now!
clean architecture introduction presentation principles objectives usecase


Matthias Noback:
Packages the case for clones
November 17, 2014 @ 11:55:21

In a new post to his site Mattias Noback makes a case for clones (in response to this post from Phil Sturgeon). In it he defends the creation of "clones" of tools, either slightly different version of pre-existing PHP packages or the functionality from a package in another language.

There is this ongoing discussion in the PHP community (and I guess in every software-related community) about reinventing wheels. A refreshing angle in this debate came from an article by Phil Sturgeon pointing to the high number of "duplicate" packages available on Packagist. I agree with Phil. [...] It doesn't make sense to do the same thing over and over again. At least I personally don't try to make this mistake. If I want to write code that "already exists", at least I don't publish it on Packagist. However, recently I got myself into the business of "recreating stuff" myself.

He talks some about one of his own projects (SumpleBus) and how, despite it possibly being a clone of other packages, it has slightly different goals than other tools, making it a different tool, not just a straight up clone. He also covers some of the package design principles he suggests in his book and how they can help to make an isolated package better. He also points out how recent PHP-FIG efforts to define common interfaces and structures can help reduce this kind of package duplication as well by reducing the possible implementations of any given process.

0 comments voice your opinion now!
package reinvent wheel opinion duplication design principles phpfig clone


Gonzalo Ayuso:
Talk about SOLID and Symfony at the deSymfony 2014 conference.
June 03, 2014 @ 09:23:21

Gonzalo Ayuso has posted a wrapup and the slides from his SOLID presentation at this year's deSymfony conference recently held in Barcelona, Spain.

Last saturday I attended to the deSymfony conference in Barcelona. A great opportunity to meet again with the PHP and Symfony community in Spain. This year the conference accepted my talk about SOLID and Symfony. Here you can see the slides of the talk (slides in spanish). [...] The conference was perfect. Barcelona is an incredible city and the conference place (10 minutes walking from the Sagrada Familia), was incredible too. Great talks. But the best, as always, the coffe breaks with the conversations with the Symfony and PHP community from Valencia, Zaragoza, Madrid, Barcelona, ...

His talk (in Spanish) covers some of the basics around the SOLID design principles including definitions of each piece and brief code snippets to illustrate. If you're interested in a bit more detail around the SOLID principles in PHP, check out the first four parts of a series over on for each principle: Single Responsibility, Open/Closed, Liskov Substitution & Interface Segregation and Dependency Inversion principles.

0 comments voice your opinion now!
solid design principles desymfony14 conference barcelona spain

SOLID Part 3 - Liskov Substitution & Interface Segregation Principles
January 27, 2014 @ 11:51:30

On today they've continued their series covering the SOLID development principles with the next letter in the acronym - "L". It stands for the Liskov Substitution & Interface Segregation Principles. The tutorial also talks some about the "Interface Segregation Principle" as they go hand-in-hand.

The concept of this principle was introduced by Barbara Liskov in a 1987 conference keynote and later published in a paper together with Jannette Wing in 1994. Their original definition is as follows: "Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T." [or more simply] "Subtypes must be substitutable for their base types."

They include some example PHP code showing a base "Vehicle" class and first an example of doing it correctly (with the Template design pattern) and an example of an incorrect method, complete with tests. They then get into the Interface Segregation Principle, an interface that can be depended on to use the module, with the same car-related examples.

0 comments voice your opinion now!
solid design principles liskov substitution interface segregation

SOLID Part 2 - The Open/Closed Principle
January 21, 2014 @ 12:45:29

On today they continue their look at the SOLID development principles with the next letter in the sequence - O for Open/Closed Principle. The first part of the series, covering "S" (the Single Responsibility Principle) can be found here.

The Open/Closed Principle, OCP in short, is credited to Bertrand Mayer, a French programmer, who first published it in his book Object-Oriented Software Construction in 1988. The principle rose in popularity in the early 2000s when it became one of the SOLID principles defined by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices and later republished in the C# version of the book Agile Principles, Patterns, and Practices in C#. What we are basically talking about here is to design our modules, classes and functions in a way that when a new functionality is needed, we should not modify our existing code but rather write new code that will be used by existing code.

They start with a look at OCP in the overall SOLID context and an example of an obvious violation of the principle. Some example code is provided showing a "Progress" class that's bound to at "File" implementation, not abstracted. They offer three different options for solving the issue:

  • Take Advantage of the Dynamic Nature of PHP
  • Use the Strategy Design Pattern
  • Use the Template Method Design Pattern

Each of the above comes with example code and some with illustrations of the structure they create.

0 comments voice your opinion now!
solid design principles open closed tutorial introduction

SOLID Part 1 - The Single Responsibility Principle
December 16, 2013 @ 13:10:55 kicks off a new series of posts today with this first article covering the SOLID development practices. SOLID is a set of principles that can help make your code more robust and well structured in the long run. In this first post they jump right in with the first letter - "S" for Single Responsibility Principle.

[The Single Responsibility Principle] is one of the five SOLID agile principles. What it states is very simple, however achieving that simplicity can be very tricky. A class should have only one reason to change. But why? Why is it so important to have only one reason for change? [...] Even though you may not use a compiled language, you may need to retest the same class or module for different reasons. This means more QA work, time, and effort.

They go on to talk about how to figure out the "audience" for your class and how that effects what it should contain. A few "class examples" are shared in the post including objects that can print or save themselves. There's a bit of talk about software design ideas to consider and a less obvious example that might be breaking the principle (and how to fix it).

0 comments voice your opinion now!
solid design principles single responsibility principle

Evolving code
November 01, 2013 @ 13:28:06

On today timoh has posted a "brief look back" at PHP's evolution to be "enterprise ready" and looks towards the future with some speculations as to what the coming years will bring to the language and its community.

I'm trying to evoke some disqussion about how we have come to the current point of life we have now going on in the PHP field, as an architectural decisions, design and best practices we use to build PHP based software today. [...] Of course PHP language itself has put some walls to design the software the way one would have liked, but still there are alot that could have been done better even "back in the days". At least "better" in a sense what it means today.

He points out that in recent years there's been a push in the community as a whole for things like SOLID/DRY principles, decoupled code and testing. He speculates about the future of things like the Symfony and Zend Frameworks (and the radical changes they both made from their version one to version two). Have your own thoughts about the evolution of PHP and where it might be headed? Share them here!

0 comments voice your opinion now!
evolution code community principles symfony zendframework


Ben Youngblood:
MVC Is Not Enough
September 04, 2013 @ 09:12:25

Ben Youngblood has a new post to his site suggesting that MVC is not enough to build good, robust applications (PHP or not) just because a good portion of the frameworks implement it.

With few exceptions, any software engineer worth his/her salt have at least heard of the model-view-controller pattern. It's been around since it was introduced to Smalltalk in the late 1970s and has been a staple pattern in object-oriented languages for as many years. Nearly all the leading PHP frameworks include some form of MVC implementation. With so many frameworks and developers espousing its use, you would think it's the best pattern for building your application. And you would be wrong.

He's not suggesting abandoning MVC altogether for something else. He just wants a reexamination of how it's being used and how to improve the structure of the applications using it. One option is to adhere more to the SOLID principles, avoiding things like domain logic in controllers and "fat" models with too much logic.

Chiefly, MVC is one part of your application, not your application. If you find that you are building your domain logic inside models, views, or controllers, then you are abusing MVC. No substantive application can, or should, be made to fit inside MVC.
0 comments voice your opinion now!
mvc opinion solid principles improvement


Community News:
"Laravel From Apprentice To Artisan" Book Release
July 17, 2013 @ 10:31:41

As is mentioned on, Taylor Otwell (author of the Laravel framework) has released his latest book about the architecture of Laravel applications.

Written by the creator of Laravel, this is the definitive guide to advanced application development with Laravel 4. Learn about dependency injection, interfaces, service providers, SOLID design, and more while exploring practical, real-world code examples. Whether you're building a robust, large application with the Laravel framework, or just want to sharpen your software design chops, this book will be of great value to you and your team.

The book covers a lot of common architecture concepts too, not just things specific to Laravel like:

  • Interfaces as contracts
  • Working with service providers
  • the Single Responsibility Principle
  • the Interface Segregation Principle
  • the Dependency Inversion Principle

You might notice that those last few chapters are actually covering the SOLID design principles. You can pick up the book over on Leanpub.

0 comments voice your opinion now!
book release laravel framework taylorotwell architecture solid principles


Scott Mattocks:
D is for Documentation
March 04, 2013 @ 09:30:16

Scott Mattocks has wrapped up his series about LUCID development with the final letter of the acronym - D is for Documentation.

Despite mankind's best efforts, writing code is still clearly an exercise for talking to computers. It has not evolved to the point where talking to a computer is as easy and natural as talking to other people. That's why documentation is so important. Programming languages are just a translation of a developer's intent into something a computer can execute.

He points out that even a little documentation can go a long way (even in presentations with code in the slides). It provides context and the intent of the code, not just details about what it's doing. He proposes a compliment practice to test-driven development (TDD) that turns the documentation process around - Documentation Driven Development. This is essentially writing up what the code does first, then writing tests to check it and only then writing the code to make it happen.

If you're interested in the rest of the articles in the series, check out the LUCID article on his site with links to each letter's article.

0 comments voice your opinion now!
lucid development principles documentation tdd

Community Events

Don't see your event here?
Let us know!

interview unittest configure series extension composer laravel opinion version release language install voicesoftheelephpant podcast api conference introduction list symfony community

All content copyright, 2015 :: - Powered by the Solar PHP Framework