Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Delegates vs. DI

DZone's Guide to

Delegates vs. DI

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

A week or two ago, I was doing some location-based programming on the iPhone. It‘s, as you might suspect, asynchronous. Delegates solve this problem, because you tell the LocationManager, go find me a location, and when you have, here‘s a reference to an object that implements the delegate protocol. It‘s like a completion port, but without the ‘the money will be in a satchel in locker 38 of the bus station.‘ It‘s the Hollywood principle that Rod Johnson mentions from the earliest writings on DI. Except, delegates really honor that approach, DI does not.



Short history of components in Java. EJB was a disaster for a bunch of reasons, but the main ones were that they lead to what was called the anemic domain model, and there were no provisions for asynchronicity. EJB 2.1 introduced message-driven beans to redress the latter shortcoming (with all the JMS implementations, the idea was ‘if you need something asynchronous, you need message-oriented middleware.‘ The cognitive dissonance here can be explained easily: power (of Java‘s early success) made people stupid (same fate befell Spring later).

‘Hey, wait, Apple cheated me: there‘s no JMS queue on my phone! How am I supposed to get back the results of my GPS inquiry??‘

Then, I came across this hilarious thread. Intellectual snobs live by the belief that their elevated consciousness ought only be asked to devote attention to high matters. Ignorance is every bit as instructive. The guy down the thread who speaks to why delegates are stupid made me realize a bunch of things: 1. DI, to most people, really does end up just being ‘here, gimme that thing. For what? Nevermind, that‘s my business,‘ 2. Measuring something by its intentions is always a bad idea. I said this before about DI, but I am sure that metrics studies would show that this attitude would predominate. Now, in counter argument mode, sure, I could misuse protocols and do the same thing: @protocol gimmeTheThing:(id)it. But it‘s not likely to happen, because, people who learn iOS will see the right way early in their education.

Delegates seem kind of kludgey when you first see them/try to use them. But, they quickly make a lot of sense. What‘s great about them is that they have greater expressive power than DI. Protocol is really an appropriate name for this. Finished reading Growing Object Oriented Software Guided by Tests Per my earlier posts, it‘s really dominated by protocols. In addition to greater readability, delegates promote looser coupling.

This also answers the question why don‘t I miss DI in using O-C? Evolution is a long string of risky undertakings. Java spent way too long on it and got way too little for it, and in practice, it‘s a small shadow of its initial promise.

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

Topics:

Published at DZone with permission of Rob Williams, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}