I'm using some kind of "manager" to store a "Context" class, in some cases I want to pass this "Context" to other functions to read data from it.
Actually, when the manager pass this "Context" to a function, it pass a "const& Context", and I the Context have some functions declared as const (for reading) and others that aren't const (becouse the manager have to change the data inside the context)
now, I ask myself, is there any difference if I just do private mutators and give friendship to manager?
I think it must be some difference.
I know, it's a particular case, but for me C++ still have a lot of magic around there.
In my experience with C++, the main difference between having private mutators and giving friendship and having public mutators not giving friendship is that the second option allows you to not give anything and everything access to the information but only certain. Let's say you create a class called Student which has 2 child classes. Regular Student and Teachers Assistant. A lot of times there's so many students that it's hard for the teacher to take care of everything so he takes the best students as TA's. When the program is looking at these students, they should probably have more access to the Student's information than the regular student. With private mutators and giving friendship, you are saying some information (like a grade on a test) is private but can be changed by a TA possibly. On the other hand, if you have public mutators and no friendship, it is possible that a regular student can access the information and change the grades.
Hope this was helpful.
I'll start with two general statements:
const-correctness is a very good thing
firendship forms extremely close coupling between the two classes, which is generally a bad thing
Is your Context so tied in to the manager that only the manager would ever want to modify it (both now and as your program evolves through the years)? And is Context happy to have the manager modify it as it pleases (accessing all its private data)? If any of the answers is "no," you shouldn't go the friendship route.
Friendship should be used sparingly. When class X grants friendship to class or function Y, you now have two separate places in code which must maintain X's internal invariants: X itself, and Y. This requires more maintenance and is more error-prone.
In short, reserve friendship for very special cases. What you describe seems like a clear-cut use for normal measures - const observers, non-const modifiers.
Related
#include<iostream>
class student
{
private:
int roll_no;
int standard;
public:
void input();
void display();
};
I asked my teacher about the significance of making some class members private and some members public. He said that data members are usually made private for security reason. He said that no object can access private things of a class, thats why they are secure.
My question is:
When we will develop software, we will be distributing executable files to users. Users will not be able to edit the code. What type of security our teacher is talking about? When I have created the entire code, how someone can edit it? What is the need to think about security?
No your teacher would not be correct that encapsulation, as this is called, is for security. Encapsulation is actually there for a few other reasons:
Creates better maintainability of code. When all the properties are private and encapsulated, it is easy for the writers of the code to maintain the program simply by changing the methods.
Have a Controlled Environment. Encapsulation lets the users use the given objects, in a controlled manner, through objects. If encapsulation didn't exist, client code could use the members of your class in any way they wanted, while member functions limit this to a specific behavior.
Hide Complexities: Hiding the complexities irrelevant to the users. Sometimes, some properties and methods are only for internal use and the user doesn't have to know about these. This makes it simple for the user to use the object.
An example that illustrates what would happen if you didn't have encapsulation:
Suppose you had a class called Human, with a member called age that is public. Now, if someone wanted to modify this, say, based off input, then they would have to check to see if the input is not negative or not a huge amount every time, unless they make a function for it. Now if there was a member function instead that provided access to age, then it wouldn't be client code's problem anymore, since the setter for the field would take care of it as it would be the responsibility of the class to make sure its fields are valid.
This will not affect users of an application, but the teacher is trying to make you safe from your own mistakes.
Keeping member variables private, when possible, protects you from accessing and changing them accidentally from places in your code where you shouldn't do that.
It also makes is clear for the users of the code which variables and functions are intended to be used from outside the class and which are not, thus clearly defining the API of the class.
Just like each person knows their own secrets and it is somehow dangerous to tell others, private members are not exposed to other classes because it may break something in the class and other classes don't really need to know them.
However, people need to communicate to fulfill their needs. We talk, explain our thoughts to be understood.. well, public members are like this, they are needed for the class itself communicate with other classes.
I have a class A which has public methods and used by 100 other classes implemented in different applications. Now I want to make those public methods as private so that no new classes access them, but I want the existing client classes to still access them.
But I don't want to even touch those client classes , because the owners seldom allow even any ripple in their classes.
I checked
Can I access private members from outside the class without using friends?
C++: Is there a way to limit access to certain methods to certain classes without exposing other private members?
friend class with limited access
But all ( not all really ) demand a change in the client's code. The client code should not change.
One straight forward way is to make all those N classes friends , But I am somewhat not comfortable doing that. Is there any pattern or an acceptable technique ( not a hack please ) to achieve this access restriction?
Thank you and I apologize if this is a duplicate.
Classes in C++ are made friends in order to indicate an special intentional strong coupling between classes. This use of friend infact enhances Encapsulation rather than break it as maybe the popular feeling.
How?
Without friendship the only non-hack way to expose the functionality to other class would be to provide public, get and set member functions,this in fact breaks encapsulation because all classes(even those who don't need to) now have access to these methods and hence the members increasing the risk of potentially breaking down the class data.
Back to your situation, If you have a 100 classes which need access to this particular class, then you already had the right design in-place by having those methods as public. Now trying to make those methods private to future classes is a trying to hack your existing design, Your design does not support it.
Making the existing classes as friends does not ideally fit in the above mentioned criteria and hence is not a good choice for the scenario.
However, given the situation there is no other way in which you can implement this. Making the existing classes as friend and granting them the special access seems the only way. This is still bad because the 100 classes which only had access to the few methods will now have access to your entire class.
I think you can extract an interface of the A class (let it be IA) and make A to implement IA. You should not define those public methods in IA at all.
Then, old code will continue using A and will have access to A public methods, while new code will use restricted interface, that code would receive through some fabric .
Of cause, this can be unimplementable, if you need to (copy-)construct class, or smth like this, but I can't say it now without knowing the usage of class.
Also, you get a little overhead due to virtual functions
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.
Is it Possible to limit the functionality of class to certain objects only (in C++). What that would mean is, suppose there are 10 methods in a class and this class has 10 objects. Is it possible to have object1 & object2 access only 3 functions.
Object3, object4,object5, object6 access 6 functions.
and rest of the objects access all functions?
I am trying to implement an access control system, where general users can see only some limited functionality. Previlaged users can have little bit more access and administrators have access to all functions.
One approach is to use inheritance, something like this:
class PublicFeatures
{
public:
// add some methods here;
};
class ProtectedFeatures:public PublicFeatures
{
public:
// add some more methods here;
};
class AdminFeatures:public ProtectedFeatures
{
public:
// add rest of the methods here;
};
In this case, we instantiate objects of any of three classes depending on the kind of access level we want. But what i am thinking is having just one class, and somehow restrict the access to some methods for that particular object.
Is it possible to do such a thing? or i have to follow a different approach for implementing access control?
As far as I know, no. This is part, however, of Aspect Oriented Programming research. I saw something like what you need in this book: Aspect Oriented Software Development.
The main issue you face is the lack of knowledge of "who is the caller" of your function. You could get along by requiring each caller to call your object's methods passing this as a form of authentication about itself. Far from perfect, but with this solution you can wrap each method in a pre-method doing the ACL.
Another alternative would be to declare your implementation class totally private in terms of methods, and define a "bodyguard" class, declared friend of the first. The bodyguard class performs the calls on behalf of the caller (which is the only one authorized to do, due to the friend declaration). You still have the problem of authentication, and you are basically wrapping the whole target class behind its bodyguard object.
Class member access levels don't really have anything to do with users and security restrictions. They're really just coding constructs, not something that you can use at runtime. The compiler is either going to allow or prevent you from calling a function when it compiles your code. If it compiles your program can be run, otherwise not. There's no meaningful way to add in any kind of conditionals or application logic.
But what I am thinking is having just one class, and somehow restrict the access to some methods for that particular object.
Yes, that's what you should do. The language won't help but you can just guard calls to the methods yourself. As in, don't even attempt to call an administrative method if the user is not an admin.
if (user.isAdministrator()) {
securityLogs.archiveAndDelete();
}
else {
throw SecurityException("You can't do that!");
}
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
When should you use 'friend' in C++?
I was brushing up on my C++ (I'm a Java developer) and I came across the friend class keyword which I had forgotten about for a while. Is this one of those features that's just part of the kitchen sink, or is there a good reason for doing this rather than just a vanilla getter? I understand the difference in that it limits who can access the data, but I can't think of a scenario when this would be necessary.
Note: I've seen a similar question, but specifically I'm asking, is this just an advanced feature that adds no real value except to confuse people looking at you're code until they realize what you're doing?
I agree with the comments that say the friend keyword can improve encapsulation if used wisely. I'd just add that the most common (legitimate!) use for friend classes may be testing. You may want a tester class to have a greater degree of access than other client classes would have. A tester class could have a good reason to look at internal details that are deliberately hidden from other classes.
In my experience, the cases when friend (or mutable, which is a little similar) to actually enhance encapsulation of data are rare compared with how often it's used to break encapsulation.
It's rarely useful to me but when I do use it it's for cases in which I've had to split a class that was formerly a single class into two separate classes that need to access some common data/functionality.
Edit to respond to Outlaw Programmer's comment: We absolutely agree on this. One other option apart from friend'ing classes after splitting them is to make public accessors, which sometimes break encapsulation! I think that some people think that friendly classes somehow breaks encapsulation because they've seen it used improperly a lot, and many people probably never see code where it's been used correctly, because it's a rare thing. I like your way of stating it though - friendliness is a good middle ground between not allowing you to split up your class and making EVERYTHING accessible to the public.
Edit to respond to David Thornley: I agree that the flexibility that C++ allows you to do things like this is a result of the design decisions that went into C++. I think that's what it makes it even more important to understand what things are generally good and bad style in flexible languages. Java's perspective is that you should never have friend classes so that these aren't provided, but as C++ programmers it's our responsibility as a community to define appropriate use of these very flexible but sometimes misused language constructs.
Edit to respond to Tom: Mutable doesn't necessarily break encapsulation, but many of the uses of the mutable keyword that I've seen in real-life situations break encapsulation, because it's much more common to see people breaking encapsulation with mutable than to actually find and understand a proper use of mutable in the first place.
When you wish that one class (Factory) be responsible for creating instances of another class (Type). You can make the constructor of the Type private and thus make sure that only the Factory can create Type objects. It is useful when you wish to delegate the checks to some other class which could serve as a validator.
Just one usage scenario.
P.S. Really missing the "friend" keyword in C#...
A concrete instance would be a class factory, where you want one class to only be created through another factory class, so you make the constructors private, and the factory class a friend of the produced class.
It's kinda' like a 2" 12-point 3/4"-drive socket - not terribly common, but when you need it, you're awfully glad you have it.
Helps with Memento design pattern
The FAQ's section about friends: here
The FQA's section about friends: here
Two different points of view about friend.
I look at the friend construct as one of those features of the language that should be used in rare occasions, but that doesn't make it useless. There are several patterns that call for making friend classes, many of them already on this site in that "Related" bar on the right. ====>
Friendship is used when you have multiple classes and/or functions that work together to provide the same abstraction or interface. The classic example is implementing some kind of numerical class, and all the non-member operator functions (*, -, +, <<, etc) are given friendship so that they can work on the private data of the numerical class.
Such use cases are somewhat rare, but they do exist, and friend is very useful.
Here is one example, of several, I'm sure, where a friend class can be legitimately used without disregarding the reasons for encapsulation.
MyClass inherits from GeneralClass. MyClass has gotten big, so you created HelperClass to encapsulate some of the function of MyClass. However, HelperClass needs access to some protected functions in GeneralClass to properly perform it's function, so you make HelperClass a friend to MyClass.
This is better than exposing the protected functions, because they don't need to be available to everybody, but it helps keep your code organized in an OOP way to keep MyClass from getting too complex. It makes sense, because although HelperClass isn't concretely related to MyClass by inheritance, it does have some sort of logical connection to it, embodied in the code, and in design, as "friend".
I always ( and only ) use friend for unit testing private methods. The only other way I can imagine to do this would be to load up the public interface with a whole lot of testing methods, which is just too messy and so I prefer to hide the test methods in a seperate test class.
Something like this:
class cMyClassTest;
class cMyClass
{
public:
.....
private:
friend cMyClassTest;
int calc(); // tricky algorithm, test carefully
};
class cMyClassTest
{
public:
int test_calc()
{
cMyClass test;
....
int result = test.calc();
if( result == 42 )
return 1;
return 0;
}
};
friend class mean we all know that is acesss the value of variable from other class so it is mainly used for use the values so we no need to return the value of other class to main function then main to needed class member function but it having the problem that is a class is friend for other class then friend class should be in below of that class