Сообщение Re[11]: О "наивном" DI и об архитектурном бессилии от 22.09.2016 13:22
Изменено 22.09.2016 13:24 IQuerist
Здравствуйте, ·, Вы писали:
Полный сарказма ответ:
J>>·>И какой тут смысл создавать инстанс UserService? Чем UserService.Save со статическим методом хуже?
J>>Вообщем-то можно и статические методы исспользовать.
·>Зачем тогда классы вообще существуют?..
Чтобы упрощать структуру кода, там где это может быть полезно... не?
J>>·>Т.е. у тебя все зависимости будут синглтонами. Правильно понял? Жуть же. Типичный спагетти-код и радости дебага правильности порядка инициализации синглтонов.
J>>Есть такое.
·>И ещё получается такой некий твой "class Settigs", который зависит от всего и все от него зависят.
·>Собственно IoC-контейнер позволяет этим хоть как-то рулить. Синглтоны однозначно в топку.
Старая история, IoC-контейнер выполняет роль статического конструктора, но адепты верят, что так они чем-то по особенному рулят.
J>>·>Почему редко такой код встречается?..
J>>А если в классе UserService в методе Save для бизнес логики надо исспользовать разные *Managers,
J>>а в методе Delete еще более разные(UserProfileManager, AcitvityManager и т.д.).
J>>Передавать в UserService(FabricOfManagers fabric) — фабрику классов со всеми менеджерами?
·>Нет. Просто передаёшь всех менеджеров в конструкторе.
·>UserService(UserProfileManager, AcitvityManager, SomethingManager, ...)
·>Да, конструктор _может_ получиться с тучей аргументов, но зато сразу видно что именно требуется для функционирования данного класса, тебе не нужно читать код каждого отдельного метода чтобы выяснить а что же этот конкретный метод в этой ветке if-условия решил вытянуть из глобального Context.Current.
Это иллюзия, код каждого конкретного метода читать все равно придется
·>И, более того, это всё проверяется на этапе компиляции, все зависимости обеспечены, плюс IDE помогает с навигацией по коду, find usages, go to declaration и прочим.
А все остальные способы создания сервисов в коде на этапе компиляции не проверяются, зависимости не обеспечивают, а IDE будет намеренно мешать навигации по коду!
·>Далее, если у тебя таки получается класс у которого очень много зависимостей это сразу явно видно по его конструктору. Это просто значит что данный класс превращается в Универсальный Всемогутор (https://en.wikipedia.org/wiki/God_object) и требуется рефакторинг: пилишь компоненты по зависимостям так, чтобы уменьшить максимальную валентность графа зависимостей.
Какая красота, люди ведь не замечают, что полдня работают с одним файлом кол-во строк которого перевалило за несколько тыс. И что простой найти метод без средств студии уже нереально А так — глянул конструктор и все понятно А то, что всю эту сервисную обвязку при рефакторинге придется переносить во все зависимые классы. Ну это фигня не упаримся. Нам работу компилятора выполнять не в тягость!
Полный сарказма ответ:
J>>·>И какой тут смысл создавать инстанс UserService? Чем UserService.Save со статическим методом хуже?
J>>Вообщем-то можно и статические методы исспользовать.
·>Зачем тогда классы вообще существуют?..
Чтобы упрощать структуру кода, там где это может быть полезно... не?
J>>·>Т.е. у тебя все зависимости будут синглтонами. Правильно понял? Жуть же. Типичный спагетти-код и радости дебага правильности порядка инициализации синглтонов.
J>>Есть такое.
·>И ещё получается такой некий твой "class Settigs", который зависит от всего и все от него зависят.
·>Собственно IoC-контейнер позволяет этим хоть как-то рулить. Синглтоны однозначно в топку.
Старая история, IoC-контейнер выполняет роль статического конструктора, но адепты верят, что так они чем-то по особенному рулят.J>>·>Почему редко такой код встречается?..
J>>А если в классе UserService в методе Save для бизнес логики надо исспользовать разные *Managers,
J>>а в методе Delete еще более разные(UserProfileManager, AcitvityManager и т.д.).
J>>Передавать в UserService(FabricOfManagers fabric) — фабрику классов со всеми менеджерами?
·>Нет. Просто передаёшь всех менеджеров в конструкторе.
·>UserService(UserProfileManager, AcitvityManager, SomethingManager, ...)
·>Да, конструктор _может_ получиться с тучей аргументов, но зато сразу видно что именно требуется для функционирования данного класса, тебе не нужно читать код каждого отдельного метода чтобы выяснить а что же этот конкретный метод в этой ветке if-условия решил вытянуть из глобального Context.Current.
Это иллюзия, код каждого конкретного метода читать все равно придется
·>И, более того, это всё проверяется на этапе компиляции, все зависимости обеспечены, плюс IDE помогает с навигацией по коду, find usages, go to declaration и прочим.
А все остальные способы создания сервисов в коде на этапе компиляции не проверяются, зависимости не обеспечивают, а IDE будет намеренно мешать навигации по коду!
·>Далее, если у тебя таки получается класс у которого очень много зависимостей это сразу явно видно по его конструктору. Это просто значит что данный класс превращается в Универсальный Всемогутор (https://en.wikipedia.org/wiki/God_object) и требуется рефакторинг: пилишь компоненты по зависимостям так, чтобы уменьшить максимальную валентность графа зависимостей.
Какая красота, люди ведь не замечают, что полдня работают с одним файлом кол-во строк которого перевалило за несколько тыс. И что простой найти метод без средств студии уже нереально
А так — глянул конструктор и все понятно А то, что всю эту сервисную обвязку при рефакторинге придется переносить во все зависимые классы. Ну это фигня не упаримся. Нам работу компилятора выполнять не в тягость!Re[11]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, ·, Вы писали:
Полный сарказма ответ:
J>>·>И какой тут смысл создавать инстанс UserService? Чем UserService.Save со статическим методом хуже?
J>>Вообщем-то можно и статические методы исспользовать.
·>Зачем тогда классы вообще существуют?..
Чтобы упрощать структуру кода, там где это может быть полезно... не?
J>>·>Т.е. у тебя все зависимости будут синглтонами. Правильно понял? Жуть же. Типичный спагетти-код и радости дебага правильности порядка инициализации синглтонов.
J>>Есть такое.
·>И ещё получается такой некий твой "class Settigs", который зависит от всего и все от него зависят.
·>Собственно IoC-контейнер позволяет этим хоть как-то рулить. Синглтоны однозначно в топку.
Старая история, IoC-контейнер выполняет роль статического конструктора, но адепты верят, что так они чем-то по особенному рулят.
J>>·>Почему редко такой код встречается?..
J>>А если в классе UserService в методе Save для бизнес логики надо исспользовать разные *Managers,
J>>а в методе Delete еще более разные(UserProfileManager, AcitvityManager и т.д.).
J>>Передавать в UserService(FabricOfManagers fabric) — фабрику классов со всеми менеджерами?
·>Нет. Просто передаёшь всех менеджеров в конструкторе.
·>UserService(UserProfileManager, AcitvityManager, SomethingManager, ...)
·>Да, конструктор _может_ получиться с тучей аргументов, но зато сразу видно что именно требуется для функционирования данного класса, тебе не нужно читать код каждого отдельного метода чтобы выяснить а что же этот конкретный метод в этой ветке if-условия решил вытянуть из глобального Context.Current.
Это иллюзия, код каждого конкретного метода читать все равно придется
·>И, более того, это всё проверяется на этапе компиляции, все зависимости обеспечены, плюс IDE помогает с навигацией по коду, find usages, go to declaration и прочим.
А все остальные способы создания сервисов в коде на этапе компиляции не проверяются, зависимости не обеспечивают, а IDE будет намеренно мешать навигации по коду!
·>Далее, если у тебя таки получается класс у которого очень много зависимостей это сразу явно видно по его конструктору. Это просто значит что данный класс превращается в Универсальный Всемогутор (https://en.wikipedia.org/wiki/God_object) и требуется рефакторинг: пилишь компоненты по зависимостям так, чтобы уменьшить максимальную валентность графа зависимостей.
Какая красота, люди ведь не замечают, что полдня работают с одним файлом кол-во строк которого перевалило за несколько тыс. И что найти метод без средств студии уже просто нереально А так — глянул конструктор и все понятно А то, что всю эту сервисную обвязку при рефакторинге скорее всего придется переносить во новые классы. Ну это фигня не упаримся. Нам работу компилятора выполнять не в тягость!
Полный сарказма ответ:
J>>·>И какой тут смысл создавать инстанс UserService? Чем UserService.Save со статическим методом хуже?
J>>Вообщем-то можно и статические методы исспользовать.
·>Зачем тогда классы вообще существуют?..
Чтобы упрощать структуру кода, там где это может быть полезно... не?
J>>·>Т.е. у тебя все зависимости будут синглтонами. Правильно понял? Жуть же. Типичный спагетти-код и радости дебага правильности порядка инициализации синглтонов.
J>>Есть такое.
·>И ещё получается такой некий твой "class Settigs", который зависит от всего и все от него зависят.
·>Собственно IoC-контейнер позволяет этим хоть как-то рулить. Синглтоны однозначно в топку.
Старая история, IoC-контейнер выполняет роль статического конструктора, но адепты верят, что так они чем-то по особенному рулят.J>>·>Почему редко такой код встречается?..
J>>А если в классе UserService в методе Save для бизнес логики надо исспользовать разные *Managers,
J>>а в методе Delete еще более разные(UserProfileManager, AcitvityManager и т.д.).
J>>Передавать в UserService(FabricOfManagers fabric) — фабрику классов со всеми менеджерами?
·>Нет. Просто передаёшь всех менеджеров в конструкторе.
·>UserService(UserProfileManager, AcitvityManager, SomethingManager, ...)
·>Да, конструктор _может_ получиться с тучей аргументов, но зато сразу видно что именно требуется для функционирования данного класса, тебе не нужно читать код каждого отдельного метода чтобы выяснить а что же этот конкретный метод в этой ветке if-условия решил вытянуть из глобального Context.Current.
Это иллюзия, код каждого конкретного метода читать все равно придется
·>И, более того, это всё проверяется на этапе компиляции, все зависимости обеспечены, плюс IDE помогает с навигацией по коду, find usages, go to declaration и прочим.
А все остальные способы создания сервисов в коде на этапе компиляции не проверяются, зависимости не обеспечивают, а IDE будет намеренно мешать навигации по коду!
·>Далее, если у тебя таки получается класс у которого очень много зависимостей это сразу явно видно по его конструктору. Это просто значит что данный класс превращается в Универсальный Всемогутор (https://en.wikipedia.org/wiki/God_object) и требуется рефакторинг: пилишь компоненты по зависимостям так, чтобы уменьшить максимальную валентность графа зависимостей.
Какая красота, люди ведь не замечают, что полдня работают с одним файлом кол-во строк которого перевалило за несколько тыс. И что найти метод без средств студии уже просто нереально
А так — глянул конструктор и все понятно А то, что всю эту сервисную обвязку при рефакторинге скорее всего придется переносить во новые классы. Ну это фигня не упаримся. Нам работу компилятора выполнять не в тягость!