Tuesday, December 26, 2006

Provider Injection, not Dependency Injection

The term "provider injection" should replace the term "dependency injection."

The term misleads by seeming to say that you are "injecting" a dependency. This would mean that the thing got the "dependency" injected into it now depends upon something that it didn't depend upon before. This is not what "dependency injection" means.

The term "dependency injection" actually means that if Object A depends upon having a "B" object that you "inject" a B object into object A (instead of object A fetching or creating a B on its own.) A classic example would be a Person object that depends upon having a database connection in order to create/update/edit/delete people in the database. Instead of the Person object creating its own database connection it gets one passed to it (i.e. "injected") perhaps as an argument to its constructor. But, see, you are not injecting a dependency. You are injecting a provider.

A "dependency" is not the thing upon which you depend. The thing you depend upon is a tool, resource, skill, or capability and you get those things by making them yourself, or from a provider.

So, I think the term "provider injection" should replace the term "dependency injection."

By the way, I want to thank Mike Ward for originally introducing me to the term "dependency injection" - whatever phrase is used, the actual practice is one I have done in the past and it is good to have a phrase to describe this technique.

See also:
Wikipedia entry on Dependency Injection (which I have attempted to edit.)
Inversion of Control Containers and the Dependency Injection pattern - 2004 article by Martin Fowler
Spring in Action - Book on Spring

Technorati Tags: ,

Saturday, December 09, 2006

countperl - count lines, packages, subs and complexity of Perl files

I recently released a new version of Perl::Metrics::Simple (0.03) that includes the countperl script. The program reports on how complicated your Perl code is - giving you direction on where to start refactoring it to make it easier to understand, debug, and maintain. Try to keep the McCabe Complexity at 9 or less for every subroutine and "main" section of your code.
countperl is a command line tool that you execute with a list of one or more files andor directories. The program examines the named files and recursivesly searches named directories for Perl files.
The countperl program produces a report on STDOUT of total lines, packages, subroutines/methods, the minimum, maximum, mean, standard deviation, and median size and mccabe_complexity (aka cyclomatic complexity) of subroutines and the 'main' portion of each file (everything not in a subroutine.)

Output Format

Line counts do not include comments nor pod.
The current output format is human-readable text. For example, a report based on analyzing three files might look like this:
 Perl files found:                3

total code lines: 856
lines of non-sub code: 450
packages found: 3
subs/methods: 42

Subroutine/Method Size
min: 3 lines
max: 32 lines
mean: 9.67 lines
std. deviation: 7.03
median: 7.50

McCabe Complexity
Code not in any subroutine::
min: 1
max 1
mean: 1.00
std. deviation: 0.00
median: 1.00

min: 1
max: 5
avg: 1.00
std. deviation: 1.36
median: 1.00

Tab-delimited list of subroutines, with most complex at top
complexity sub path size
5 is_perl_file lib/Perl/Metrics/Simple.pm 11
5 _has_perl_shebang lib/Perl/Metrics/Simple.pm 13
5 _init lib/Perl/Metrics/Simple/Analysis/File.pm 30
4 find_files lib/Perl/Metrics/Simple.pm 11
4 new lib/Perl/Metrics/Simple/Analysis.pm 10
4 is_ref lib/Perl/Metrics/Simple/Analysis.pm 8

Chris Chedgey has a posting that describes a common situation - you have accumulated a huge pile of "complexity debt" - well, using countperl is one tool to help "keep a lid on it."

Technorati Tags: , , , , ,