protected vs. private convention

[camelCase]

When I want to restrict access to certain class members, I use protected members by default.
This is so I can derive from that class easily without worrying about being unable to use methods/variables from the base class.

I hardly (if ever) use the 'private' access modifier and only use it if I'm sure I only need to make a method/variable accessible to that class and that class alone.

I thought that everyone did what I do until today's programming class at school today.
The lecturer was saying that you should do the reverse.

Make all members/methods that you want to control private and make it protected only when you want to work with inheritance.
This got me a lil' confused so I'm here asking for opinions =x

It probably doesn't matter and is probably up to the programmer but which convention is more widely used and why?
And is one convention really better than the other?

[EDIT]
I might as well toss in another question about singletons.
What's the difference between a singleton and a class with all members/methods static?

 

[Vestras]

I agree with your lecturer. Making everything available to an inheriting class is pretty bad design.

 

[phyrex1an]

I'm from the school that considers properties to be part of the object and not part of the class. In that school, declaring variables local to the class (but somehow still inside the object) doesn't make any sense what so ever. I'd use object composition if I wanted to preserve the invariants you typically try to preserve by using "private". In any case, a subclass can just override all public methods and change the observable behavior that way. Using private doesn't prevent that.
That said, if I can save half a day of refactoring by just writing private I usually take the easy route That doesn't happen very often though.


Edit: I guess that doesn't answer your question at all. A wild guess is that using private is way more common.
But I'd take almost the opposite stance of Vestras and conjecture that: If the distinction between "private" and "protected" matters in your code then it's likely to be badly designed.

What's the difference between a singleton and a class with all members/methods static?

In practice, nothing really.
There might be some differences in how your implementation handle them (for example how much memory is used before you initiate the singleton and what kind of memory is used). If your language doesn't have first class classes (lol) (Java or C# doesn't without using reflection) then you wont be able to "pass around" a static class but you can pass around a singleton.

 

[s3rius]

A difference about a Singleton and a static class is that static classes are initialized at program start. You can't really control where.
Singletons can be initialized when they're called first. That depends on the implementation of the Singleton though.
It also nicely allows polymorphism since you can store whatever class derives from the one your singleton handles.


I always make all of my member variables private, until I consciously decide to turn them into public/protected.
One idea of OOP is making easy interfaces and to encapsulate data. That means you try to hide all internal mechanics from external eyes.

 

[camelCase]

Making everything available to an inheriting class is pretty bad design.

Oh..
Guess I get funny ideas here and there =/

I'm from the school that considers properties to be part of the object and not part of the class. In that school, declaring variables local to the class (but somehow still inside the object) doesn't make any sense what so ever. I'd use object composition if I wanted to preserve the invariants you typically try to preserve by using "private". In any case, a subclass can just override all public methods and change the observable behavior that way. Using private doesn't prevent that.
That said, if I can save half a day of refactoring by just writing private I usually take the easy route That doesn't happen very often though.

I read that and my head exploded =x
It seems like it might be interesting but my head can't parse it at this moment =/

If the distinction between "private" and "protected" matters in your code then it's likely to be badly designed.

That statement seems like it could spark a debate =x
But I've never found a real need for both private and protected at the same time (even though I know the difference between the two).
In fact, I don't think I've *ever* used the 'private' access modifier except in test programs =/

A difference about a Singleton and a static class is that static classes are initialized at program start. You can't really control where.
Singletons can be initialized when they're called first. That depends on the implementation of the Singleton though.
It also nicely allows polymorphism since you can store whatever class derives from the one your singleton handles.

Those are really good points ;O
I now view Singletons as totally separate from static classes ._.

I always make all of my member variables private, until I consciously decide to turn them into public/protected.
One idea of OOP is making easy interfaces and to encapsulate data. That means you try to hide all internal mechanics from external eyes.

Huh..
I always felt that 'protected' provided all the encapsulation I needed.
Guess I need to program moar =/

Okay, so..
A class would normally have *only* private members.
A class will have protected and/or private members if it serves as a base-class.
Of course, base-class or not, both will have public members.

Right.. ?

 

[s3rius]

A class would normally have *only* private members.
A class will have protected and/or private members if it serves as a base-class.
Of course, base-class or not, both will have public members.

Well, I only make everything private because I didn't know about protected when I started to program. So it became a habit xD

But basically I only change the private access when there's a good reason for it.
Either I need to because of inheritance.
Or I think it's ok to allow the outside to use this function/variable.

For example

class Point{
public:
    int x;
    int y;
}

I'd be stupid to make getters/setters for those -_- xD

If the distinction between "private" and "protected" matters in your code then it's likely to be badly designed.

Especially in libraries it's important to differentiate between private and protected.
If you create a superclass from which users can inherit their own classes it's important to keep critical internals away from them, while you might still want them to have access to other stuff.
One could argue that everything else could be declared public, since the user has access to it through the inherited subclass anyway. But that would completely defeat the idea of data encapsulation.

 

[camelCase]

Thanks, S3rius!
Seems like that pretty much convinced me to use private over protected =x