Dependency Injection and OO

Once upon a time, there was Object-Orientation, and people liked it and wanted to do complex things with it. One idiom that was widely used was dependency injection:

class PaymentCard {
  public boolean validateTransaction(Transaction t, Communicator c);
}

Here, a transaction (a different Object) is validated using some communication channel (a different object, being injected). The subclass could then just say

class VisaCard extends PaymentCard {
  public boolean validateTransaction(Transaction t, Communicator c) {
    super.validateTransaction(t, new VisaCommunicator());
  }
}

Alas, the real world is not that easy. The VisaCommunicator is probably something that needs to be injected into VisaCard, or else it needs other injections like SerialCommunicator, EthernetCommunicator, RandomGenerator, CertificateHandler and whatnot. Pretty soon, the methods become huge.

"This is a bother", says everybody, and proceeds to move the injections into the constructor. However, it still means that to construct an object, you need to know what it and all objects it constructs needs injected.

"This breaks encapsulation", says everybody, and proceeds to make Dependency Injection frameworks where all these things are done automagically with annotations, reflections and all manner of other niftiness. Now several layers of reflection, lookup and wrapping is done for each object creation.

"This is slow", says everybody, and proceed to move the injection into "beans" that handle various layers of services: web service layer, business service layer, data access objects, ... The injections can now be done only when a new bean is needed, and since beans are stateless, they can be pooled and reused. Much faster. Scales nicely.

"This is not object-oriented", says I. My objects no longer have any significant functionality on them, since anything that requires injections (which turns out to be many things) must live in the beans. Code becomes spaghetti once again. However, these injections are almost all "static" injections - the objects injected are always the same class and have no state. So maybe each "OO class" (class that is actually object-oriented) could have an associated class that just holds its injections? It cannot be a static field, as they don't play well with beans. It should just be findable at construction time to be plugged into the object. Surely somebody has done this, I says, and wander off looking for a solution

iPhone development license changes

While my iPhone development has been put on the back burner in favor of other activities at the moment, I still have a plan to develop a memory training program in Lua. However, this would appear to put a more permanent hold on my plans, as Lua development simply won't be allowed anymore. Here's the letter I wrote to Apple in response:

Dear Apple,

One of the news to greet me this morning was the information that you're changing section 3.3.1 of your iPhone Developer Program License Agreement to exclude the use of other languages than Objective-C, C++ and Javascript for iPhone development. I have been planning to develop iPhone apps in Lua, but if this change stands, I will be using my $100 a year on other investments instead.

Banning all but these three languages would be a boneheaded move on your part, as it would extinguish in an instant a number of thriving development communities, most of whose members would probably go to a more liberal platform like Android. I fail to see how this change is beneficial to the future of the iPhone platform.<

If, as some have suggested, you are doing this to prevent systems like Adobe's Flash compiler from allowing cross-platform development that would it easy to have the same application on both iPhone and other mobile platforms, why not just say so? It would be easy enough to disallow applications in the App Store from also being made available on other platforms without excluding exciting new or existing technologies and the multitude of programmers who master them.

This change seems like a complex technological solution to a simple social problem, and will be harmful to the larger iPhone development community in the long run. It also saddens me that such onerous and arbitrary restrictions should be placed on a system I have grown so fond of. While I adore the care and thought that has gone into designing and developing the iPhone and most other Apple products, this and other policies of non-openness makes me question whether this is really a company I want to support with my time and money.

Yours in hope of a change for the better,

-Lars Clausen