In c++ instance variables are private by default,in Python variables are public by default
i have two questions regarding the same:-
1: why Python have all the members are public by default?
2: People say you should your member data should be private
what if i make my data to be public?
what are the disadvantages of this approch?
why it is a bad design?
You can use a leading underscore in the name to tell readers of the code that the name in question is an internal detail and they must not rely on it remaining in future versions. Such a convention is really all you need -- why weigh the language down with an enforcement mechanism?
Data, just like methods, should be public (named without a leading underscore) if they're part of your class's designed API which you intend to support going forward. In C++, or Java, that's unlikely to happen because if you want to change the data member into an accessor method, you're out of luck -- you'll have to break your API and every single client of the class will have to change.
In Python, and other languages supporting a property-like construct, that's not the case -- you can always replace a data member with a property which calls accessor methods transparently, the API does not change, nor does client code. So, in Python and other languages with property-like constructs (I believe .NET languages are like that, at source-code level though not necessarily at bytecode level), you may as well leave your data public when it's part of the API and no accessors are currently needed (you can always add accessor methods to later implementation releases if need be, and not break the API).
So it's not really a general OO issue, it's language specific: does a given language support a property-like construct. Python does.
I can't comment on Python, but in C++, structs provide public access by default.
The primary reason you want a private part of your class is that, without one, it is impossible to guarantee your invariants are satisfied. If you have a string class, for instance, that is supposed to keep track of the length of the string, you need to be able to track insertions. But if the underlying char* member is public, you can't do that. Anybody can just come along and tack something onto the end, or overwrite your null terminator, or call delete[] on it, or whatever. When you call your length() member, you just have to hope for the best.
It's really a question of language design philosophies. I favour the Python camp so might come down a little heavy handedly on the C++ style but the bottom line is that in C++ it's possible to forcibly prevent users of your class from accessing certain internal parts.
In Python, it's a matter of convention and stating that it's internal. Some applications might want to access the internal member for non-malignant purposes (eg. documentation generators). Some users who know what they're doing might want to do the same. People who want to shoot themselves in the foot twiddling with the internal details are not protected from suicide.
Like Dennis said "Anybody can just come along and tack something onto the end, or overwrite your null terminator". Python treats the user like an adult and expects her to take care of herself. C++ protects the user as one would a child.
This is why.
Related
Qt makes heavy use of the PIMPL idiom in their development process: https://wiki.qt.io/D-Pointer
As I've read here: "The name 'd-pointer' stems from Trolltech's Arnt Gulbrandsen, who first introduced the technique into Qt, making it one of the first C++ GUI libraries to maintain binary compatibility even between bigger release.". But nobody says what "D" stands for.
So what does the "D" stand for in D-Pointer?
From this page Data Sharing with Class (an old docs from QT), it says:
Before we can share an object's private data, we must separate its interface from the private data using an idiom called "d-pointer" (data pointer)
So, d-pointer means data-pointer
I'll add my own answer, since I remember the day it happened.
I was trying to extend something while maintaining binary compatibility, and noticed that there was a pointer called 'data' that I could reuse for a different purpose. So I made a private class for implementation-related data (a pimpl), put both the old data and my new data there, and since the existing name seemed to fit I kept the name.
I abbreviated it from data to d after a short meeting later on the same day, where we agreed that the pattern I'd invented stumbled upon was good and we should use it widely, and that d-> was short enough and unique enough to be used everwhere as a mark of implementation-specific fields.
At the same meeting, we decided to put implementation-specific data in d-> as a matter of policy from then on, mostly in order to keep the number of includes down, but also to keep the declared API clean in general. Fewer private variables in the class declaration means few opportunities for error, fewer temptations, fewer things that can conflict with subclass naming and so on. Better hygiene.
Following my reading of the article Programmers Are People Too by Ken Arnold, I have been trying to implement the idea of progressive disclosure in a minimal C++ API, to understand how it could be done at a larger scale.
Progressive disclosure refers to the idea of "splitting" an API into categories that will be disclosed to the user of an API only upon request. For example, an API can be split into two categories: a base category what is (accessible to the user by default) for methods which are often needed and easy to use and a extended category for expert level services.
I have found only one example on the web of such an implementation: the db4o library (in Java), but I do not really understand their strategy. For example, if we take a look at ObjectServer, it is declared as an interface, just like its extended class ExtObjectServer. Then an implementing ObjectServerImpl class, inheriting from both these interfaces is defined and all methods from both interfaces are implemented there.
This supposedly allows code such as:
public void test() throws IOException {
final String user = "hohohi";
final String password = "hohoho";
ObjectServer server = clientServerFixture().server();
server.grantAccess(user, password);
ObjectContainer con = openClient(user, password);
Assert.isNotNull(con);
con.close();
server.ext().revokeAccess(user); // How does this limit the scope to
// expert level methods only since it
// inherits from ObjectServer?
// ...
});
My knowledge of Java is not that good, but it seems my misunderstanding of how this work is at an higher level.
Thanks for your help!
Java and C++ are both statically typed, so what you can do with an object depends not so much on its actual dynamic type, but on the type through which you're accessing it.
In the example you've shown, you'll notice that the variable server is of type ObjectServer. This means that when going through server, you can only access ObjectServer methods. Even if the object happens to be of a type which has other methods (which is the case in your case and its ObjectServerImpl type), you have no way of directly accessing methods other than ObjectServer ones.
To access other methods, you need to get hold of the object through different type. This could be done with a cast, or with an explicit accessor such as your ext(). a.ext() returns a, but as a different type (ExtObjectServer), giving you access to different methods of a.
Your question also asks how is server.ext() limited to expert methods when ExtObjectServer extends ObjectServer. The answer is: it is not, but that is correct. It should not be limited like this. The goal is not to provide only the expert functions. If that was the case, then client code which needs to use both normal and expert functions would need to take two references to the object, just differently typed. There's no advantage to be gained from this.
The goal of progressive disclosure is to hide the expert stuff until it's explicitly requested. Once you ask for it, you've already seen the basic stuff, so why hide it from you?
If I have a class that inherits from another, and only this class has to use a certain variable, which is better practice? To have said variable be 'protected' in the base class, or have it private and give it a protected getter?
I've heard conflicting things. My teachers told me to always use getters, while other people have told me that using getters at any level reveals bad program design. What's the real answer? I feel like both are illogical extremes.
Also, if getters and setters are bad program design, why is this?
Are there any resources that will teach me more about how to structure my code?
Do you need (or anticipate you will need in the future) to do anything else other than just reading a value? For example: assertions, locking or making the read polymorphic?
If no, use the field.
If yes, use the getter.
Whether you use protected or not is completely orthogonal to that.
BTW, managed languages such as C# and Java often require the presence of getters, where "logically" just the ordinary fields would suffice, because their UI design (and other) tools were implemented to use reflection that way. So the practice of excessively using getters seems to have "rubbed off" the C++, despite the lack of reflection or such tools in C++.
protected is closer to public than private. People can create a derived class, access and change the protected members and use their derived instance as an instance of the base class. You can make your decision based on that. If you want a data member to be read-only for the outside world, you need a getter and there is no way around that. A protected getter (and maybe setter) can also work.
Another thing to note is that setters can act as a gateway to your data. They can be used to validate ranges and throw exceptions when needed. Take this into consideration as well.
Also, since you said that it is for use by a certain derived class, you might want to make that class friend. This may or may not be a good idea, you should carefully evaluate pros and cons.
I don't think that getters and setters are generally bad design. I'm sure they can be abused, as almost any idiom or pattern. Generalizing is never a good idea.(1)
(1) Yeah.
Your protected and public interface (classes, members, fields) are things that you need to keep stable. Every time you change your protected and public interface, you have the potential to break any code that depends on it.
This might be one line of your own code that you break. It might be hundreds of classes in your own codebase. If you shipped your code somewhat publicly, then you might break thousands of lines of code from hundreds of programmers you've never heard of and will never meet.
Sometimes this break is necessary and good. Sometimes it could have been avoided with a little foresight. Getting into the habit of understanding and considering your reasons for change is the core to good design.
if getters and setters are bad program design, why is this?
Getters and Setters give you only a small amount of encapsulation. You still aren't hiding much from users. They still know there's a field of that type in your code (or at least know you're pretending that that there is), and they depend on it being there. If you changed the implementation of your class in such a way that made that field unnecessary, you couldn't remove the getter/setter unless you were willing to break all dependent code. If you tried to avoid the break, you'd have to make those accessors still work and make logical sense, which might be difficult.
Sometimes exposing a field (or a Getter/Setter) makes sense, even in high level code. If that field is important to access, and would never have a good reason to change name or type (from the view of a programmer using your code), then it might be fine and good and best to expose it in some way.
Sometimes wrapping fields in a Getter/Setter makes sense. If you have Getters/Setters, it can be easier to add logging, bounds checking, thread locks/semaphores, and debugger breakpoints. It is also easier in C++ to define an abstract interface that requires a Getter/Setter to be present than it is to define an interface that requires a field to be present.
Sometimes directly exposing a field, and not using getters/setters makes sense. Sometimes "classes" made entirely of fields makes sense (consider using a struct instead). This is going to be most common in very low level code (such as code that pulls data out of a file), or inside the implementation of another class (such as in the implementation of an algorithm). Often you'll hide these classes inside other classes, so users of your code never see them.
My teachers told me to always use getters, while other people have told me that using getters at any level reveals bad program design. What's the real answer? I feel like both are illogical extremes.
Blanket statements often have truth to them, but truth is seldom binary.
Get in the habit of asking "why?". Get in the habit of judging truth for yourself, and judging situations within their own context. Sometimes what is "always best" is not actually best, or even desirable at all, in a specific situation.
In most cases, getters and setters do reveal bad desing. But there is no general rule. The main reason to use getters and setters should be for debugging, so when you're accessing some base class member from a derived class, you have a point you can set a breakpoint at to intercept changes to that member.
So, you should adapt. If you plan on having 2-3 levels of inheritance, it's better to go with protected members, since there aren't that many places the member can change. If more, protected setters/getters might be a better option - you don't want to set breakpoints in every class that can possibly modify a member of the base class.
If the member in the Base class is not required to be accessed outside the derived class then you make them protected in the base class. That is the purpose of protected access specifier.
Getter and setter methods are an explicit way of saying that this member variable is available for use and usually they should be used to expose the member to external entities. They make the intent clear, but since your variables only need to be accessed in the derived class, the protected access specifier already expresses the intent clearly.
What are classes. Collections of data or collections of behaviors?
Of course they're both. But let's contrast how fields and accessor methods (getters and setters) enable you to work with data and behaviors.
Fields
Are data
You can't alter their behavior without altering dependent classes (unless they're pointers to abstract base classes)
They can be directly accessed with operators, so can be used inline in expressions.
You can't get as clever with their noun-based names. They usually won't be tied to beahvior.
Accessor methods
Are behaviors
You can change them without having to alter dependent classes (assuming you've kept the same contract)
You cannot access them directly with operators, so can't be used directly in as many expressions (without some work).
You can do Method Chaining with them.
You can get as clever as you want with their verb-based names (Get, Create, Find, etc). They define a behavior.
Tangent: Method chaining is neat, because it lets you create something called a "Fluent Interface".
Encapsulation
Whatever you do, you should remember your OO principles. Don't violate your encapsulation.
If you write a class that is suppose to encapsulate its whole behavior, yet exposes a field, you've broken your encapsulation. If you've written a class that stores data, and has convenient assignment/data-generation patterns that happen to map well to methods on that class, then you haven't broken your encapsulation.
Which case is true for your class depends on the level of abstraction the class is operating at.
When to use each
They both make sense to use in certain contexts.
It makes sense at lower levels of code to work more closely and intimately with data. In these cases you should use the most performant and most data-tied syntax you can. Use fields.
It makes sense at higher levels of code to work more closely and intimately with behaviors. In these cases you should use the most flexible and most behavior-tied syntax you can. Use accessors. Or, often, don't use accessors. Use interfaces, classes, and non-accessor methods instead.
When in doubt, I opt for flexibility over performance. It is hard to predict performance bottlenecks in whole programs by examining things at this particular level of detail. We're really bad at it, and that is why profilers exist. It is easier to make an accessor into a field than vice-versa. If you're careful and lucky, you might already have your accessors inlined, which would then make it a moot point.
I've read a lot of guides that explain why I should use "private" and the answer is always "Because we don't want anyone else setting this as something". So, let me ask the following questions:
Assuming that I want to have a variable that is set-once (perhaps something like a character name in a video game, ask once, then it's set, and then you just use the get variable(edit:function) for the rest of the game) how do I handle that one set? How would I handle the get for this as well?
What is the actual advantage of using a private access modifier in this case? If I never prompt the user to enter the name again, and never store information back to class.name shouldn't the data remain safe (moderately, assuming code works as intended) anyways?
I hope someone will help me out with this as the explanations I've googled and seen on here have not quite put my thoughts to rest.
Thanks!
The access specifiers mainly serve to denote the class interface, not to effectively limit the programmer's access or protect things. They serve to prevent accidental hacking.
If something is set once, then you should try to set it when it is created, and make it const.
If the interface doesn't need to be especially clear (for example, if few people need to learn it) then it doesn't make sense to spend effort engineering it. Moreover changes that don't make much difference in how the interface is used can be applied later. The exposed variable can be changed to a getter/setter using simple search-and-replace.
If it were a published binary interface, then you would want to get it right the first time. But you're just talking about the internals of your program.
And it's fairly unlikely that anyone will reset the player name by accident.
I won't try to justify the private set method as that sounds a bit weird to me. You could handle the one set by using a friend declaration. But then why would you define a setter when the friend could just set the value directly?
I generally avoid setters if I can at all manage it. Instead I prefer provide facility to set member variables via the constructor. I am quite happy to provide getters if they make sense.
class player_character_t {
std::string name_;
public:
player_character_t(std::string const& name)
: name_ (name)
{
}
std::string const& name() const { return name_; }
};
This forces you to delay construction of the object until you have all the information you require. It simplifies the logic of your objects (ie they have a trivial state diagram) and means you never have to check is something is set before reading it (if the object exists, it is set properly).
http://en.wikipedia.org/wiki/State_diagram
Marking things as private helps prevent accidents. So when you make a mistake and it is no longer the case that the "code works as intended" the compiler may help you detect it. Likewise const can be a big help in detecting when you are using objects incorrectly.
It's that last parenthetical that is important: assuming code works as intended.
In my mind it's similar to permissions in Linux systems. You know the root password and you can delete any file, but you don't stay logged in as root so you don't do anything by accident. Similarly, when you have a private variable characterNameString, and someone (or you) later tries to give it a new value, it will fail. That person will have to go look at the code and see that it's marked private. That person will have to ask themselves "why is this private? Should I be modifying it? Should I be doing this another way?" If they decide they want to, then, they can. But it prevents silly mistakes.
Don't confuse the private and the public interfaces of the class. In theory these are completely different interfaces, and this is just a design feature of C++ that they're located physically in the same class declaration.
It's perfectly ok to have a public getter/setter when the object property should be exposed via the public interface, so there is no rule such as 'setter is always private'.
More on that topic in the (More) Exceptional C++ books by Herb Sutter. It's an absolutely neccessary reading for someone who wants to understand C++ and be proficient with it.
If you have doubts over deciding whether to use getter/setters over the class variables, there are numerous explanations on the internet why getters/setters are better.
If the variable is 'write once then forever read only' I'd recommend making it a const member that is initialized during construction. There's no value in a private 'setter' function because it won't be used. Also you avoid people using the setter function to set the name when it's never meant to be set.
For example:
class Player
{
private:
const std::string m_name;
public:
Player(const std::string& name) : m_name(name) {}
};
Private getters and setters all make sense when the data in question involves several variables, have additional constraints you want to make sure you adhere to, and these operations are done several times in your class. Or when you plan further modifications to the data model and wish to abstract operations on the data, like using std::vector but planning to make it std::map or similar cases.
For a personal example, I have a smart pointer implementation with a private reset(T*, int*) method that is essentially a setter for the stored object and its reference count. It handles checking validity of objects and reference counts, incrementing and decrementing reference counts, and deleting objects and reference counts. It is called eight times in the class, so it made perfect sense to put it into a method instead of just screwing around with member variables each time, slowing programming, bloating code and risking errors in the process.
I am sure private getters can also make sense if you are abstracting the data from the model and/or you have to implement error checking, for example throwing instructions if the data is NULL instead of returning NULL.
I'm writing in second-person just because its easy, for you.
You are working with a game engine and really wish a particular engine class had a new method that does 'bla'. But you'd rather not spread your 'game' code into the 'engine' code.
So you could derive a new class from it with your one new method and put that code in your 'game' source directory, but maybe there's another option?
So this is probably completely illegal in the C++ language, but you thought at first, "perhaps I can add a new method to an existing class via my own header that includes the 'parent' header and some special syntax. This is possible when working with a namespace, for example..."
Assuming you can't declare methods of a class across multiple headers (and you are pretty darn sure you can't), what are the other options that support a clean divide between 'middleware/engine/library' and 'application', you wonder?
My only question to you is, "does your added functionality need to be a member function, or can it be a free function?" If what you want to do can be solved using the class's existing interface, then the only difference is the syntax, and you should use a free function (if you think that's "ugly", then... suck it up and move on, C++ wasn't designed for monkeypatching).
If you're trying to get at the internal guts of the class, it may be a sign that the original class is lacking in flexibility (it doesn't expose enough information for you to do what you want from the public interface). If that's the case, maybe the original class can be "completed", and you're back to putting a free function on top of it.
If absolutely none of that will work, and you just must have a member function (e.g. original class provided protected members you want to get at, and you don't have the freedom to modify the original interface)... only then resort to inheritance and member-function implementation.
For an in-depth discussion (and deconstruction of std::string'), check out this Guru of the Week "Monolith" class article.
Sounds like a 'acts upon' relationship, which would not fit in an inheritance (use sparingly!).
One option would be a composition utility class that acts upon a certain instance of the 'Engine' by being instantiated with a pointer to it.
Inheritance (as you pointed out), or
Use a function instead of a method, or
Alter the engine code itself, but isolate and manage the changes using a patch-manager like quilt or Mercurial/MQ
I don't see what's wrong with inheritance in this context though.
If the new method will be implemented using the existing public interface, then arguably it's more object oriented for it to be a separate function rather than a method. At least, Scott Meyers argues that it is.
Why? Because it gives better encapsulation. IIRC the argument goes that the class interface should define things that the object does. Helper-style functions are things that can be done with/to the object, not things that the object must do itself. So they don't belong in the class. If they are in the class, they can unnecessarily access private members and hence widen the hiding of that member and hence the number of lines of code that need to be touched if the private member changes in any way.
Of course if you want to access protected members then you must inherit. If your desired method requires per-instance state, but not access to protected members, then you can either inherit or composite according to taste - the former is usually more concise, but has certain disadvantages if the relationship isn't really "is a".
Sounds like you want Ruby mixins. Not sure there's anything close in C++. I think you have to do the inheritance.
Edit: You might be able to put a friend method in and use it like a mixin, but I think you'd start to break your encapsulation in a bad way.
You could do something COM-like, where the base class supports a QueryInterface() method which lets you ask for an interface that has that method on it. This is fairly trivial to implement in C++, you don't need COM per se.
You could also "pretend" to be a more dynamic language and have an array of callbacks as "methods" and gin up a way to call them using templates or macros and pushing 'this' onto the stack before the rest of the parameters. But it would be insane :)
Or Categories in Objective C.
There are conceptual approaches to extending class architectures (not single classes) in C++, but it's not a casual act, and requires planning ahead of time. Sorry.
Sounds like a classic inheritance problem to me. Except I would drop the code in an "Engine Enhancements" directory & include that concept in your architecture.