When do you write a private method against a protected one?

Question

If I write a class, when do I make the method private and not protected? In other words, how can I know in advance that a client programmer will never need to redefine a method? In the event that he has external considerations, such as connecting to a database?

Answer 1

public and protected methods form an “interface” to your object, public for developers using (delegating) your class, and protected for developers who want to extend the functionality of your object by subclassing it,

Note that there is no need to provide protected methods, even if your class is subclassed.

The public and protected interfaces require careful checking, especially if it is an API that developers will use outside your control, because changes to the interface can disrupt programs that make assumptions about how the existing interface works.

private methods are intended solely for the author of the object and can be reorganized, modified and deleted at their discretion.

I would go for private by default, and if you find that you need to expose more methods, think about how they will be used, especially if they are virtual - what happens if they are completely replaced by an arbitrary alternative function of another developer - will your class work? Then create some suitable protected that can be useful for developers by subclassing your object (if necessary) rather than revealing existing functions.

Answer 2

In other words, how can I know that a client programmer never needs to redefine a method?

You can not. And you do not need. It is not your job to foresee that a developer might want to override a method, not to mention how to do it. Just suppose he wants and allows him to do this without touching your code. And for this reason, do not declare private methods unless you need to.

If a developer feels that he needs to configure some functions of your classes, he can choose from a number of structural and behavioral models to do this, for example. Decorators, adapters, or subclasses. Using these templates is good because it encapsulates the changes in the developer’s own class and does not leave your own code unaffected. By declaring private methods, you will ensure that the developer will be monkey with your class. And that's bad.

A great example is the DB Zend Framework adapter. They prevent the use of persistent connections, and their adapters do not provide any value for this purpose. But what if you want to have this, however, and the adapter method was marked private (it is not, but what if)? Since there is no way to overwrite a method, you would (yes, you would) change the adapter code directly inside the class or copy and paste the code into your own adapter class, effectively duplicating 99% of the class just for changing one function call. Whenever there is an update for this adapter, you will either lose your changes or not get it (in case you are c & p'd). If it were marked as protected (as is), you could just write a subclass of pConnectAdapter.

Also, when subclassing, you actually say that subClass is parentClass. Thus, you can expect the derived class to have the same functions as parentClass. If the parent class has functionality that should not be available in the subclass, then disabling it will conceptually relate to the subclass.

That's why I find it much better to use all the default methods and properties for protected visibility and to mark only those methods (though not properties) that allow interacting with my class from another class or script as public , but only a few things private . Thus, I give the developer the opportunity to use my class, as I expected, to use it, and the ability to configure it. And if he breaks something in this process, it is most likely his fault, not mine.

Update: since I wrote this four years ago, I came to the conclusion that default for protected rather than private often leads to suboptimal subclasses. This is because people will start using everything that you provide as protected. This, in turn, means that you must treat all of these methods as APIs and cannot modify them as you see fit. Therefore, it’s best to carefully consider which extension points you want to provide, and keep everything else private. See http://fabien.potencier.org/article/47/pragmatism-over-theory-protected-vs-private for a similar presentation.

Answer 3

I usually start at the lowest level. If you are not sure, make it private. Then, as needed, you can make things secure or public.

The idea is that this is not a break, the transition from private to secure, but it can be a terrific change to go the other way.

Answer 4

Do not think of a private / protected / public thing, as if the programmer ever "needed" a method. Think of it as if you want to allow them access to it.

If you think that they should be allowed to change the DB connection string, make it public.

Answer 5

I always make all methods private by default. This means that the interface is clean and easy to maintain.

It is much more difficult to change or hide an already visible method than to make a private method more visible. At least if you need to be compatible with existing client code.

Answer 6

In other words, how can I know that a client programmer never needs to redefine a method?

If you do not know what it will be necessary. If this is good for you (i.e. if you think they should be able to), use protected ; otherwise use private .

Answer 7

Private members are used to encapsulate the inner workings of your class. Use them to store data that only you want to receive. For example, suppose you have a field named _name and getter / setter named GetName () / SetName (name). You might want to do some syntax checking on the name before allowing SetName to succeed, otherwise you will throw an exception. By making _name private, you guarantee that this syntax check occurs before any name changes occur (unless you yourself change _name in your own class, in your own code). Protecting you, you say to any potential future heir of your class: "Go ahead and monkey with my field."

In general, protected is used sparingly and only in specialized cases. For example, you might have a protected constructor that provides additional functionality for building child classes.

Answer 8

Usually I just do everything private and refactoring when I need to call it from the base class.

Also, when I feel lazy and do everything protected , it is not definitely dangerous.