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