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

41–50 of 66 posts

Re: The inverse of IoC is Control

#41

Post by mercurial »

SideburnsOfDoom wrote: post #29
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 s…

That's what Guice does, and newer versions of Spring too (though I'm not sure if you can go full Java and drop the XML entirely).

Re: The inverse of IoC is Control

#42

Post by bjhoops1 »

philbarr wrote: post #12
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…

Exactly, you should really think about when and if you need IoC, just like with any other technique. It can be really useful. Unfortunately, if misused, it can lead to an absolute nightmare. The problem is that when people learn about new techniques then they end up wanting to use those techniques in their next project. It reminds me of something a doctor said to me once, "Every time a new disease is identified there…

Or as a senior developer I know often said, "To the man with a hammer, everything looks like a nail."

Re: The inverse of IoC is Control

#43

Post by michaelochurch »

twistedpair wrote: post #33
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…

Always love all the Java hate on ycomb. I'm not sure how a dynamically code hotswapping Ruby app with 10k classes and 1k domain objects works, but I suspect many of the same patterns emerge as have been solved in Java.

Large single programs should almost never exist. There are exceptions, but the typical bloated business app is not one of them.

Managerial idiots like overambitious single-program IT projects because it makes it easier to allocate "headcount" when the programmer-to-program relationship is inverted (many programmers to one program, instead of the right way, which is one programmer working on many programs).

The truth is that every programming approach fails you when you do this. For one example, static typing fails on versioning issues and compile-speed problems, while dynamic typing ends up with silent failures and integration bugs.

There is one case I can think of where large single programs work, and that's in the database space. You have a lot of requirements (transactional integrity, concurrency, performance in a heterogeneous world) and they all have to work together. It has also taken decades for some of the brightest technical minds out there to get it right.

Re: The inverse of IoC is Control

#44

Post by mercurial »

wcoenen wrote: post #24

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…

Yeah, what you'd end up recreating is a directed graph of dependencies, and make it needlessly fragile.

You don't need the big machinery for smaller projects, though. What I end up doing in Python is having builder methods in __init__.py which can instantiate objects from the package (possibly instantiating objects from sub-packages in the process), with any dependency not in the package or sub-packages being a parameter. You get some granularity in your dependency injection, you avoid magic and you don't need to use the builder methods if you don't want to. It may not scale to large class hierarchies, but for mid-size projects it's fine.

Re: The inverse of IoC is Control

#45

Post by michaelochurch »

wheaties wrote: post #36
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…

Not all of Java culture is like this. There's a ton of really great code out there. Take a look at any Android library. There's no damned Spring anywhere. Or switch to Scala like me.

I agree with you. I don't think there's one Java culture anymore. So what I mean by "Java culture" is POJOs, Factories, Maven, and IDE-dependence. Commodity-developer, large-single-program nonsense that corporations invented to compensate for mediocre engineers. Android is bringing a lot of good engineers into Java, and Scala and Clojure are also bringing a lot of good people into that ecosystem.

I think the issue with the enterprise, large-single-program Java world is that there isn't a feedback cycle. Curious, motivated engineers hate that kind of environment because they want to see things actually work. Clojure and Scala have the REPL, but large-program Java development doesn't.

Re: The inverse of IoC is Control

#46

Post by fusiongyro »

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…

> It's based on the idea that reading code is a lost cause.

I would argue that it is based on the idea that there's going to be too much code to read it all, and that knowing you need to use something shouldn't automatically entail knowing how to create something.

Re: The inverse of IoC is Control

#47

Post by nahname »

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(new SessionFactory(new Configuration()))
Writing that code is pretty painful. Rather than dealing with long chains of dependencies, manually wiring everything up. You define mappings and let an IoC container do it for you.

Why not just wire everything up manually in static functions and be done with it? It is really hard to change static code and often impossible to test it in a language like Java/C#. There is almost nothing you can do to test a piece of code that calls out to User.find(1) in one of it's methods.

Why are there no IoC practices in ruby? Primarily because the second point is no longer true (you can test everything easily). I still think there is merit in knowing the dependency chain rather than just calling User.find(1) and hoping that something somewhere conjures up a database connection and configures everything correctly, at the correct time.

IoC is control and automation. Those are both powerful tools to any programmer.

Re: The inverse of IoC is Control

#48

Post by bborud »

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 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.

A little extra typing never killed anyone.

Re: The inverse of IoC is Control

#49

Post by netghost »

twistedpair wrote: post #33
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…

Always love all the Java hate on ycomb. I'm not sure how a dynamically code hotswapping Ruby app with 10k classes and 1k domain objects works, but I suspect many of the same patterns emerge as have been solved in Java.

In languages like ruby, python, and probably to some degree go, you tend not to need as many classes. Things like Factories, Adaptors, and Proxies tend to disappear or become pretty trivial.

Eventually programs written in these languages can grow huge, but it takes longer, and the preference tends to then be to break a program down into smaller libraries (gems, eggs, etc.) and separate applications that communicate with each other.

Re: The inverse of IoC is Control

#50

Post by twistedpair »

michaelochurch wrote: post #43
twistedpair wrote: post #33

Earlier quoted context omitted.

Always love all the Java hate on ycomb. I'm not sure how a dynamically code hotswapping Ruby app with 10k classes and 1k domain objects works, but I suspect many of the same patterns emerge as have been solved in Java.

Large single programs should almost never exist. There are exceptions, but the typical bloated business app is not one of them. Managerial idiots like overambitious single-program IT projects because it makes it easier to allocate "headcount" when the programmer-to-program relationship is inverted (many programmers to one program, instead of the right way, which is one programmer working on many programs). The truth…

WADR, most enterprise billing, invoicing and accounting systems are also such cases where it is not desirable or practical to sprinkle the business logic across dozens of silos.
Post reply on HN