Почему в Ruby on Rails Devise или Restful Authentication не создают пространство имен для лучшей инкапсуляции?

Question

Кажется, что Restful Authentication и Devise оба используют

current_user
user_signed_in?    (or logged_in?)
self.current_user = ...   (for Restful Authentication)

как «интерфейс» для драгоценного камня. Интересно, почему ни один модуль или класс не используется, чтобы дать ему пространство имен, такое как:

Auth.current_user
Auth.set_current_user

или

Devise.current_user

На самом деле, я сначала немного испугался, обнаружив, что Restful Authentication «смешивает» все, и в документах даже не упоминается «Интерфейс» - не является ли интерфейс одним из самых важных элементов в объектно-ориентированном программирование, что все заключено в капсулу и что интерфейс - это все, что нужно пользователю? Иногда я не вижу никаких документов по интерфейсу, например, по Facebooker или Facebooker2, и если запрашивается краткое описание API, ответом может быть «прочитать код». Мой друг, может быть 5 драгоценных камней (1 драгоценный камень и 4 драгоценных камня, от которых это зависит) и как минимум 40 файлов. Это полностью нарушает основополагающие принципы объектно-ориентированного программирования?

Возвращаясь к первоначальному вопросу, не могут ли Restful Authentication и Devise использовать пространство имен и лучше определять интерфейс? Если это смешать во всех именах (включая имена переменных экземпляра), не будет ли это загрязнять класс Controller? (большая работа выполняется в различных классах контроллеров, поэтому загрязнение пространства имен там почти так же плохо, как загрязнение глобального пространства имен).

Answer 1

Это одна из тех вещей, где нет правильного ответа. Когда вы смешиваете в devise, он добавляет около 4 методов в actioncontroller, эти методы документированы, и вы должны прочитать документацию перед использованием любой библиотеки. По сути, это «интерфейс» для драгоценного камня. Все по-прежнему заключено в модуле, единственное отличие состоит в том, что ActiveRecord ни к чему не причастен, библиотека Devise - это та, которая выполняет интеграцию. Кроме того, людям, которые занимаются разработкой устройства, для написания интеграции нужно писать меньше и меньше кода, а вам, как пользователю, не нужно писать столько кода для его использования.

Теперь, теоретически, это ЗОМГ, КОТОРЫЙ УПАЕТ! тип ситуации. В действительности, очень редко вещи разрушают другие вещи, если они выполняются правильно (т.е. инкапсулируют все в миксине, переопределяют метод, не забудьте вызвать super). Даже когда вы сталкиваетесь с этими типами проблем, (после первого раза) обычно очень легко понять, что происходит. Это в основном другая форма наследования, которая является одной из основополагающих концепций ООП.

Подобные действия также позволяют библиотекам добавлять функции в другие библиотеки или даже в основной язык. Это позволяет изящно решать действительно сложные ситуативные проблемы. Это также означает, что состояние языка движется вперед НАМНОГО быстрее, чем если вам придется ждать, пока какая-либо новая функция будет запущена, прежде чем вы сможете ее использовать, и позволяет кросс-версионному кодированию быть довольно элегантным с помощью полифиллов. Я думаю, что это одна из лучших функций в любом языке, которая его реализует, и работа на более ограничительных языках представляет собой реальную боль, потому что вы чувствуете, что у вас на плече маленький полицейский, который говорит вам, что вы не ' t достаточно умен, чтобы использовать мощные языковые функции для решения ваших проблем.

Теперь, если вы скажете: "ООП - это беспорядок, и у нас не должно быть неприятного типа связи, введенного наследованием", я бы полностью с вами согласился. Но это другое обсуждение:)

Answer 2

что вы подразумеваете под основанием принципов объектно-ориентированного программирования? как использовать 2 конфликтующих драгоценных камня в вашем проекте?

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

Общая идея, что ruby ​​открыт для внесения исправлений обезьянами и изменения классов во время выполнения, - разработчики не глупы и не захотят делать вещи, которые нарушают их проект.