Good manners protected or private?

Question

OOP

Somewhere I heard such a rule of good taste that class methods should be made private by default, if access to the method is needed then it should be changed to
protected classes, and then it will not be necessary to modify the class.
How is it better in the end?

Answer 1

And why don't you set public by default if you choose between public and private? Probably because you need encapsulation?
The situation with child classes is no different. You shouldn't make a method protected by default for the same reason you shouldn't make it public by default.

Answer 2

As for protected, in cases where you doubt it, it’s you in vain) You essentially think through your program, you know approximately what you use in it, but protected doesn’t rush to the wind. What about private, so store only variables there so that they are protected by the class from external changes, but methods are usually stored under public, so you can call them from outside the class.
As a result, variables in private
Protected are only for inheritance
Methods in public , thus you defaesh variables, but also have access to them in the class.

Answer 3

well, there are SOLID principles, which say that classes should be closed for changes and open for extension
If, during development, you suddenly took and changed something in a class, this is a bad signal
If it seems to you that there may be an heir with this field - put protected

Answer 4

there are SOLID principles which say that classes should be closed for modification and open for extension

How is it better in the end?

better - as the developer decides
in most cases because of the solid - it is protected
private that is needed in VERY limited cases

Answer 5

Well, if you approach philosophically), then a class is a fairly self-sufficient piece of code. Those. if something happened, then you go to this class and correct or (complete it - which is not entirely correct). those. the functionality lies in one place (a kind of modularity) and is not spread out over the code. Everyone is happy and drinking beer. The question arises how to break the program into such classes. The principle of dependency inversion comes to the rescue. It sounds scary, but it's actually top-down development. Those. you write work with accounts. I needed to keep accounts. It's a repository. He has a method to save the account. Good cases stub Repository, with save method. Then, as the logic was implemented, a method was needed to load the account. insert into storage.
those. we have an interface of the Storage class that is required for logic. And the methods of this interface will be all public. and nothing more.
Fine. the helper comes, we say "I don't have time, but I have work. I need to implement the methods of my storage" The helper takes your interface as a basis and implements its Impl. The interface methods are public, and the rest that he has allocated for his convenience are privat. Everyone is happy and the work is replaced by a dependency on toster.ru. but the boss comes and says "wtf?!!!" ..;%:;No. "you made the implementation on mysql, and half of our clients work on oracle!"
You take Impl, meditate and understand that you can, in principle, rewrite only part of the class for oracle, and leave the rest. but people are advanced and understand that common code can be separated into a base class. So you have a General class in which there are public, private, protected. public and protected can be abstract. Fine. You implement only the part that you need for oracle and you're done. Moreover, if you need to connect MSSQL, you can easily do it.
Here is such a fairy tale. There is a hint in it - do not produce too much in the interface. pick out what you need. Don't overprotect. only what needs to be reused by descendants. You don't write frameworks. You don't need to push the unnecessary in advance.