4 ms·

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

by orless 9y ago

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

ivan_gammel 9y ago
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.
- orless 9y ago
  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.
  - ivan_gammel 9y ago
    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.
    - orless 9y ago
      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".
      - ivan_gammel 9y ago
        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.

by orless 9y ago

ivan_gammel 9y ago

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.

orless 9y ago
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.
- ivan_gammel 9y ago
  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.
  - orless 9y ago
    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".
    - ivan_gammel 9y ago
      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.