Closer To The Ideal

I do not know much about Objective-C, but I’ve got a lot of friends who want to do iPhone apps, so I’ve thought about diving in.

Matt Gallagher writes about the best aspects of Objective-C in a really interesting post:

The short answer is that this dynamic message handling in Objective-C makes it much easier to work within a large framework that you didn’t create because you can examine, patch and modify elements of that framework on the fly. The most common situation where this is likely to occur is when dealing with an application framework.

The biggest reason for this is that you can add or change methods on existing objects, without needing to subclass them, while they are running. Approaches for this include categories, method swizzling and isa-swizzling.

This makes the following situations possible:

• You want to add a convenience method to someone else’s object (a quick search of my own posts reveals that about a dozens of my own posts involve adding convenience methods to Cocoa classes, e.g. Safely fetching an NSManagedObject by URI).
• You want to change the behavior of a class you didn’t (and can’t) allocate because it is created by someone else (this is how Key-Value Observing is implemented in Cocoa).
• You want to treat objects generically and handle potential differences with runtime introspection.
• You want to substitute an object of a completely different class to the expected class (this is used in Cocoa by NSProxy to turn a regular object into a distributed object).

These points may seem somewhat mild but they are central to maximizing code reuse when working within someone else’s framework: if you need existing code to work differently, you don’t need to reimplement the whole class and you don’t need to change how it is allocated.

Languages using virtual method tables can adopt some of these ideas (like the boost::any class or C♯ 4.0’s dynamic member lookup) but these features have additional restrictions and don’t apply to all objects, meaning that they can’t be used on purely arbitrary objects (such as those you don’t control or didn’t create) and so don’t help when interacting with someone else’s framework.

Simply put: dynamic message passing instead of virtual method invocations makes Objective-C a much better language for working with a large library or framework that someone else has written.

… In my opinion, Objective-C is the best language for programming situations where you must make extensive use of a framework written by someone else (particularly an application framework). The success of Objective-C in this situation is due to the combination of:

* speed and precision (from its compiled C roots)
* dynamic flexibility (due to using message passing for method invocations)

To frame this conclusion, I’ll state that I’ve written major projects using C/WIN32, C++/PowerPlant, C++/MFC, and Java/Swing/AWT. I’ve also dabbled in smaller projects using C♯/.Net. In all of these cases I have found the application frameworks to be less flexible and less reusable because they lack the dynamic modifiability of Objective-C.

When I hear the words “change methods on existing objects… while they are running” I immediately think of Ruby. In fact, till recently, Ruby was the only language I was aware of that allowed you to modify a class at runtime. Some programmers regard this as heresy. Consider the fear in Bill Venners voice as he talks about this with Yukihiro Matsumoto (the creator of Ruby):

Bill Venners: In Ruby, I can add methods and variables to objects at runtime. I have certainly added methods and variables to classes, which become objects at runtime, in other languages. But in Java, for example, once a class is loaded or an object is instantiated, its interface stays the same. Allowing the interface to change at runtime seems a bit scary to me. I’m curious how I would use that feature in Ruby. What’s the benefit of being able to add methods at runtime?

Yukihiro Matsumoto: First of all, you don’t have to use that feature. The most useful application of dynamic features, such as adding methods to objects, is meta-programming. Such features allow you to create a library that adapts to the environment, but they are not for casual uses.

So, it seems to me, Objective-C was pioneering many of the advantages that I would nowadays associate with dynamic scripting languages, like Ruby or Groovy. But an interesting thing about Objective-C is that it is a compiled language. It was compiled largely because the computers that existed back then were not powerful enough to handle script languages. Perl and Python don’t get going till the end of the 80s, and scripting languages don’t really take off till the 90s, when there was sort of an explosion of them (Ruby, PHP, etc).

The SmallTalk language was an inspiration for Objective-C, but SmallTalk ran very slowly on the machines of the early 80s:

In the early 1980s, common software engineering practice was based on structured programming. Structured programming was implemented in order to help “break down” programs into smaller parts, primarily to make them easier to work on as they grew increasingly large. However, as the problems being solved grew in size, structured programming became less useful as more and more procedures had to be written, leading to complex control structures and a low level of code reuse.

Many saw object-oriented programming as a potential solution to the problem. In fact, Smalltalk had already addressed many of these engineering issues; some of the most complex systems in the world were Smalltalk environments.[citation needed] On the downside, Smalltalk used a virtual machine. The virtual machine interpreted an object memory called an image, containing all development tools. The Smalltalk image was very large and tended to require huge amounts of memory for the time. The virtual machine also ran very slowly, partly due to the lack of useful hardware VM/container support.

So what was needed, at that time, was a compiled language that offered the flexibility of object oriented code, and perhaps some of the productivity benefits of dynamic languages:

Objective-C was created primarily by Brad Cox and Tom Love in the early 1980s at their company Stepstone. Both had been introduced to Smalltalk while at ITT Corporation’s Programming Technology Center in 1981. Cox had become interested in the problems of true reusability in software design and programming. He realized that a language like Smalltalk would be invaluable in building development environments for system developers at ITT. Cox began by modifying the C compiler to add some of the capabilities of Smalltalk. He soon had a working implementation of an object-oriented extension to the C language, which he called “OOPC” for Object-Oriented Programming in C. Meanwhile, Love was hired by Schlumberger Research in 1982 and had the opportunity to acquire the first commercial copy of Smalltalk-80, which further influenced development of their brainchild.

Objective-C arrived at Apple via NeXT:

After Steve Jobs left Apple, he started the company NeXT. In 1988, NeXT licensed Objective-C from StepStone (the owner of the Objective-C trademark) and released its own Objective-C compiler and libraries on which the NeXTstep user interface and interface builder were based. Although the NeXT workstations failed to make a great impact in the marketplace, the tools were widely lauded in the industry. This led NeXT to drop hardware production and focus on software tools, selling NeXTstep (and OpenStep) as a platform for custom programming.

…After acquiring NeXT in 1996, Apple Inc. used OpenStep in its new operating system, Mac OS X.

I can imagine that at the time Steve Jobs was starting NeXT, Objective-C would have huge appeal as the most dynamic compiled language available at that time. And Jobs has stuck with it for over 20 years now, first bringing it into the MacOS and then making it the basis of programming in the iPhone API.

The Wikipedia page says Objective-C tends to run 3 times slower than plain C. I imagine that used to matter, though of course nowadays large projects (possibly the majority of all software written?) is written in languages that depend on a virtual machine, so I assume Objective-C is faster than most of the languages that are nowadays in heavy use.

All of this leaves me somewhat curious about why Objective-C isn’t more popular. Perhaps it is just too much in the middle in terms of performance versus its dynamic nature? Nowadays programming tends to fall into 2 worlds – when you need speed, write in C, but if you want dynamic productivity, use something like a script language: Ruby, Groovy, PHP. Or, at the very least, a language that cleans up variables and memory for you (automatic garbage collection) as in Java and C#. Possibly it is the lack of automatic garbage collection that has kept Objective-C from taking off?

I like this:

Bill Venners: I’ve found that many people don’t seem to think about programming so much in terms of the interface as an abstract contract and the implementation as one way to implement that contract. They just think in terms of “the code.” But the throws clause is part of the interface.

I’d forgotten how much I liked Artima. It was at something of a peak back in 2003, which just happened to be the year that I was moving past mere coding and moving onto to larger theoretical concerns. 2003 was the year I started studying Java, and theories of object oriented development. I recall, when I first started reading of issues beyond simply the syntax of the code, how fascinated I was with the subject, for a long while.

This summer I worked on a project where some other programmer had used the Context object in the model classes. This caused ridiculous problems. For instance, to run the command line tools (such as “symfony propel:build-model”) I had to hard-code the loading of a context object into the core classes – what an ugly hack!

So I was intrigued to read of the problems that the Context object can cause in your form classes, and how dependency injection gives us an easy way to avoid needing the Context object.

You might read that and think “woah, this is getting complicated!” but we’re not talking about dependency injection containers here, we’re simply saying that you can make your form object depend on something to run. The thing it depends on should not be the context singleton, it should be the minimum thing that the form needs to operate correctly – which in this case, is a user object that supports credentials.

…The test here is where we are making this form “dependent” on a user object. In this case we are insisting that the object is an instance of sfUser, which you may argue is tying us in to symfony again, but you could use any test here to ensure that the object will have the necessary functionality you need, maybe check for the existence of a “hasCredential()” method for example.

When writing a test for this form class, we now only need to instantiate a user object and load it with some credentials – much easier than doing the same thing and locking into a context singleton. There may be other times when this form could be useful in a lightweight environment, where you can get speedy access to a user object but don’t want the overhead of the symfony context – you might not think of one now, but it’s best to code this way and you’ll have less reasons to kick yourself further down the line.

As I recall, when I was getting into programming in the late 90s, and especially when I was getting into PHP, there was a debate about the value of light-weight scripting languages, such as Ruby, Python, Perl and PHP. Some old-school programmers insisted that working with those languages didn’t count as “real” programming – those languages were too easy. And many old-school programmers were critical of the performance hit one takes with the light-weight scripting languages. After all, for some tasks, a routine written in C will run more than 100 times faster than the same routine written in PHP. A two-order-of-magnitude difference in execution speed needs to be taken seriously. Of course, on the flip side, a programmer can rapidly prototype new software with a light-weight scripting language, whereas using C would take much, much longer, and then it would be harder to change once it was done.

Back then, the decision was seen as either/or: either use a light-weight scripting language, or use a lower-level language that is more efficient.

In recent years, the new style has been “both”: mix the high-level and low-level languages. Use light-weight scripting languages to prototype some software, then look at the bottlenecks and drop into a lower level language for those parts of your code that need the speed. For instance, consider what David Heinemeier Hansson says about Campfire, the chat software he helped developed. First written in Ruby On Rails, it soon became clear that the code that polls to see who is in the chat room needed to be as fast as possible:

We rewrote the 100 lines of Ruby that handled the poll action in 300 lines of C. Jamis Buck did that in a couple of hours. Now each poll just does two super cheap db calls and polling is no longer a bottleneck.

Campfire and a shared todo list is different because they’re not working on a shared resource. There’s no concept of locking. Or two people dragging the same item. So a 3 second delay between posting and showing up doesn’t matter. It does when you’re working on a shared resource.

In between C and the light-weight script languages are those languages that added some extras, such as Java, C# and Erlang. Java and C# offer object orientation and automatic garbage collection, whereas Erlang offers automatic concurrency. The crew at 37 Signals has decided to re-write the polling in Campfire, using Erlang:

Last Friday we rolled out the Erlang based poller service into production. There are three virtual instances running a total of three Erlang processes. Since Friday, those 3 processes have returned more than 240 million HTTP responses to Campfire users, averaging 1200-1500 requests per second at peak times. The average response time is hovering at around 2.8ms from the time the request gets to the Erlang process to the time we’ve performed the necessary MySQL queries and returned a response to our proxy servers. We don’t have any numbers to compare this with the C program that it replaced, but It’s safe to say the Erlang poller is pretty fast. It’s also much easier to manage 3 Erlang processes than it was the 240 processes that our C poller required.

The diversity of language choices allows programmers to find exactly the right level of abstraction. When do you need programmer efficiency, and when do you need the code to execute efficiently? One needs a variety of languages so one can always get the right level abstraction for a given project. I think this is part of what Larry Wall was talking about:

Doing it right involves treating the evolution of the language as a pragmatic scope, or as a set of pragmatic scopes. You have to be able to name your dialect, kind of like a URL, so there needs to be a universal root language, and ways of warping that universal root language into whatever dialect you like. This is actually near the heart of the vision for Perl 6. We don’t see Perl 6 as a single language, but as the root for a family of related languages. As a family, there are shared cultural values that can be passed back and forth among sibling languages as well as to the descendants.

As I previously wrote:

Larry Wall is a deep thinker. And he has been developing a deep philosophy of computer languages. Yet the world of Java has, quite surprisingly, opened up and become a world of many languages: Groovy, JavaFX, JRuby, hecl, Jython, etc. No one would have guessed, in 2002, how much Java was going to open up. But while Larry Wall has been thinking about Perl 6, the Java community went ahead and created the reality that he was merely thinking about: “So there needs to be a universal root language… [and] shared cultural values that can be passed back and forth among sibling languages as well as to the descendants.”

I’ve written a little Java in the past, but I’ve always hated how heavy it is. Double casting a variable when you declare it leads to code that strikes me as overly verbose, for my purposes. Most of the time, I work on code that should be built quickly, and execution speed is not a concern. However, I’ve recently started studying Groovy, and I like it quite a lot. It is a light-weight scripting language that runs on the JVM. Using it, one can drop back to standard Java any time one needs a performance boost, or one needs to take advantage of a library that is specific to Java. You could knit together software made of Java pieces, using Groovy as the glue.

This, it seems to me, is the new style. We no longer face an either/or decision about high-level and low-level languages. Rather, the new pattern is, start high, and then drop down to a lower level whenever you need the extra power.

For the sake of readability, I do this in my PHP code, as well:

One would definitely call it like this:

this.updatePost(true);

The problem is, that’s not very explanatory. In other words, you can’t tell straight from the line what this true does. I propose a solution that takes advantage of loose typing: just pass a string containing a parameter name as an argument.

this.updatePost('highlight');

Now, this is definitily more verbose.

Took me a moment to figure this out, so I will put this here, in case I need to remember this later.

I was debugging some form code tonight, because my forms are not getting populated with data when the user wants to edit old entries. These are the forms that were auto-generated by Symfony, so they should work perfectly.

The module name is “Alumni” and its code is for working with the database table called “alumni”. In the actions.class.php file for the “alumni” module I have this:

public function executeEdit($request)  {
$this->form = new AlumniForm(AlumniPeer::retrieveByPk($request->getParameter('id')));
}

This is auto-generated code.

The job of AlumniPeer is obvious enough – given an id (which it expects to find in the URL) it finds a row in the database, gets the data, and turns that into an “Alumni” model object. Note that the class called “Alumni” is a class for dealing with the database – this tripped me up for a moment. The class called “Alumni” has nothing to do with the forms. But the forms classes will eventually need this info.

I looked to see what AlumniForm looked like.

class AlumniForm extends BaseAlumniForm
{
public function configure()
{
}
}

It is an empty form class that inherits from its base class.

BaseAlumniForm has just two methods:

setup()

getModelName()

The setup() method just initiates an array of validators, for handling the forum input, and an array of form widgets, so it knows how to create the forms.

The getModelName() method really just returns the name of the model:

public function getModelName() {
return ‘Alumni’;
}

Since there is no constructor, I became curious where setup() was called from. BaseAlumniForm inherits from BaseFormPropel which inherits from sfFormPropel. I took a look at its constructor:

public function __construct(BaseObject $object = null, $options = array(), $CSRFSecret = null)
{
$class = $this->getModelName();
if (is_null($object))
{
$this->object = new $class();
}
else
{
if (!$object instanceof $class)
{
throw new sfException(sprintf('The "%s" form only accepts a "%s" object.', get_class($this), $class));
}

$this->object = $object;
$this->isNew = false;
}

parent::__construct(array(), $options, $CSRFSecret);
$this->updateDefaultsFromObject();
}

There is something quite elegant about the way this auto-generated Symfony code fits together. The first thing that happens is that the constructor calls the getModelName() method in the BaseAlumniForm child class (actually the grand-child class). This, as you can see above, returns “Alumni”, so sfFormPropel now knows which class is suppose to be handling the database data (or rather, which class is suppose to return a model to call a row of data in the database). If for some reason the constructor has not been handed an instance of Alumni, then it creates a new instance. But above we saw that in actions.class.php, the form class is given an instance of the correct model:

$this->form = new AlumniForm(AlumniPeer::retrieveByPk($request->getParameter('id')));

So, at least in the auto-generated code, the constructor to sfFormPropel is always being given an instance of the correct model. If it was handed an object of the wrong class, then it would throw an appropriate exception.

The constructor ends by calling the constructor in its parent, which is sfForm:

public function __construct($defaults = array(), $options = array(), $CSRFSecret = null)
{
$this->setDefaults($defaults);
$this->options = $options;

$this->validatorSchema = new sfValidatorSchema();
$this->widgetSchema = new sfWidgetFormSchema();
$this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);

$this->setup();
$this->configure();

$this->addCSRFProtection($CSRFSecret);
$this->resetFormFields();
}

This is where setup() gets called.

This is also where configure() gets called. Mind you, configure() starts off as an empty method in the class AlumniForm:

public function configure()
{
}

This is where you do all your customization. They offer this example in the Symfony Cookbook, in the article How To Implement A Choice In Forms:

// lib/form/DemoArticleForm.class.php
class DemoArticleForm extends BaseDemoArticleForm
{
public function configure()
{
$this->widgetSchema['status'] = new sfWidgetFormChoice(array(
'choices' => DemoArticlePeer::getStatusChoices()
));

$this->validatorSchema['status'] = new sfValidatorChoice(array(
'choices' => array_keys(DemoArticlePeer::getStatusChoices())
));
}
}

In this example, they are making a change to the widgetSchema and validatorSchema arrays, which would have been set in the setup() method of the BaseDemoArticleForm class.

I am planning on building a new scaffolding system for Syfmony. One of the many great things about the vibrant community that surrounds Ruby On Rails is that for every default in RoR, there are competing alternatives – for instance, you can replace the default scaffolding with ActiveScaffold. Similarly, I’d like to build an alternative scaffolding system for Symfony. Understanding how the forms are currently built is the first step.

Jamis at 37 Signals has up a strange post in which he is critical of modules. I say “strange” because his tone is defensive and he interrupts his post to repeatedly to insist that modules are really great:

The code remains really clean, overall, because we’ve continued to follow the pattern of moving related methods into modules, and just including those modules in the base model.

Got that? Refactoring code out of your main classes and into modules is  a great way to keep your code clean. He emphasizes:

Don’t misunderstand me, though. Modules are awesome. We use them a bunch, and love them.

and then:

Modules are very handy, and as I said before, we still use them extensively.

He seems worried that someone is going to criticize him because of his criticism of modules. Yet his criticism is almost the same as Michele Simionato wrote in last month’s explicitly anti-module post.

Jamis writes:

However, there are two issues with this approach. First, when a class includes lots of modules (as some of ours do), it becomes hard to keep track of where different methods are defined, and even which methods are defined. This can lead to confusion when trying to find the definition of a method, and (worst case) can allow two or more methods with the same name, which is bad. There is no warning if you have methods with the same name in multiple modules, so it isn’t hard to wind up with bugs where you’ve clobbered a method with another. You wind up double-namespacing your methods (e.g., method names in the Avatar module being prefixed with avatar_), to avoid collisions.

…There are more issues with the module approach. What if you have different kinds of avatars (e.g., person versus group, or company)? You can’t subclass modules in Ruby, so you wind up finding other ways to solve it (like including modules in modules, etc.). Also, you can’t reference the avatar as a separate entity; instead, controllers that deal with avatars need to deal with the entity to which the avatar is attached.

And what solution does he offer for these problems? I was thinking he was going to say something really original, because it sounded like he was really wedded to the idea of using modules. But in the end, his solution is to simply not use modules:

Can the avatar code be split out further, somehow? Yes, it can. We’ll do this by making avatars a model of their own and using aggregation (rather than module inclusion, or inheritance) to pull it into Person.

So the solution is simple: don’t use modules, use independent classes and then build your objects through composition. This is probably very good advice, though I was a little surprised by his conclusions, given that he started off sounding like a big fan of modules.

Martin Fowler wrote a long article about “Inversion of Control Containers and the Dependency Injection pattern“. I recall struggling to read this article back in late 2005 or early 2006. It was really mind numbing at the time. For some reason, folks writing for the Java community feel the need to surround their ideas with a fair amount of ceremony. Also, the folks attracted to Java seem to be folks who are attracted to abstractness for its own sake. Fowler is a great writer and a genius of a programmer. Nevertheless, sometimes it is nice to say things plainly and simply. (Fowler is writing for a tough crowd – experienced Java programmers who can think of a counter-argument to all his arguments, and even counter-counter-counter arguments to all his counter-counter arguments. So his writing must contain a number of qualifiers that add to the complexity.)

I just reread the article and, since I’ve had years to grow used to its ideas, I found it easy to read. Allow me to summarize it here, as quickly and simply as possible, using PHP for what examples I give.

The problem to be solved is dependency. If you have an object that is dependent on another object, then your code is more brittle than it needs to be. A direct call from one object to another is an example of tight coupling. If that dependency could be made less direct, then your code would be more loosely coupled. When imagining the set of classes that will make up your software, your design goal should be “small pieces, loosely joined.”

I’ll use an example similar to the one that Martin Fowler uses.

Imagine you’d like to build some software that looks up all the movies that are made by a particular director. You might have a class that looks like this:

class MovieLister {

function moviesDirectedBy($nameOfDirector) {

$finder = new FindMoviesInCommaSeparatedList();

$arrayOfMovies = $finder->findAllMoviesMadeByThisDirector($nameOfDirector);

return $arrayOfMovies;

}
}

So this method returns an array with the list of movies it just found. If you are using this on a web site, for instance, you could now loop through the array and wrap it in some HTML and, viola, you’ve a nice little service that is listing all the movies made by some director.

But this line of code is bad:

$finder = new FindMoviesInCommaSeparatedList();

It is bad because you are using FinderMoviesInCommaSeparatedList directly, and this is a case of tight coupling. And yes, the name is clearly awful, but that is deliberate. Things would still be just as bad if you changed the name:

$finder = new FindMovies();

If FindMovies still looks up its data in a comma separated list, you are still tightly coupled to a particular way of looking up data. What if, in the future, you want to look up movies in a database?

Let’s imagine that you run a web design shop, and two new customers walk in. They hire you to build two different web sites. They both want to use this movie listing software you’ve developed, but one wants to store data in an XML file, and another wants to store data in a MySql database. How do you adapt the software to those different circumstances? You could edit the code for each customer, but then you’d essentially have two separate software programs, rather than one. Assuming you are called upon to maintain this software, and debug it, you would be facing twice the costs. Wouldn’t it be better if you could stick with one code base, and have a configuration file control those things that need to be different on the different sites?

In a real life application (let’s say for a website) you’ll often have multiple objects in use in a class:

class MovieLister {

private $finder;
private $html;
private $user;

function __construct() {

$this->finder = new FindMovies();

$this->html = new HtmlMaker();

$this->user = new UserManager();

}

function moviesDirectedBy($nameOfDirector) {

if($this->user->isLoggedIn()) {

$arrayOfMovies = $this->finder->findAllMoviesMadeByThisDirector($nameOfDirector);

return $arrayOfMovies;
}
}
}

This is some brittle code. MovieLister now depends on 3 other objects. If you later decide that MovieLister should use replacements for FindMovies or HtmlMaker or UserManager, you need to come here to this class and change the way the code is written. Again, wouldn’t it be better if you could make such changes from the configuration file?

That’s the basic idea of both the “dependency injection” pattern and the “service locator” pattern: the decision about what class you are using gets moved to a configuration file.

Imagine we have an object that can fetch other objects based on settings in a configuration file. We could re-write the constructor like this:

function __construct() {

$dm = new DependencyManager();

$this->finder = $dm->fetch(”FindMovies”);

$this->html = $dm->fetch(”HtmlMaker”);

$this->user = $dm->fetch(”UserManager”);

}

This is more flexible. Imagine that DependencyManager looks in some kind of configuration file (perhaps a big XML file) and finds out that, on this particular website, the call to “FindMovies” should really get FindMoviesMySql, which is a class that looks up the movies in a MySql database. On another website, using the same code but a different configuration, the same call to “FindMovies” fetches an instance of FindMoviesInCommaSeparatedList.

Your code is now more loosely coupled. You can make changes from the configuration file, so you no longer need to come here and directly edit your code, even when you want to make changes to the objects that are in use.

The only problem with the above constructor is that we are still directly dependent on DependencyManager. This could be fixed like so:

function __construct($dm) {

$this->finder = $dm->fetch(”FindMovies”);

$this->html = $dm->fetch(”HtmlMaker”);

$this->user = $dm->fetch(”UserManager”);

}

Now the DependencyManager can be invoked at some high level in your code, and perhaps the place where it is created could also be dependent on some setting in configuration. If you do that, you’ve achieved some wonderfully loose code. Your software is now insulated against a wide variety of changes that it might face in the future.

For the record, “inversion of control” is a fancy term, and it can apply to a lot of things, but when it comes to the “dependency injection” pattern mostly it just means that decisions are being moved from your code to some code that is outside of the current software. That is, normally your script will cause something to happen, and then another thing, and then another thing, but with inversion of control, some outside software will take charge for awhile and make some important decisions.

In his article, Martin Fowler talks about two patterns of managing dependency. He calls these two patterns “dependency injection” and “service locator”. The DependencyManager object that I’m showing in the code above is an example of the “service locator” pattern. This is an object that looks up other objects (other “services”) based on settings in the configuration file. The only possible problem with the service locator pattern is that you still have this object in your code, and you still have its interface there, so changes to its interface could harm your software, so clearly you’ve got a kind of dependence there. Most of the time, this won’t be a serious problem – it’s just the interface you’re dealing with. You can change to a different service locator, so long as it maintains the same interface.

With the dependency injection pattern you assume that you have some high level code, outside of your main code, that initiates your objects and which simply injects the objects that your code is dependent upon. There are different ways to do this but the main way is to use a constructor. So if you were using dependency injection, the above code might look like this:

function __construct($finder, $html, $user) {

$this->finder = $finder;

$this->html = $html;

$this->user = $user;

}

So in this example, all the complicated questions of managing dependencies is removed from your main code and placed in some high level code that works from the configuration and takes care of the dependencies for all of your objects. Your main code ends up looking quite simple, as you can see above.

Which is better, the dependency injection pattern, or the service locator pattern? That depends on context. Martin Fowler has this to say:

Inversion of control is a common feature of frameworks, but it’s something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn’t to say it’s a bad thing, just that I think it needs to justify itself over the more straightforward alternative.

…A lot of this depends on the nature of the user of the service. If you are building an application with various classes that use a service, then a dependency from the application classes to the locator isn’t a big deal. In my example of giving a Movie Lister to my friends, then using a service locator works quite well. All they need to do is to configure the locator to hook in the right service implementations, either through some configuration code or through a configuration file. In this kind of scenario I don’t see the injector’s inversion as providing anything compelling.

The difference comes if the lister is a component that I’m providing to an application that other people are writing. In this case I don’t know much about the APIs of the service locators that my customers are going to use. Each customer might have their own incompatible service locators. I can get around some of this by using the segregated interface. Each customer can write an adapter that matches my interface to their locator, but in any case I still need to see the first locator to lookup my specific interface. And once the adapter appears then the simplicity of the direct connection to a locator is beginning to slip.

…So the primary issue is for people who are writing code that expects to be used in applications outside of the control of the writer. In these cases even a minimal assumption about a Service Locator is a problem.

I have a personal PHP framework that’s been in development since 2002. For my personal style of coding, getting the right dependency manager in place was the single most important design decision I ever made. Through trial and error, over the course of two years, I stumbled into my current design. Without even knowing the name of the pattern, I developed a service locator. As Fowler points out, a service locator is the ideal choice for managing dependencies in situations where the author has full control over the relationship between the base code and the client code. When you, as the author, know where your base code (providing services) will live, and where your client code (dependent on those services) will live, then a service locator makes sense.

That was back in 2004, before I had even read Fowler’s article – though having struggled with the issue of dependency, I was hungry for information on the subject (though, as I said above, I found the article overly abstract the first time I read it).

In the end, the dependency manager I put in place allows so much flexibility that I haven’t needed to change it in the last 4 years. It allows my code to evolve with each new project I take on. Whenever I need to replace a class, I simply do so, and the rest of the code is insulated from that change – no surprising bugs crop up.

On a different subject, I’ve already written of a bitter experience I’ve had trying to manage a Flash project. I am curious how dependency injection would be handled in ActionScript 3, and how that would get worked into a Flash project. Maybe I don’t understand enough about Flash/Flex, but the setup of the average Flash project seems resistant to a lot of the best ideas in OOP programming.

(Speaking of Martin Fowler, I just noticed someone has created a PHP version of PicoContainer, for doing dependency injection in PHP the way Fowler suggested.)

I’m a little amazed at the ability of Javascript to mimic other languages. Prototype has added some features that allow Javascript to imitate some aspects of Ruby. This article gives Javascript a set of methods that allow a close imitation of standard object inheritance, as seen in languages like Java or C#. The author offers the standard qualifiers:

The following is a discussion of a technique I’ve used over the years to simulate the feeling of Object-Oriented Programming in languages like C# and Java. The keyword here is “simulation”. This is not necessarily equivalent to what you would encounter in those languages. JavaScript is a very expressive language and, as a result, there are a wide variety of techniques you can employ to build re-usable and extensible code. What I describe here is by no means the final answer on that subject.

As a side note, this article will use OOP terminology common to Java and C#; however, this vernacular is technically incorrect when discussing JavaScript in general. So, if you find it offensive to mix that terminology with JS then close this page now! For the rest of you, keep in mind that I am merely presenting an idiom. I tend to build libraries, so this particular style of JS coding fits my needs well. Others will argue that it is pointless to write JS in this way. If you decide to use this approach or even to roll your own OOP JS, be prepared for debates much like the tab vs. whitespace argument.