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

21–30 of 66 posts

Re: The inverse of IoC is Control

#21

Post by jedbrown »

MatthewPhillips wrote: post #15
roam wrote: post #5

Don't use IoC if you don't need it, but I'll explain why we need it in our case: some customers require different implementations. That's where the DI part comes from -- to enable us to load a different dependency based on the customer. Now, you could provide a different bootstrapper class per customer or start building a mega class with a lot of ifs-and-buts(elses), or you specify this kind of stuff in a configurati…

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.

Re: The inverse of IoC is Control

#22

Post by nkohari »

zupatol wrote: post #8
roam wrote: post #5

Don't use IoC if you don't need it, but I'll explain why we need it in our case: some customers require different implementations. That's where the DI part comes from -- to enable us to load a different dependency based on the customer. Now, you could provide a different bootstrapper class per customer or start building a mega class with a lot of ifs-and-buts(elses), or you specify this kind of stuff in a configurati…

I agree with using IoC for different implementations, but I'm puzzled by those who want to use it everywhere, because it supposedly makes the code easier to test. Guice is a nice IoC framework, but look at what they say on their website: "Think of Guice's @Inject as the new new." http://code.google.com/p/google-guice/

Testing is kind of a side effect. When you design your code with IoC in mind, you naturally will create more logical separations and avoid tight coupling -- which in turn will make your code easier to test. (Source: I wrote Ninject. :)

Re: The inverse of IoC is Control

#23

Post by martinced »

IoC is an usual technique and buzzword from the C#/Java + XML + ORM + SQL hell.

There are many programmers working in the Real-World [TM], powering great apps and webapps, using saner technologies who have never heard of the term.

I wrote my own IoC container (a clone of picocontainer IIRC) to see what the fuss was about when the term started to become fashionable. No big deal. It can help reproduce various states (for examples in testing environments) to more easily test your app.

Sure people will say: "You need an IoC container to do DI, what you're talking about is DI, not IoC".

But, fundamentally, it is once again related to "state" and the difficulty to recreate a state in {dev,pre-prod,prod,whatever}.

So it's once again a "solution" missing the bigger picture.

Sure, people stuck in the "stateful OO" mindset will love IoC and, honestly, if you're stuck in such an hell IoC can be useful. With the caveat that IoC makes it much harder to reason about what's going on when some shit hits the fan.

"Every problem can be solved with another layer of abstraction, except the problem of too many layers of abstraction"

But there's light at the end of the tunnel. There are other ways to design great apps.

And to make you feel even better: being "smart" as nothing to do with knowing every technology out there ; )

Re: The inverse of IoC is Control

#24

Post by wcoenen »

It turns out that there is a problem with instantiating everything manually in main if you have a lot of components: it becomes non-trivial to figure out the order of instantiation.

This problem will typically surface whenever you add a dependency between existing components. If the dependency is currently instantiated after the changed component, it will have to be moved up so it is instantiated earlier. But then it turns out the dependencies of that component also need to be moved up etc.

To deal with this you then have to calculate a "dependency rank" for each component (i.e. 0 for components without dependencies, and x+1 for components where the max rank among the dependencies is x) just to figure out a new order that works.

This problem doesn't exist if you use a dependency injection container with configuration in code, because the order of component registration is not important.

Re: The inverse of IoC is Control

#25

Post by michaelochurch »

Java culture (IDE-dependence, AbstractFactoryVisitorFactory patterns, Maven and XML monstrosities) is hideous. It's based on the idea that reading code is a lost cause. You can no longer trust code, so you need all these wonky tool configurations to compensate for the fact that you're trying to make an army of inept programmers build something that is (unless it fails) going to become the next generation's legacy bloatbomb.

Re: The inverse of IoC is Control

#27

Post by RyanZAG »

_pmf_ wrote: post #16
RyanZAG wrote: post #14

Earlier quoted context omitted.

Just curious, but what's wrong with recompiling? If you make a typo in your Rhino file on production, your whole app is now failing. Surely it makes more sense to just take the 5 minutes to recompile (or hopefully 30 minutes and test it out in dev first)? I don't really understand what problem using the dynamic language is trying to solve there, and you've just added in a whole new branch of different code that won't…

In my case, I have an Eclipse-based product (toolchain for embedded development) that must be reconfigured per client or even per project (on site); i.e. it is more about dynamically creating very specific variants of a product. Using client/project-specific plugins would be the alternative for me, but this has much more overhead.

Are you not packaging un-used code into your embedded binaries then? You'd also have to manually test the reconfigured client before deploying it, I think.

Seems better to make an automated build system off a database of configurations - a simple sql table with the different settings that could automatically build versions for all clients. You'd get static compile time checking of each build, and it would allow for easily running automated tests against each client's version.

So you'd end up with no un-used code, a database of client configuations, and static compile time checking. Seems win-win.

Sorry for 'assuming your problems', feel free to ignore. Interesting situation though.

Re: The inverse of IoC is Control

#28

Post by tkellogg »

Maybe you should be using C#. As a community we fight hard to reject xml configuration, favoring type safe lambda expressions instead. Anything that ignores the type safe guarantees that C# offers quickly does. There was briefly a spring.net but it quickly died for this reason.

Re: The inverse of IoC is Control

#29

Post by SideburnsOfDoom »

tkellogg wrote: post #28

Maybe you should be using C#. As a community we fight hard to reject xml configuration, favoring type safe lambda expressions instead. Anything that ignores the type safe guarantees that C# offers quickly does. There was briefly a spring.net but it quickly died for this reason.

Agreed. Is the author's problem with IoC or with XML config? hard to tell, but they're really not the same thing.

IoC containers in C# have rejected config in XML, in favour of config in code, using either generics and lambdas (e.g. register Component.For.ImplementedBy ) or via scanning (e.g. AllTypes.FromAssembly(x).BasedOn().WithService.FirstInterface() ).

Spring.net was an exception and in comparison it really sucked.

IoC Config in code is much better. But can't this be done in java too?

Re: The inverse of IoC is Control

#30

Post by factorialboy »

michaelochurch wrote: post #25

Java culture (IDE-dependence, AbstractFactoryVisitorFactory patterns, Maven and XML monstrosities) is hideous. It's based on the idea that reading code is a lost cause. You can no longer trust code, so you need all these wonky tool configurations to compensate for the fact that you're trying to make an army of inept programmers build something that is (unless it fails) going to become the next generation's legacy blo…

In our defense, have you tried reading Java code?
Post reply on HN