Printable View
This is kinda related to my other thread about protected members.
If I have a data member, maybe an int val which should be readable as well as writable by clients. Is it still better practice to create a getter AND setter method instead of making the member public?
If an object is fully accessible to anyone anywhere, then what is the point
of initialization during construction?...
Using a public member is using a global (in terms of accessibility) which
collides C++ encapsulation.
I don't get your point. It's not global, it's still in the context of the class.
An object instance allows everyone to "mess" its public member, like a program that allows everyone to "mess" its globals.
Guysl's point is that it's globally accessable, i.e. accessable by anyone in the (program) world. The problem with this approach is that the class itself then has no way of knowing that someone has changed it's variable(s) which can lead to disaster. I believe that there was an example posted, something like this:
This is bad. Since it's my data, I'm assuming that the data will be valid for the life of the class instance. However, because the data is public, anyone can change it, and cause crashes, memory leaks, etc...Code:class foo
{
public:
foo() { m_MyData = new char [100]; }
~foo() { delete [] m_MyData; }
void doSomethingWithData(const char *pNewData)
{ strcpy(m_MyData, pNewData); }
char *m_MyData;
};
int main()
{
foo myFoo;
myFoo.m_MyData = NULL;
myFoo.doSomethingWithData("This will crash!!!");
}
Now, if the data was private, then only my class can change it. Therefore, I can completely control when it's created/deleted, etc.
Viggy
Public setter and getter (for a private member), compared to a public member variable, are similar in access rights, but have a significant difference: setter (and getter) provide extra layer of abstraction.
A few of the benefits are:
- controlled access (optional validation, counters, etc.)
- notification of a change (obviously), so you can update related data
- hiding implementation details (you can change a type of that member, or even combine it with another or split into multiple members), without changing client's code
It's a matter of style. When they implemented std::pair they made it a struct (which is the same as a class anyway). So you use aPair.first and aPair.second to access rather than aPair.getFirst() and aPair.getSecond().
Generally the rule is that for small data structs it is fine to use public members, usually fairly basic types, but for fully-fledged classes it's slightly more conventional to make the attributes private and use access functions.
While in C++ a class and a struct are the same thing, on a design level, I would call a struct a collection of data - it may have user-defined constructors but not really "methods" as such. A class has attributes rather than data and methods.
get functions are usually inlined and therefore there is no major difference in performance. set functions can be useful for debugging as you can stick a breakpoint or a cout in a set function to trace where it is being called more easily.
Alright, thanks, I usually do it like NMTop40 said. Although struct is pretty useless in C++ I use it when I have a small class which has no user defined methods and only data members which are supposed to be accessed by the "public domain" :)
And what if I have a class (a nested class for example) that I don't want *everyone* to access a certain setter method, but only the outer class. Then 'friend' and 'private' are the way to go instead of just making the setter public, right?
With a nested class I will sometimes put the nested class in the private area of the class but make its access all public, thus giving the outer class full access.
Well...in general this is correct, however, there are two differences between them...Quote:
Originally Posted by NMTop40
- By default, the members of a class are private, while the members of a structure are public.
- Structs are inherited from publically by default while classes are inherited from privately.
Aside from these distinctions, structures and classes perform exactly the same function.
Yes that is true. I generally think in a class it is clearer to use the keyword "private" anyway though.
One thing that could come in handy is the use of a friend function. This could help you get what you want.
Friends are iffy in that they greatly increase the coupling in your program, which is something that you generally want to reduce. Indeed, friendship is the tightest coupling there is, followed by inheritance (because friendship grants access to all members, whereas inheritance still denies access to private members).
The thing to keep in mind is the distinction between interface and implementation. A well-designed class will present a good, useful interface to the rest of the world. The implementation of that interface, however, should be hidden. The rest of the program should not be interested in how the class works, only in what it does. By hiding the implementation, you give yourself the freedom to change that implementation at will without affecting the rest of the program. Expose any part of your implementation and you have to be very careful about changing it, because other classes and functions may be dependent on the specifics (IOW, you have high coupling between classes).
Implementation hiding reaches its peak with the pimpl idiom, where the class consists only of public function members and a single pointer to an implementation class:
Using this idiom, the entire implementation is hidden away in the implementation file. The outside world only sees a single name (fooimpl), without even a class definition - and even the little bit that can be "seen" is private. The freedom this gives you to radically alter the implementation is unrivalled - you cannot affect anyone else, even if you completely rewrite the implementation. And, since changing the implementation doesn't even affect the header file, a complete rewrite of the implementation still only requires the recompilation of a single file. (Of course, if the new implementation is rubbish, that is a sort of effect, but that's not what I mean.)Code:class foo
{
public:
// function members
private:
class fooimpl* pimpl;
};
The protected section of a class is there to provide an interface for use by derived classes only - it's like the public section apart from restricted access.
This is not about style, this is about clean code, maintainable code, robust code - code that you can muck about with without having the whole edifice collapse around your ears; code that you're not afraid to make improvements to, because you know changes will be localised and easily undone.
My personal approach to the implementation of a class's (public and protected) interface is:
1) Whenever possible, make it invisible (using pimpl).
2) If I can't make it invisible, make it private.
3) If I can't make it private, retire, because I've forgotten how to write C++.
Your mileage may vary, of course. I've described a personal approach, one which comes from viewing C++ classes not as blobs that contain functions and data, but as entities that provide an interface and an implementation of that interface. To my mind, data members are implementation, with very few exceptions (I can't think of one at the moment), so should be hidden from everyone.
Well, yes, you're right. I should have stated that friend functions/classes have to be dealt with care. But it is one example on how the program can get access to a class's variables or functions.Quote:
Originally Posted by Graham
Graham, I've read your entire post, but I still have some questions.
When you talk about the pimpl idiom, do you mean something like having 2 classes, one for implementation and one that uses the implementation class but prevents the modification of this class?
Herb Sutter, in Exceptional C++, has an excellent article about the pimpl idiom (also known as "Compiler Firewall"). Basically, the idea is that you present an "interface class" to the rest of the world (note: I don't mean a class that only has pure virtual functions; I mean one that only has public - and possibly protected - functions, plus the private pointer-to-implementation). You separate the implementation of that public interface into another class: this one is completely hidden from the rest of the program.Quote:
Originally Posted by YourSurrogateGod
So, yes, that about sums it up, except that I'm not sure what you mean by "prevents the modification of this class". The implementation class is hidden away, the external (interface) class, uses it.
When I made that particular statement, I was refering to the implementation class, the fact that it's hidden and such.Quote:
Originally Posted by Graham
And to provide a small example...Quote:
Originally Posted by YourSurrogateGod
Code:class CDllImpl; // Forward declaration of implementation class
class CDll
{
public:
void Function();
// all your functions etc.
private:
CDllImpl *m_pImpl;
};
// dll.cpp
#include <dll.hpp>
#include <dllimpl.hpp>
CDll::CDll()
{
m_pImpl = new CDllImpl;
}
CDll::~CDll()
{
delete m_pImpl;
}
void CDll::Function()
{
m_pImpl->Function();
}
// dllimpl.hpp
#include <SomeHeader>; // Here you can put all your needed headers
class CDllImpl
{
public:
void Function();
...
};
// dllimpl.cpp
void CDllImpl::Function()
{
// Do some processing
}
Just one thing to be careful about there:
- Default copy constructor. Yikes! and operator=
You can handle this in several ways:
- use boost::scoped_ptr< Impl >
Impl can still be incomplete. Will automatically make your class non-copyable and non-assignable and you won't have to worry about the delete
- put in private declarations (no definitions required) for copy constructor and operator=
- derive privately from boost::noncopyable
- implement a deep copy
You could also use boost::shared_ptr but then you'd find your two copies were actually simply different references to the real impl. If that's what you want then do it, but beware of this among other things:
Because both instances of MyClass share their implementation, you are modifying both of them when you call the nonConstFunction.Code:void DoSomething( const MyClass & rMyClass )
{
// you think I can't modify the MyClass but I can, without const-casting, thus
MyClass myClassCopy( rMyClass );
myClassCopy->nonConstFunction(); // haha!
}
Of course, the interface of the implementation class doesn't have to mirror the interface of the outer class. For example Outer::function() could call two or more functions of the pimpl class. This comes from another possibility raised by the pimpl idiom: one carefully designed pimpl class could actually provide the implementation for two or more outer classes, who use the (probably much more low-level) functions of the pimpl in different orders or at different times.
It often does mirror it though. I've often thought about doing the below but never actually have done it:
That would lead to the prospect of actually doing this:Code:class Impl1 : public SomeInterface
{
public:
// all the methods
private:
boost::scoped_ptr< Impl2 > m_pImpl;
};
class Impl2 : public SomeInterface
{
// everything
};
Here you have a base class (probably abstract), an implementation which is a fully blown implementation (Impl2) and an implementation by proxy (Impl1). Impl1 is a concrete class and you can construct members of it.Code:class Impl1 : public SomeInterface
{
private:
boost::scoped_ptr< SomeInterface > m_pImpl;
public:
// these methods are virtual in SomeInterface
virtual void Method1() { m_pImpl->Method1(); }
virtual int Method2( const std::string & s ) const
{ return m_pImpl->Method2( s ); }
// etc
// in .cxx file
Impl1::Impl1()
: m_pImpl( new Impl2 )
{
}
I'd be interested to know, by the way, has anyone ever written an automatic code generator for pImpl.
Thanks, I think I'll play around with this subject a little bit more when I get home.Quote:
Originally Posted by Andreas Masur
The closest I got once was to write a Rational Rose macro that made a pimpl from a given class. That is, if I created a class foo in my Rose model, I selected it, then chose the pimpl macro, and it created a foo_impl class and added the appropriate aggregation dependency.
I've just read all your answers, very interesing, very interesting. That book by Herb Sutter, I think I'll give it a shot. I still find myself being unhappy with my class design too often. It's a serious challenge in C++. :/