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: inversion of control, software development

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

 Counts
 ------
 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

 Subroutines/Methods:
 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: Perl, programming, refactoring, software development, software testing, static analysis