原因使用私人而不是保护字段和方法(Reasons to use private instead of protected for fields and methods)

原因使用私人而不是保护字段和方法(Reasons to use private instead of protected for fields and methods)

这是一个相当基本的OO问题，但一段时间以来一直困扰着我。

我倾向于避免在我的领域和方法中使用'私人'可见性修饰符来支持protected 。

这是因为，通常，我没有看到隐藏基类和子类之间的实现的任何用法，除非我想为我的类的扩展（即在框架中）设置特定的指导原则。 对于大多数情况，我认为试图限制我的课程如何由我或其他用户扩展是没有好处的。

但是，对于大多数人来说，定义非公开字段/方法时， private修饰符通常是默认选择。

那么，你可以列出private用例吗？ 总是使用私人的主要原因是什么？ 或者你也认为它被过度使用？

This is a rather basic OO question, but one that's been bugging me for some time.

I tend to avoid using the 'private' visibility modifier for my fields and methods in favor of protected.

This is because, generally, I don't see any use in hiding the implementation between base class and child class, except when I want to set specific guidelines for the extension of my classes (i.e. in frameworks). For the majority of cases I think trying to limit how my class will be extended either by me or by other users is not beneficial.

But, for the majority of people, the private modifier is usually the default choice when defining a non-public field/method.

So, can you list use cases for private? Is there a major reason for always using private? Or do you also think it's overused?

最满意答案

有一种共识认为，人们应该更偏好组合而不是 OOP中的继承 。 这有几个原因（谷歌，如果你有兴趣），但主要部分是：

继承很少是最好的工具，并不像其他解决方案那样灵活 受保护的成员/字段形成一个面向你的子类的接口 界面（以及关于他们将来使用的假设）很难正确地获取正确的文档

因此，如果你选择让你的班级继承下来，你应该这样做，并且考虑到所有的优点和缺点。

因此，最好不要让这个类可以继承，而应该通过其他方式确保它尽可能的灵活（不再是）。

这在大型框架中最为明显，因为您的课程使用超出了您的控制范围。 对于你自己的小应用程序，你不会注意到这一点 ，但它（默认继承）会迟早会让你落在后面，如果你不小心。

备择方案

组合意味着您将通过显式（完全抽象）接口（虚拟或基于模板）公开可定制性。

因此，您不需要具有虚拟drive（）函数的Vehicle基类（以及其他所有内容，例如价格的整数等），您将有一个Vehicle类获取Motor接口对象，并且该Motor接口只显示drive（）函数。 现在您可以在任何地方添加和重新使用任何类型的电机（或多或少）。

There is some consensus that one should prefer composition over inheritance in OOP. There are several reasons for this (google if you're interested), but the main part is that:

inheritance is seldom the best tool and is not as flexible as other solutions the protected members/fields form an interface towards your subclasses interfaces (and assumptions about their future use) are tricky to get right and document properly

Therefore, if you choose to make your class inheritable, you should do so conciously and with all the pros and cons in mind.

Hence, it's better not to make the class inheritable and instead make sure it's as flexible as possible (and no more) by using other means.

This is mostly obvious in larger frameworks where your class's usage is beyond your control. For your own little app, you won't notice this as much, but it (inheritance-by-default) will bite you in the behind sooner or later if you're not careful.

Alternatives

Composition means that you'd expose customizability through explicit (fully abstract) interfaces (virtual or template-based).

So, instead of having an Vehicle base class with a virtual drive() function (along with everything else, such as an integer for price, etc.), you'd have a Vehicle class taking a Motor interface object, and that Motor interface only exposes the drive() function. Now you can add and re-use any sort of motor anywhere (more or less. :).