Re: IoC & DI в Ruby (Inversion of Control & Dependency Injection)

Я гляжу на это и видится мне такая проблема, общая вообще для
архитектуры приложений, но особо болезненно проявляющаяся в том, что я
увидел.

Когда у тебя в приложении есть четко выделяемый компонент, который
действительно изолирован от окружающих и ты можешь понять, какой ему
нужен API, это хорошо.

Можно даже надеяться, что когда-нибудь за время жизни приложения у
тебя будет больше одной реализации одного интерфейса. Ха-ха!

Вот тут мы подходим к очень болезненному моменту. Повторного
использования кода -- полно. Библиотеки, которые действительно массово
используются есть на всех языках программирования. А вот обобщения API
между разными кусками кода объективно мало.

Но я считаю, что проблема спускания в библиотеку ссылки на какое-то
API -- практически нерешаемая задача. Если и решаемая, то по счастливой
случайности и лишь до того момента, когда потребуется протащить
дополнительные модули, потому что потребовалась новая
функциональность.

Т.е. в реалии получается, что любой уродливый Java проект на половину
забит объявлениями интерфейсов, у которых никогда не будет больше
одной реализации. Более менее хоть что-то хоть как-то получилось с
логгерами (хотя всё равно половина проектов имеют свои логгеры с
обертками над обертками над логгерами). Как грустный пример -- никаких
других примеров для аспектного программирования кроме логгеров обычно
не приводят.

Давай теперь насчёт твоего кода.
Удобно ли когда в любом месте есть logger под рукой? Это не просто
удобно, это очень важно. В ffmpeg например даже запрещено пользоваться
функциями вида puts, надо пользоваться логгером.

Удобно ли пользоваться micon.router. ? Извини, нет, особенно учитывая
что никакого другого роутера не будет. Вот не будет его и всё. А если
чем-то не устраивает текущий, то руби -- не джава. Можно взять и
поправить безболезненным патчем в config/initializers и следующий
программист будет знать, куда посмотреть на предмет всяких хаков,
которые мешают обновлению рельс.

Т.е. в этом и есть проблема IoC под руби. Он создает ненужные проблемы
в и без того непростом метапрограммированном коде рельс и не решает
проблемы, которые находятся уровнем выше, чем выбор инфраструктуры
динамической конфигурации проекта.

Что до меня, то has_many :clients выглядит куда как приятнее, чем
micon.register :client, :scope => :'manager.clients' или как там это
должно быть.

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ

Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru