In a post on the Dev.to site Dhurim Kelmendi shares an introduction to the SOLID principles of software development, a set of guidelines that can help to make your software more robust, flexible and testable in the long run.

This article aims to give a solid explanation of SOLID Principles and give some insight on their benefits and potential issues when applying them. Let’s go through each of them briefly.

He then goes through each of the principles and describes the basics behind them:

• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

The post isn't language specific so you won't find any code examples but it is a great introduction to the principles for those that are just starting out.

In a recent post to his site Herberto Graca shares some of his thoughts around packaging and namespacing and how it relates to the overall architecture of your application.

The architecture of a system is the high-level view of that system, the big picture, the system design in broad strokes. The architectural decisions are the structural decisions in the system, the ones that affect the whole code base, the ones that define where everything else will be built on top of.

Amongst other things, architecture is responsible for deciding the systems: components, relationships between components [and] principles guiding the design and evolution of components and relationships.

In other words, these are the design decisions that are more difficult to change as the system evolves, it’s the foundations that give support to feature development.

The post then goes on to talk about "spaghetti" architecture, what makes for a more maintainable codebase and how this impacts the overall structure. He shares a few of the "packaging principles" previously defined by Robert C. Martin and the concept of "screaming architecture" (it should be very clear about how it's structured).

Mark Scherer has a post to his site looking at developing CakePHP 3+ plugins, showing how it's much easier than it used to be with previous versions of the framework.

he days of CakePHP 2 plugins and how difficult it was to actually develop plugins are over. Back in the days (OK, I still have to do it once in a while), there was even an app required to test a plugin. Since you didn’t want to have a boilerplate app for each plugin, you usually worked in your actual app. So you had cross contamination from that messing up your tests and stuff. Really annoying.

[...] While most of the concrete examples are about plugin development for CakePHP 3, the main ideas apply to all library code you write. And if you are a developer for other frameworks, the same principles apply, only the concrete implementation might differ.

He starts with the "real story" behind his development of a plugin - a need to integrate hashid support into a CakePHP v3-based application. He uses his own library as an example (here on GitHub) and shares his thought and development process in its creation. He then shares a few helpful tips for the would-be plugin authors out there:

• Thinking about what should be in core vs a plugin.
• Try to follow coding and package principles.
• Following the six package principles including common reuse, common closure and package coupling practices.

On his Code in PHP site *Sarfraz Ahmed * has a post talking about coding to interfaces, how its done and why he thinks it's an essential part of any application.

One of the nicest things you can add to your programming skills is coding to interface.

One of the nicest things you can add to your programming skills is coding to interface. One of the five principles of S.O.L.I.D is Dependency inversion principle which states: [...] High-level modules should not depend on low-level modules. Both should depend on abstractions [and] abstractions should not depend on details. Details should depend on abstractions.

He elaborates on this "pretty formal definition" with an example MySQL wrapper class used in a User class, making them tightly coupled to each other. He also points out the same with a `UserController. As a solution to this tight coupling problem, he suggests using dependency injection (inversion of control) to pass in instances of the classes rather than creating them internally. This still couples them, though a bit more loosely, so he suggests using an interface for the dependency instead of a concrete class. This way any number of potential classes could be passed in and the class internally knows how to use them.

On Scotch.io today they've posted a tutorial about SOLID, the "first five principles of object oriented design". SOLID is an acronym made from the first letter of several principles that can help make your OOP code well-architected and easier to test.

S.O.L.I.D is an acronym for the first five object-oriented design(OOD) principles by Robert C. Martin, popularly known as Uncle Bob. These principles, when combined together, make it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development. Note: this is just a simple “welcome to S.O.L.I.D” article, it simply sheds light on what S.O.L.I.D is.

They start with a basic overview of what the letters in SOLID stand for and then work through each, providing basic code examples to help make the point clearer.

In the latest show from the Three Devs & A Maybe podcast hosts Michael Budd, Fraser Hart, Lewis Cains and Edd Mann talk about a wide range of topics with a focus on the SOLID development principles.

This week we have a three developer podcast with discussion on a host of topics. We kick off with how Fraser has enjoyed building his first bonus slot game, written entirely in JavaScript and HTML5. Preprocessors are a huge part of the JavaScript ecosystem at this time, with so many to choose from we discuss a couple of the more popular ones. This leads on to Photoshop discussion, ReactJS, the cool features present in ES6 and how you can use them today with transpilers. Following this we move on to the SOLID principles, the overuse of inheritance, technical debt and the concept of Over-DRY vs. Software Value. This then takes us on to a strange 'rubber duck' example Edd conjured up to help try and explain the Liskov substitution and Interface segregation principles. Finally, we discuss Edd's media server setup and how he has got it to a staged that he is finally happy with it.

Other topics include things like:

• Phaser - Desktop and Mobile HTML5 game framework
• Grunt
• Scotch.io
• Implementing Streams in PHP

You can listen to the latest show either through the in-page audio player or by downloading the mp3 of the episode. Also, be sure to subscribe to their feed of you enjoy the show!

In an article on Thedo.fr 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.

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.

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 NetTuts.com for each principle: Single Responsibility, Open/Closed, Liskov Substitution & Interface Segregation and Dependency Inversion principles.

On NetTuts.com 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.