Hacker News Reader

Comment by orless | Hacker News Reader

"... so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool."

It is the failure of concepts so if the tool brings the right concepts, it helps avoid such design mistakes in the first place.

View on HN

That's too generic statement to be applied to anything. Some specific failures of tools (what exactly?) may be the cause of other issues, but it's not the law of nature. You can hit your finger by a hummer, but it's not because hummer brought the wrong concepts - it served millions of people to build their homes, their farms and fences, it's just because sometimes you miss the nail.

It is only generic if you completely drop the context of the discussion (Spring and dependency injection). My point is that Spring brings DI/IoC concepts which help build healthy projects.

There are so many counter-examples in the world of poorly built projects, that I don't really understand how did you came to this conclusion. DI/IoC is just a pattern, there's no way it could guide you to good architecture itself. Spring is just a tool, which adds some constraints, but which does not force you to make business decisions on scope of different domains or interaction between them that might lead to strong coupling and low modularity.

I'm not sure where I stated that Spring forces "to make business decisions on scope of different domains or interaction between them that might lead to strong coupling and low modularity".

Let me explain in other words. You said: >It is the failure of concepts so if the tool brings the right concepts, it helps avoid such design mistakes in the first place. In the context of Spring/DI it does not make sense, because no matter what, some developers do and will be doing design mistakes related to coupling and modularity and some will write great code, but this is neither feature nor failure of the tool. DI/IoC is too low-level concept to influence application design, because in case of Spring it affects individual classes, not components, namespaces or subsystems. It is the responsibility of the developer to make decisions and create designs that make application modular, designs that restrict number of dependencies etc, and, in general, to do all the work required to avoid creating "giant ball of mud". The result of this work done with Spring or any other IoC/DI framework will not be very different from manual instantiation of objects and wiring.

Reply on news.ycombinator.com