Здравствуйте, Тёмчик, Вы писали:

Тё>IoC — про декларативное описание зависимостей. Что куда более явное, чем простыни говнокода ручной инициализации.

Задумайся о том, откуда у тебя столько зависимостей, что тебе нужен аж целый фреймворк для их инициализации и декларативное описание? Это просто как бы красивый способ спрятать кривой дизайн, который был популярен во времена монолитных монстров. Я допускаю что в корпоративной Java и сейчас так пишут, конечно.

KP>>Любовь джавистов наплодить абстркций и конфигураций ради самого процесса, а не результата, мне всегда казалось странной
Тё>Результат — чистый, поддерживаемый, расширяемый код.

Нет, в результате у тебя есть гора абстракций и вечно тормозящее приложение, а не "чистый, поддерживаемый, расширяемый код"

Здравствуйте, Тёмчик, Вы писали:

Тё>IoC — про декларативное описание зависимостей. Что куда более явное, чем простыни говнокода ручной инициализации.

Задумайся о том, откуда у тебя столько зависимостей, что тебе нужен аж целый фреймворк для их инициализации и декларативное описание? Это просто как бы красивый способ спрятать кривой дизайн, который был популярен во времена монолитных монстров. Я допускаю что в корпоративной Java и сейчас так пишут, конечно.

Тё> Inheritance vs Composition. IoC- про composition.

IoC про интерфейсы, вообще-то, но вот наследование и реализация интерфейса не совсем одно и то же. Да, это одно и то же в мире C++, но даже в Java это не так.

KP>>Любовь джавистов наплодить абстркций и конфигураций ради самого процесса, а не результата, мне всегда казалось странной
Тё>Результат — чистый, поддерживаемый, расширяемый код.

Нет, в результате у тебя есть гора абстракций и вечно тормозящее приложение, а не "чистый, поддерживаемый, расширяемый код"