I have a question about static member of class in c++, since the static member belongs to the class not any instance of class, so should the static member be declared as public, private?
Whether or not to declare a member public or private has nothing to do with whether it is static or not. You can have a static member be either public or private; both uses are acceptable depending on the situation.
Basically, if you want or need components outside of the class to have direct access to the static member, make it public. Otherwise, make it private.
Actually the static member is shared by all instances of the class. If it was a data member for example you could use is to count how many instances of the class were created. You can declare it either private or public or protected depending on your needs.
You're talking about making some static class members private to the class, so that instances of the class can't access them. Unfortunately I don't think c++ has any syntactical mechanism that you can use to enforce that at compile time. You might be able to pull off a runtime check, but it would be convoluted to say the least.
Really, I'm not sure why you would want to do what your asking. If you are already in ownership of and editing the class, you are also able to edit all the instance methods to ensure they don't use the static member. If you want to try to enforce it you'll have to put a big heavy comment next to your static member saying "Instance methods shouldn't use this" and make sure your team knows it. In general, you don't have to be religious about accessor modifiers like public/private in order to write good code so I would simply say don't worry about trying to enforce what you suggested.
Other object-oriented languages could provide what you are asking for as they draw more of distinction between classes and instances. e.g. Scala, Smalltalk.
Related
When should I mark the static method of a specific class as private other than public?
What aspects should I consider when making such considerations.
What are the advantages for mark the static method as private?
Any simple example would be appreciated, which could help me fully understand this matter.
UPDATE:
As per this answer, which says that[emphasise mine]:
This function could easily have been made freestanding, since it doesn't require an object of the class to operate within. Making a function a static member of a class rather than a free function gives two advantages:
It gives the function access to private and protected members of any object of the class, if the object is static or is passed to the function;
It associates the function with the class in a similar way to a namespace.
How to fully understand the statements above?
The general rule for methods (static or otherwise) is to make them private if possible — i.e. unless you absolutely need them to be callable from other classes (which is to say, you need them to be part of your class’s public API)
The reason for making as much as possible private is simple: in the future, you’ll be able to change anything that is private, without breaking a bunch of other classes that were written to call the old version of the method. Changing a public method is more problematic, because other classes might be depending on it.
What are public, private and protected in object oriented programming?
They are access modifiers and help us implement Encapsulation (or information hiding). They tell the compiler which other classes should have access to the field or method being defined.
private - Only the current class will have access to the field or method.
protected - Only the current class and subclasses (and sometimes also same-package classes) of this class will have access to the field or method.
public - Any class can refer to the field or call the method.
This assumes these keywords are used as part of a field or method declaration within a class definition.
They aren't really concepts but rather specific keywords that tend to occur (with slightly different semantics) in popular languages like C++ and Java.
Essentially, they are meant to allow a class to restrict access to members (fields or functions). The idea is that the less one type is allowed to access in another type, the less dependency can be created. This allows the accessed object to be changed more easily without affecting objects that refer to it.
Broadly speaking, public means everyone is allowed to access, private means that only members of the same class are allowed to access, and protected means that members of subclasses are also allowed. However, each language adds its own things to this. For example, C++ allows you to inherit non-publicly. In Java, there is also a default (package) access level, and there are rules about internal classes, etc.
All the three are access modifiers and keywords which are used in a class.
Anything declared in public can be used by any object within the class or outside the class,variables in private can only be used by the objects within the class and could not be changed through direct access(as it can change through functions like friend function).Anything defined under protected section can be used by the class and their just derived class.
A public item is one that is accessible from any other class. You just have to know what object it is and you can use a dot operator to access it. Protected means that a class and its subclasses have access to the variable, but not any other classes, they need to use a getter/setter to do anything with the variable. A private means that only that class has direct access to the variable, everything else needs a method/function to access or change that data. Hope this helps.
as above, but qualitatively:
private - least access, best encapsulation
protected - some access, moderate encapsulation
public - full access, no encapsulation
the less access you provide the fewer implementation details leak out of your objects. less of this sort of leakage means more flexibility (aka "looser coupling") in terms of changing how an object is implemented without breaking clients of the object. this is a truly fundamental thing to understand.
To sum it up,in object oriented programming, everything is modeled into classes and objects.
Classes contain properties and methods.
Public, private and protected keywords are used to specify access to these members(properties and methods) of a class from other classes or other .dlls or even other applications.
These are access modifiers.
All the data and functions(behaviours) are encapsulated or bounded into a single unit called a class. In order to access the properties and behaviour of the class we use objects. But it's also important to decide which behaviour or property has to be exposed or should remain accessible to all the classes and which behaviour or property has to be private.
So, that's when access modifiers like public, private, protected and protected internal help in doing so. This act of defining privilege to the class or method or property is called as abstraction.
One can choose public static over private static if the static needs to be accessed outside the class(e.g. singleton), while private static is preferred when the function need not be exposed(otherwise unnamed namespaces would do fine) - in which case its only access either through static member function or other non static member functions
However i am trying to get to the core idea of why would one choose private static over private member function?
Ofcourse, both can have access to private members of the class(or any object that is passed), with static member explicitly requiring an object to be passed, but why can't i keep my design open by making it a private Non-Static member function even if it doesn't need access to private members(just like static member functions). This way even if in future i require to access some private members i save myself from converting static to non-static mem func - I understand this isn't a big deal/change but still can somebody give me a crystal clear idea about when and why to choose one over the other?
When you have a static member variable, you choose its access level in just the same way that you would for a non-static member variable. There's nothing "special" here.
Most of my private statics tend to be things like built-in constants that are only used by the internals of the class.
I admit I can't think of many other use cases for them, but I will also tend to make any function static if it logically has nothing to do with a particular instance of the class (and thus needs no non-static member access) — this may be a bit more OCD than some people indulge in though.
why can't i keep my design open by making it a private Non-Static member function even if it doesn't need access to private members(just like static member functions)
You can. It is up to you.
This way even if in future i require to access some private members i save myself from converting static to non-static mem func
Sure. I mean, it's one keyword. But this "forward-compatibility" may be useful if you need to keep your headers from changing (e.g. you're deploying them). Arguably this is a downside of making static members private, where there aren't really many solid upsides. Again, it's up to you.
to ensure the ABI with the pimpl pattern, is that true that we only need to put all the data members to the "Private class" ? I see in some introduction about pimpl, they also make all the functions implementations in the "Private class" and define a "wrapper function" on the exported class for each function in the "Private class", is that necessary?
When your aim is to have ABI compatibility, then you need to put all data member variables in the private class.
There is this famous article about c++ ABI compatibility. From their to do's/don'ts :
you can not change the signature of existing member functions. You can add new methods
you can not add virtual functions to a class without one
you can not add or change non-static data members, or change their order
The list goes on, but these 3 items should cover your questions.
As long as you are 100% sure you are not going to modify private member functions, it is fine. If you expect a change, move them to a private class. I always expect a change.
The advantage of wrapping the functions is that then the functions can be defined in the "private" aka "implementation" class. (Although I always use a struct. Since the entire thing is private to one file I don't see the point to protecting its implementation.)
Since the functions are defined in the same class as the data, you don't need to stick p-> on the front of every access like p->variable.
If you put data in the implementation class/struct but no functions, then all of your function definitions need to put that p-> before every access.
In C++ sometimes in class definition public members are declared at first and privates later. But the variables or data members are normally private and used by the public methods. So, in this case variables are used but not even declared yet. Thus the code become difficult to understand. But I found renowned programmers, sites or books to declare the private members later. Does anybody knows what is the reason?
I do things that way round since users of my class don't care about the private members, they're interested in the public API (i.e. how to use my class).
Also, in header files I'm generally just declaring member functions, rather than defining them, so I'm not accessing any private members anyway.
We read text from top to bottom, so the most relevant information should be at the top. In a class definition, that's the public interface.
Private members and implementation should be hidden from the header file. Putting the private member definitions at the bottom is a quick way to do so. Perhaps it is better to use the Pimpl idiom and hide the private part of your class in an internal struct.
Normally private members don't matter. If I'm looking at a class to determine how to use it somewhere else in code I don't care about it's internals so put private members at the bottom since i don't need to know about them. If I"m modifying a class then I'll take the time to find the private members and know they'll be at the bottom instead of having to skim the entire class.
We are like opposites: My Question
My reasoning is that when you are becoming familiar with a class it is more beneficial to first get introduced to the public interface then go deeper into the private members when you need to. If you start by looking at the private members, you have no context how they are used.
Agreed. Private members should be declared at bottom. The only good reason to declare private members first that i found, is when a function needs to get or return a custom data type, like: vector . The compiler will ask you about what kind of data is that.
But even, in that case i preffer to do:
{
private: /// advicing ofc theres more private below!
earlier declare just of the type
public:
private:
};