Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The inverse of IoC is Control

comoyo.github.com

Post reply on HN
Print view View original

61–66 of 66 posts

Re: The inverse of IoC is Control

#61

Post by MatthewPhillips »

jedbrown wrote: post #21
MatthewPhillips wrote: post #15

Earlier quoted context omitted.

Why not just split out the shared code into libraries and make your main() be different for each customer?

Then updates to the customer's configuration requires modifying code, compiling it, and shipping the result. It's easy to put an interface on configuration file modification and in many cases, updates can be applied without needing to restart a running system.

That's the problem with soft-coding, you trick yourself into believing that modifying a configuration file is not modifying code, but it is. It's code that isn't compiled, isn't regression tested.

As far as re-shipping, nearly every language nowadays has a method for automatic updates. Here is what Chrome uses: https://code.google.com/p/omaha/

Re: The inverse of IoC is Control

#62

Post by InvisibleCities »

First of all, the author doesn't hate IoC and Containers, he hates XML registration (with good reason). I can't say anything about Java, but in C#, when you use modern IoC frameworks like StructureMap and AutoFac, all registration of components takes place in code, using generics and lambdas. This allows you to easily wrap your services in interfaces, de-coupling code and making things much more testable, especially if you use a good mocking framework like Rhino. When you combine DI/IoC with ideas like the Onion Archtecture (http://jeffreypalermo.com/blog/the-onion-architecture-part-1...), writing readable, testable, flexible, maintainable applications becomes supremely easy.

Re: The inverse of IoC is Control

#63

Post by bunderbunder »

bborud wrote: post #48
nahname wrote: post #47

IoC is automating the code required to wire up objects that are properly decomposed. When you spend a long time learning how to effectively work with static languages, a few things come out. Dependency inversion and composition. Where does this leave us? It often means we have classes that need one or more other objects when they are instantiated. This often results in chains of objects. For example, new Repository(n…

> new Repository(new SessionFactory(new Configuration())) > Writing that code is pretty painful. If you think you are making things less painful by obfuscating the code snippet above I would challenge you to think about what you are doing. The above is incredibly clear. There is no doubt what is happening and if you screw up the compiler will yell at you. If you obfuscate it through annotations and force readers of y…

> If you obfuscate it through annotations and force readers of your code to try to reason about how the system will behave runtime, you have added exactly zero value. You have only degraded the readability and understandability of the system.

I'd argue a few things here:

1. An IoC container that relies on annotations or XML configuration is not an IoC container that you should be using. Unless you're using an IoC container to help with field configuration, component registration needs to be done through a fluent API so that it's strongly typed and right there in the code where everyone can see it. A well-crafted registration routine should be every bit as readable as the hand-coded factory it replaces, if not more so.

2. Code that's architected in such a way that you need to understand explicit details about the order or manner in which objects are instantiated is code that is not ready to be used with an IoC container. The SOLID principles are a non-negotiable prerequisite of any IoC container. If you haven't drank that Kool-Aid, an IoC container doesn't really have a lot to offer.[1]

3. It's not about making individual snippets of code less painful. It's about making the long-term maintenance of the application - or, for preference, an entire suite of applications - less painful.

1: http://kozmic.net/2012/10/23/ioc-container-solves-a-problem-...

Re: The inverse of IoC is Control

#64

Post by bunderbunder »

MatthewPhillips wrote: post #61
jedbrown wrote: post #21

Earlier quoted context omitted.

Then updates to the customer's configuration requires modifying code, compiling it, and shipping the result. It's easy to put an interface on configuration file modification and in many cases, updates can be applied without needing to restart a running system.

That's the problem with soft-coding, you trick yourself into believing that modifying a configuration file is not modifying code, but it is . It's code that isn't compiled, isn't regression tested. As far as re-shipping, nearly every language nowadays has a method for automatic updates. Here is what Chrome uses: https://code.google.com/p/omaha/

It's absolutely modifying code.

But it's modifying code that your support team is allowed to modify in the field. By contrast, depending on the business policies in place any code that has to go through a compiler might also have to go through meetings, reviews, QA testing, a release cycle, IT department scheduling, acceptance testing, blah blah blah.

Re: The inverse of IoC is Control

#65

Post by skrebbel »

A lot of people in this thread point out that modern IoC containers are good because they can automatically wire up your component tree for you, which is such a hassle to figure out and code manually in a place like main().

This component tree is the core of your application architecture. If the classes are well named, a big part of the application structure should become clear to someone reading your hand-coded main(). Also, if this is such a pain to figure out, why are you using components at all?

I find the idea of splitting functionality into classes but having no clue how these classes relate to one another a tad scary, really. I usually have a picture of the entire component tree on the wall near our team. It's great for pointing at when discussing design, and it's trivial to draw.

Writing a main() really shouldn't be more work than copying that picture into code. A tad tedious, but never more than an hour of work. Why add all that IoC complexity for saving 60 minutes. ? Why replace an excellent starting point for new team members to dive into code by a library that does magic?

Deployment variability doesn't cut it for me. Nearly always, you can foresee which things may need to be variable, and which aren't. Explicitly make those configurable, instead of all classes and their arguments like you'd do in Spring. In your main(), just if or switch over these config settings to instantiate the right class. Again, very readable, and you strongly convey intent to code readers.

Re: The inverse of IoC is Control

#66

Post by jedbrown »

MatthewPhillips wrote: post #61
jedbrown wrote: post #21

Earlier quoted context omitted.

Then updates to the customer's configuration requires modifying code, compiling it, and shipping the result. It's easy to put an interface on configuration file modification and in many cases, updates can be applied without needing to restart a running system.

That's the problem with soft-coding, you trick yourself into believing that modifying a configuration file is not modifying code, but it is . It's code that isn't compiled, isn't regression tested. As far as re-shipping, nearly every language nowadays has a method for automatic updates. Here is what Chrome uses: https://code.google.com/p/omaha/

By this logic, every user is "programming" when they change their facebook account settings or configure the appearance of their desktop. Call it what you want, but configuration via "config files" of some sort (perhaps managed by a GUI) is a totally different beast from modifying 'main'.
Post reply on HN