This is an archived post. You won't be able to vote or comment.

all 14 comments

[–][deleted] 10 points11 points  (4 children)

No comments on this yet? I thought it was interesting. Also, it was interesting that they mentioned "Dependency Injection" as a new pattern they would mention in a new edition. I have a hate-love relationshipwith that pattern. I love it because it is a sane pattern. I hate it because it has been misinterpreted to mean that you need a framework "taking care of it" for you. So now everything is managed with XML, annotations and what not... Sigh..

[–]zyle 5 points6 points  (2 children)

I was not familiar with "Dependency Injection," and had to look it up. The problem I personally have with all these myriad patterns is that they all seem to be minor variant of one simple, fundamental pattern.

So now, what really is the major distinction between "Dependency Injection", "Dependency Inversion", and "Inversion of control"? I can see and understand the subtle differences, but at the end of the day, they all just seem to be a small variation of a basic strategy pattern with some garnishing around them about how to instantiate the subclasses of the strategy.

[–]tachi-kaze 1 point2 points  (0 children)

I honestly thought they were all the same (from my old java spring days..) Doesn't spring use the term interchangeably? IoC, Dependency Injection, etc?

[–]keithb 0 points1 point  (0 children)

They have different inents. The resulting code might look very similar, but in discussion with your colleagues about what you think you are doing you would talk about them in different ways.

This is what patterns are for, to provide a vocabulary to aid better communication between people.

There are also asymmetries in the relationships between them: in order to invert control some weak form of dependency injection is typically used, but to have a strong for of DI where dependencies are injected while an obejct graph is being created in no way implies that any inversion of control is going to happen in subsequent processing.

[–][deleted] -1 points0 points * (0 children)

I hate it because it has been misinterpreted to mean that you need a framework "taking care of it" for you.

Exactly. To me it just means passing dependencies as interface parameters to ctors or method calls. Works great for C#, although some people hate long parameter lists and passing stuff everywhere instead of storing references to them in fields. Pretty much just the strategy pattern.

[–]zahlman 5 points6 points  (2 children)

(Not really—I'm in favor of dropping Singleton. Its use is almost always a design smell.)

Anyone else read the whole thing waiting for something like that? :)

[–][deleted] 1 point2 points  (1 child)

Seriously, teach people about Singletons and nearly every class becomes a Singleton.

[–]zahlman 1 point2 points  (0 children)

Yep. It comes from the same line of thinking that worships inheritance as a means of code reuse at the expense of complete disregard for composition. The fundamental problem, AFAICT, is a failure to grasp the key concept that a class defines a new data type, or else a failure to grok why this is a useful thing to do.

[–]iceice 0 points1 point  (0 children)

I studied design patterns from Ralph Johnson. He loves to talk. I am sure the interviewer would have had a hard time getting him to stop talking for long enough to end her interview. :)

But, he is a great guy!

[–]nmcyall 0 points1 point  (1 child)

What is a good book on procedural C programming design patterns?

[–]adam75 0 points1 point  (0 children)

I'm not aware of any book covering procedural patterns. However, some years ago, I wrote a series of articles covering patterns in C. The articles are available here:

[–]hjaltij 0 points1 point  (1 child)

Bah, instapaper chokes on it.

[–]Nebu 0 points1 point  (0 children)

Try "Readability".

[–]toconnor -1 points0 points  (0 children)