PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

On Libraries and Dependencies

Note: This article was originally published at Planet PHP on 18 April 780.
Planet PHP

Recently, Aura is creating some buzz that components of PHP frameworks should not have any dependencies. To quote Paul M. Jones' recent article on Aura:

The distinction is that all Aura packages (with the exception of the Framework package) are completely independent, and have no cross-package dependencies, whereas at least some of the components from Symfony2 and ZF2 have dependency requirements.

Or, quoting this article on replacing Silex with Aura.Micro:

I was recently working on a small project that usedASilex. As I browsed my vendor folder, I realized how much extra aostuffa I had inherited with Silex. There were a bunch of other components required when all I wanted was some quick and easy routing, micro-framework style.

I think this needs some urgent clarification before this way of thinking becomes mainstream and PHP creeps back into its NIH-hole.

Dependencies Are Bad

The general attitude of people arguing against dependencies is that dependencies are a bad thing. Why could they be a bad thing?

Because I have to install them all by hand.

This used to be a problem, but void now that we haveAComposer.

Becaues they clutter up my hard disk space.

Hard disk space is cheap, and internet connnections are fast, so whether you upload 500k to your web server or 1M does not really make a difference anymore.

Because they eventually might become unsupported.

That's a problem, but it's a problem of the developer of the library, who should pick dependencies that he trusts. You as a user don't have to care about that.

Because they confuse me.

Composer installs dependencies into a directory aovendor/a, so they are hidden away from you. If you ever browse them, you probably know what you're looking for.

Because it's not micro-frameworkish.

I suggest to join the nearest church if you are into religious debates.

Are They Really?

Why do libraries have dependencies at all? Is a library with dependencies less decoupled than one without?

The reasoning for dependencies usually goes like this:

If I need some functionality, and if another library does that, I should reuse that library.

For example, let's look at the Guzzle HTTP Client's composer.json:

"require": { "php": "=5.3.2", "ext-curl": "*", "symfony/event-dispatcher": "=2.1" },

Guzzle needs event dispatching and relies on the Symfony2 Event Dispatcher to do so. There's no point in coding another one if there's a solid, mature and tested implementation available, right now, for free, that does what you want.

Coupling vs. Cohesion

One major argument for the elimination of dependencies is aodecouplinga. So let's examine two important quality criteria in software engineering: Coupling and Cohesion.

InAsoftware engineering,AcouplingAorAdependencyAis the degree to which eachAprogram moduleArelies on each one of the other modules.

Coupling can be expressed in various degrees, ranging from high to low:

Content coupling (high)

Content coupling (also known asAPathological coupling) is when one modul

Truncated by Planet PHP, read more at the original (another 5699 bytes)