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

Jason McCreary:
Writing Clean Code (Part 2)
Oct 19, 2017 @ 11:24:52

Jason McCreary has continued his series looking at writing "clean code", providing a few helpful hints you can integrate into your daily development work. In part two he goes a bit "deeper" and talks about grouping and encapsulation.

In Part 1 of Writing Clean Code I outlined three simple practices of formatting, naming, and avoiding nested code. All in an effort to improve code readability.

In Part 2, I want to go a little deeper and cover grouping. When I say grouping, I’m really talking about the Object Oriented Programming paradigm of encapsulation. Whether we group the code into a function or a class is often not important. What is important is did we improve the readability of the code.

He starts off by describing the goal of this grouping and lists three motivations for using it as a part of your application's architecture:

  • Improving communication
  • Couple data
  • Organizing code

For each, he includes a brief summary of the topic and some code examples illustrating it in action where appropriate.

tagged: clean code example opinion communication coupling organize

Link: https://jason.pureconcepts.net/2017/10/writing-clean-code/

Sarfraz Ahmed:
Coding to Interface
Dec 29, 2015 @ 09:27:48

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.

tagged: code interface dependency injection ioc solid principles objectoriented coupling

Link: http://codeinphp.github.io/post/coding-to-interface/

Paul Jones:
What's The Difference Between Tightly-, Loosely-, and De-Coupled ?
Oct 06, 2014 @ 10:20:30

In his latest post Paul Jones recounts a Twitter-based discussion that happened between Taylor Otwell (@taylorotwell) and others on Twitter about the different types of coupling in libraries or applications. The discussion focused around three different types and their definitions: loosely-coupled, tightly-coupled and de-coupled.

The quotes from the conversation come from Taylor, but Paul includes some of his own thoughts in response (things better expressed in more than 140 characters. He talks about some of the assumptions that were made during the discussion, the general knowledge level of "basic programming terminology" and how Paul views the definition of "decoupled".

If your code has a dependency on classes in a particular thrid-party package, your code is tightly coupled to the code in that package. [...] The fact that your code could be tightly coupled to another package does not mean that the other package is coupled to anything else. That is to say, the other package might have no couplings of any sort to any other code outside itself. The other package in that case is de-coupled.

He talks about how one of the main goals of the packages that make up the Aura project is to be decoupled from the start and how that can help with changing requirements/dependencies down the road. He also defines what he sees as "loose" and "tight" coupling, largely defined by the packages required in the "composer.json".

tagged: decouple loose tight coupling package library definition terminology

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

Introduction to the Law of Demeter
Oct 26, 2012 @ 12:13:35

On PHPMaster.com today they've posted an introduction to the Law of Demeter, an idea that promotes loose coupling between objects that each do their own work. This makes it simpler to make pieces interchangeable and more able to focus on their job.

With so many heuristics stating how and why software systems should cling to a specific approach, it’s pretty disappointing not seeing a broader implementation of them in the world of PHP. For example, the Law of Demeter is probably one of the most underrated in the language’s realm. Effectively, the law’s “talk to your closest friends” mantra still seems to be in a pretty immature state in PHP, something that contributes to rot in the overall quality of several object-oriented code bases.

They look at how keeping the functionality of each object focused and not "knowing too much" is a good thing and include some examples of working with a service locator, serializer and file storage classes.

tagged: lawofdepeter introduction object loose coupling


Lukas Smith's Blog:
Loose interface coupling
Dec 06, 2011 @ 11:02:18

In a new post to his blog Lukas Smith proposes an idea for a loosely coupled interface setup that would allow for easier integration between third-party libraries and other applications.

Especially as for different libraries a different subset of the community could end up collaborating. Here I see 3 options: 1) each library bundles the interfaces (even though they sit in some common namespace), 2) each project asks their users to fetch the common interfaces from some other place 3) runtime "coupling". Option 3) doesn't exist today and is what this blog post is about.

He introduces the idea of a "spl_register_compatible_interface" method that would let you compare interfaces to see if they'd mesh. There'd still have to be a lot of communication between developers to make things match, though. He suggests three "practical issues" that libraries/tools would have to overcome to use a system like this - each framework has their own interface setup, the lead time for collaboration could be too much to be worthwhile, a lack of interest from some about collaboration and the idea of competing interface methods.

He's looking for feedback from the community on the idea(s) though, so go and leave a comment with your thoughts!

tagged: interface coupling loose opinion collaboration


PHPImpact Blog:
Analysis of coupling within the Zend Framework
Jun 09, 2008 @ 07:56:00

As the PHP:Impact blog points out there's a new post from Neil Garb talking about the (loose) coupling going on inside the Zend Framework.

One of the Zend Framework's strongest drawing cards, as I see it, is its loosely-coupled structure. The name Zend Framework may be a misnomer, in fact, as ZF is more a set of reusable libraries than an actual application framework. I won't go into detail about the advantages of loose coupling, but a recent discussion on the ZF mailing list prompted me to investigate just how loosely coupled the framework is.

He's created a few graphs to show the extent of the coupling - a directed graph, the density of it and example code showing deep and shallow coupling. Here's his results.

tagged: analysis coupling zendframework graph deep shallow