在 Ruby on Rails 中，为什么 Devise 或 Restful Authentication 不创建命名空间以实现更好的封装？
看来 Restful Authentication 和 Devise 都用作
current_user
user_signed_in? (or logged_in?)
self.current_user = ... (for Restful Authentication)
gem 的“接口”。我想知道为什么没有使用模块或类来给它命名空间，例如：
Auth.current_user
Auth.set_current_user
或
Devise.current_user
事实上，一开始我有点震惊地发现 Restful Authentication“混合”了所有内容，并且文档甚至没有提到“接口” “——接口不是面向对象编程中最重要的东西之一吗？一切都被封装起来，接口就是用户需要关心的一切？有时，我看不到任何接口文档，例如 Facebooker 或 Facebooker2，如果请求 API 的简要描述，响应可以是“阅读代码”。可以有 5 个宝石（1 个宝石和 4 个宝石取决于它）和至少 40 个文件，我的朋友。这是否完全违反了面向对象编程的基本原则？
回到最初的问题，Restful Authentication 和 Devise 不能使用命名空间并定义接口更好吗？如果它混合了所有名称（包括实例变量名称），是否会污染 Controller 类？ （很多工作是在各种控制器类中完成的，因此污染命名空间几乎与污染全局命名空间一样糟糕）。
It seems that Restful Authentication and Devise both use
current_user
user_signed_in? (or logged_in?)
self.current_user = ... (for Restful Authentication)
as the "interface" to the gem. I wonder why no module or class is used to give it a namespace, such as:
Auth.current_user
Auth.set_current_user
or
Devise.current_user
In fact, I was a bit horrified at first to find Restful Authentication "mix in" everything, and the docs doesn't even mention an "Interface" -- isn't interface one of the most important thing in object oriented programming, that everything is encapsulated and that the interface is all the user needs to care about? Sometimes, I don't see any docs for interface, such as for Facebooker or Facebooker2, and if requesting a brief description of the API, the response can be "read the code". There can be 5 gems (1 gem and 4 gems it depends on) and at least 40 files, my friend. Does this totally violate the founding principles of object oriented programming?
Back to the original question, can't Restful Authentication and Devise use a namespace and define the interface better? If it mix in all the names, (including instance variable names), won't that contaminate the Controller class? (a lot of work is done in the various controller classes, so contaminating the namespace there is almost as bad as contaminating the global namespace).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是没有正确答案的事情之一。当你混合设计时，它会向actioncontroller添加大约4个方法，这些方法都有文档记录，你应该在使用任何库之前阅读文档。基本上，这就是 gem 的“接口”。所有内容仍然封装在模块中，唯一的区别是 ActiveRecord 不购买任何内容，Devise 库是进行集成的库。此外，维护设备的人员需要编写更少、更不复杂的代码来进行集成，并且作为用户，您不需要编写那么多的代码来使用它。
现在，从理论上讲，这是 ZOMG 天塌下来了！！情况类型。事实上，很少有事情会压倒其他事情，只要它们做得正确（即将所有内容封装在 mixin 中，重写方法，记住调用 super）。即使您确实遇到了这些类型的问题（在第一次之后），通常也很容易弄清楚发生了什么。它基本上是一种不同形式的继承，这是 OOP 的基本概念之一。
以这种方式进行操作还允许库向其他库甚至核心语言添加功能。这可以为真正棘手的情境问题提供优雅的解决方案。这也意味着，如果您必须等待任何新功能推出才能使用它，那么该语言的状态向前发展的速度要快得多，并且允许通过polyfills 使跨版本编码变得相当优雅。我认为它是任何实现它的语言中最好的功能之一，并且发现在限制性更强的语言中工作是一种真正的痛苦，因为它，你感觉就像有一个小警察站在你的肩膀上告诉你，你不是'不够聪明，无法使用强大的语言功能来解决您的问题。
现在，如果你说“OOP 是一团糟，我们一开始就不应该有继承引入的令人讨厌的耦合类型”，我完全同意你的观点。但这是一个不同的讨论:)
That is one of those things where there isn't a correct answer. When you mix in devise, it adds about 4 methods to actioncontroller, those methods are documented, and you should read the documentation before using any library. Basically, that is the "interface" to the gem. Everything is still encapsulated in the module, the only difference is that ActiveRecord isn't buying in to anything, the Devise library is the one doing the integration. Also, the people who are maintaining devise need to write less, and less complected code to do the integration, and you as the user don't need to write as much code to use it.
Now, in theory this is a ZOMG THE SKY IS FALLING!! type of situation. In reality, it is very rare that things crush other things, so long as they are done properly (i.e. encapsulate everything in a mixin, override the method, remember to call super). Even when you do run into these types of issues, (after the first time) it is usually really easy to figure out what is going on. It is basically a different form of inheritance, which is one of the foundational concepts of OOP.
Doing things this way also allows libraries to add features to other libraries, or even the core language. This allows for elegant solutions to really tough, situational problems. It also means that the state of the language moves forward MUCH faster then if you have to wait for any new feature to get pushed out before you can use it, and allows for cross version coding to be quite elegant through polyfills. I think it is one of the best features in any language that implements it, and find working in more restrictive languages to be a real pain because of it, you feel like you have a little police man on your shoulder telling you that you aren't smart enough to use powerful language features to solve your problems.
Now, if you say "OOP is a mess and we shouldn't have the nasty type of coupling introduced by inheritance in the first place" I would totally agree with you. But that is a different discussion :)
面向对象编程的基本原则是什么意思？喜欢在你的项目中使用 2 个相互冲突的 gem？
回答你的问题 - 要求用户输入不必要的代码是没有意义的，这两个宝石本质上是在做同样的事情，只是不同，所以真正的问题是 - 为什么你想同时使用它们？
ruby 在运行时对猴子修补和更改类开放的总体想法是 - 开发人员并不愚蠢，也不想做破坏他们项目的事情。
what do you mean by founding principles of object oriented programming? like using 2 conflicting gems in your project?
answering your question - there is no point in asking user to type more code than necessary, these 2 gems are essentially doing the same thing, just differently so real question is - why would you want to use them both?
general idea with ruby being open to monkey patching and changing classes at runtime is - developers are not stupid and will not want to do stuff that breaks their project.