您应该在 Ruby 中使用 private、protected 和 public 修饰符吗？
我有更多的 C# 背景，但在业余时间学习 Ruby。
给定的类，可以将它们的方法设置为私有、公共（默认）或受保护。虽然我了解它们的用法，但 Ruby 代码使用此类修饰符是否很典型，尽管它是一种动态语言，用户可以轻松地覆盖访问权限？
虽然使用像 Send 这样的东西允许用户访问私有方法，但我只是想知道关于 Ruby 和访问修饰符的最佳实践是什么？换句话说，我应该在课堂上使用它们吗？
I come from more of a C# background yet am learning Ruby in my spare time.
Given classes, it is possible to make their methods private, public (default) or protected. While I understand their usage, is it typical for Ruby code to make use of such modifiers, despite being a dynamic language, in which the user can easily override access?
While using something like Send allows the user access to private methods regardless, I was just wondering what the best practice is regarding Ruby and access modifiers? In other words, should I be making use of them in my classes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
它仍然相对常见，因为它传达了意图并最小化了您所公开的界面。需要遵守的一些约定：
只需省略
public，因为除非您另有说明，否则所有方法都是公共的，并且方法通常按访问权限修改进行分组。即使用户可以覆盖访问权限，但这并不意味着他们应该（以同样的方式，您不会看到 C# 开发人员做疯狂的事情，例如将 IL 存根注入类中，以便它们可以访问私有方法）。因此，区分仍然很有用。
受保护的方法比 C# 中的方法要少一些，因为 Ruby 并不真正鼓励将继承作为传递行为的一种方式。通常可以将常见行为重构为模块，然后根据需要进行包含/扩展。
私有方法与 C# 中一样常见； Ruby 通常喜欢使用许多微小的方法来完成非常具体的事情，然后将它们组合在一起以获得有用的东西。但您不会公开这些方法，因为它们不是公共接口的一部分，并且您希望保持其整洁。
因为私有方法不被视为接口的一部分，所以您应该可以自由地更改它们而不受惩罚。通过将它们设置为私有，您可以让其他人注意到这些方法及其实现或定义可能随时更改。
It's still relatively common, because it conveys intent and minimizes the interface you're exposing. Some conventions to observe:
Simply omit the
public, since all methods are public unless you say otherwise, and methods are typically grouped by access modification.Even though a user can override access, that doesn't mean they should (in much the same way, you don't see C# developers doing crazy things like injecting IL stubs into classes so that they can access private methods). So it's still useful to have the distinction.
Protected methods are somewhat rarer than they would be in C#, because Ruby doesn't really encourage inheritance as a means of passing on behavior. Common behavior can often be refactored into
Modules and theninclude/extend-ed as necessary.Private methods are about as common as in C#; Ruby often favors lots of tiny methods that do very specific things, which you then compose together to get something useful. But you don't expose these methods, because they're not part of your public interface and you want to keep that clutter-free.
Because private methods aren't considered part of the interface, you should be free to change them with impunity. By making them private, you've put others on notice that these methods and their implementation or definitions could change at any time.
我一直认为这是关于暴露一个接口。您不希望用户对您的实施感到不知所措，因此您将此类内容设为私有。这对他们比较友善。例如，在处理数组时，您真的想要另外 71 个方法吗（您几乎肯定不关心这些方法？）
私有方法的另一个重要含义是“可能会发生变化”。接口，你必须支持它。你不能在每次下载新版本时都破坏每个人的代码。私有的东西被认为是不稳定的。它们没有公开，因此意味着您可以自由更改它们。如果用户构建的代码依赖于私有方法，那么这不是你的错（假设他们没有这样做，因为你给了他们一个糟糕的接口）。因此，您可以将其设为私有，以便给自己留出空间，以便将来做得更好。
I always figured it was about exposing an interface. You don't want your users to be overwhelmed with your implementation, so you make stuff like that private. It is kinder to them. For example, when dealing with Arrays, do you really want another 71 methods in your way (that you almost certainly don't care about?)
Another important implication of private methods is that of "subject to change" When you commit yourself to an interface, you have to support it. You can't go breaking everyone's code every time they download a new version. Things that are private are understood to be volatile. They aren't exposed, so the implication is that you are free to change them. If users built code that relied on the private methods, then that isn't your fault (assuming they aren't doing it b/c you gave them a crap interface). So you can make it private to give yourself room to make it better in the future.
我仍然会在您的代码中使用它们，因为它向代码阅读器传达了明确的意图，并为您提供了所需的保护。如果另一个开发人员要覆盖您的方法或直接通过 #send 调用它们，他们很可能有充分的理由，或者至少理解为什么他们必须这样做。
在代码中使用 Private/Protected 可以让未来的开发人员更加明确地覆盖你的方法，并且如果没有人覆盖它们，也可以正常工作
I would still use them in your code as it conveys a clear intent to the code reader and also give you the protection you need. If another dev is going to override your methods or call them directly via #send, they most likely either have or good reason or at least understand why they have to do it that way.
Using Private/Protected in your code makes things more explicit to the future dev who is going to override your methods and also works properly for you if no one ever overrides them