Хм, это был как раз пример нестандартного доступа, обычно
используется
вот так:
class App
inject router: :router
def do
router.do_something
end
end
Если так тоже неудобно, то хотелось бы пример - как удобно.
> Т.е. в реалии получается, что любой уродливый Java проект на половину
> забит объявлениями интерфейсов, у которых никогда не будет больше
> одной реализации.
...
> Удобно ли пользоваться micon.router. ? Извини, нет, особенно учитывая
> что никакого другого роутера не будет. Вот не будет его и всё. А если
> чем-то не устраивает текущий, то руби -- не джава. Можно взять и
> поправить безболезненным патчем в config/initializers
1. У меня впечатление что ты концентрирушся на возможности быстрой
смены компонентов, это да, одно из преимуществ IoC, но для меня лично
это второстепенно, и не важно, как ты верно отметил - руби и так
позволяет легко это делать использую метапрограммиг и duck-typing.
Гораздо важнее другое - управление зависимостями.
Вот пример реального роутера https://github.com/alexeypetrushin/rad_core/blob/master/lib/components/router.rb
(там всего пара строчек), там видно что у роутера стоит 2 зависимости,
это позволяет легко контролировать зависимости и делать ленивую
загрузку приложения.
Можно возразить "require делает то-же самое" - нет, когда я ставлю в
зависимость компонент (у этого роутера в дереве зависимостей
есть :environment), то это означает не просто
загрузить класс Environment, а загрузить и сконфигурировать используя
конфиг продакшена.
Например компонент :models (не отдельная модель, а сам фреймворк
моделей) во время инициализации читает конфигурацию базы и выполняет
подключение.
Т.е. для того чтобы использовать компонент мне вообще абсолютно ничего
не нужно знать о нем кроме его имени.
Ни где он находится, ни из каких файлов состоит, ни как правильно и в
какой последдосательности его инициализировать, ни где его конфиги,
никак мержить конфиги по умолчанию с продакшен конфигами, ни его
зависимости (такие-же сложные компоненты).
И я могу свободно изменить любой из этих параметров, и никто из
модулей зависимых от этого компонента ничего об этом не узнает.
Т.е. получается просто отличное инкапсулирование и независимость -
просто обьяви какие компоненты тебе нужны - и они сами автоматически
появятся в нужное время.
2. Чуть подробней про конфиги, там еще есть такой файл
https://github.com/alexeypetrushin/rad_core/blob/master/lib/components/router.yml
И если мне вздумается перегрузить эти настройки - достаточно просто
поместить с таким-же названием и нужной строчкой в продакшен-пути -
они будут смержены.
Т.е. любая из настроек любого из компонентов приложения может быть
легко перегружена таким способом. И не нужно читать документацию и
помнить как именно настраивается тот или иной компонент - все они
настраиваются одинаково.
Там кстати есть еще одна проблема которую сразу не видно, и которая
собственно и вынудила меня разрезать один конфиг на множество -
компоненты инициализируются в определенном порядке, и когда весь
конфиг в одном файле - то очень сложно мержить и перегружать
настройки. А так все тривиально.
> Что до меня, то has_many :clients выглядит куда как приятнее, чем
> micon.register :client, :scope => :'manager.clients' или как там это
> должно быть.
Хм, это вообще никак не связано, совершенно из другой области.
Описание связей между моделями никак не относится к IoC.
Что именно навело на такую мысль, что-то в описаниии примера? Если
так, что именно? (я тогда поправлю описание чтобы было более понятно).
> Как говорится если у вас есть проблема и вы решили решить ее с помощью Java,
> то у вас появится еще AbstractProblem и FactoryProblem.
Я привел пример Java для того чтобы было понятно откуда на мой взгляд
идет предвзятое отношение и своеобразное восприятие IoC.
И наоборот имел ввиду что нельзя брать и использовать техники Java
напрямую, потому что они не подходят к Ruby.
Добавляется всего 3 понятия:
- register(component)
- inject(component) / micon.component
- путь к папке конфигов и компонентов 'lib/components'
- activate(scope) не в счет, он черезвычайно редко используется, и
только в очень низкоуровневой логике.
Что имеется ввиду конкретно в данном случае? Где фэктори, сложности, и
т.д.?
Кстати, забыл упомянуть - получается6 что расходов и сложностей
собственно и нет, вы почти не несете никаких дополнительных расходов
(за исключением необходимости помнить эти 3 метода и помещать
обьявления компонентов в папку lib/components)
П.С.
Хм завтра ради интереса сделаю второй пример без IoC и посчитаю число
символов.
--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "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
Комментариев нет:
Отправить комментарий