Private methods and properties

Question

Programming

When should one prefer to use private instead of protedted for methods and properties of a class?
Private completely deprives us of the ability to extend the class - which, in my opinion, is not logical.
Does anyone have any ideas or maybe someone already knows the answer?

Answer 1

The scope of a method should always be as small as possible. Access to the method is opened only when it is really necessary.

Answer 2

First, exposing class fields to the public is almost always a bad idea.
Secondly, it is very important that the API be concise and concise. A third-party developer who will use your class does not need to see more methods than may be necessary for the purpose of the task (do not overload people with information and do not reveal details of your implementation).
Therefore, methods should be defined as private by default. If it turns out that the method may be required (or its behavior may be refined) in a child, then make it protected.
It is worth making public only those methods that correspond to the semantic abstraction.

Answer 3

As mentioned above, private should be used for those variables that will not be needed by class descendants to be used explicitly.
For example, I make all variables private and only when urgently necessary, I transfer them to protected. But more often I just make protected getters and setters for this variable, because how it may be necessary to control access to it from child classes.
Also, keep in mind that protected behaves differently in different languages. For example, in C++ protected allows child classes to have access to a variable, and in Java it allows child classes, as well as all other classes in the same package.

Answer 4

Private is justified in those cases where an incorrect override of a method or attribute by an inheritor can lead to an incorrect state of the object (implementation of an encapsulation violation).
Your mistake is that you are comparing protected with private in the first place, when in fact the difference between protected and public is much smaller than between private and protected.
Think of public and protected as the api of your class. Only public is an external api (for class users), and protected is internal (for class heirs).

Answer 5

Example: a class from a third-party library that is inherited in your program. During the life cycle of your program, you can update the library to a newer version, while its internal structure may change (private methods), but the exposed interfaces cannot (including protected interfaces). But if some methods were declared as protected, then it is no longer possible to significantly change their behavior or declaration.

Answer 6

Can't think of an example? Just now I am programming the client class to the http and https servers. Suppose there is a Client class that generalizes HttpClient and HttpsClient. That class is responsible for the transport work between the application and the protocol. Inside the description of the work processes of the Client class, functions are often used that are directly related to the abstraction level of this class (respectively, they have private access). For example, serializing an array of request headers and then sending it. That is, this function is involved in the Client algorithm, and it makes no sense to use such a function anywhere else, including in the child classes HttpClient and HttpsClient.

Answer 7

What I can say is that encapsulation hides the implementation and minimizes the interface to the client. The child in this case is not a client.

The child in this case is the client.
There is a class and there are two ways to use it - 1. work with its instance. 2. expand it.
The class specifies both the interface of its direct use (public) and the interface of its extension (protected).

Answer 8

There is no definite answer to your question. There is no magic pill here)
You yourself must answer it in each case.