I'm trying to declare a vector containing user objects in the header file, but I'm unsure of how to use the setter and getter functions to push values objects back to the vector or call them again.
class userbase
{
public:
userbase();
virtual ~userbase();
//FUNCTION DECLARATIONS
void record_User(user);
void setUserVector(vector<user> const &newUser) {
//userbase_V = newUser;
userbase_V.push_back(newUser);
}
vector<user> const &getUservector() const {
return userbase_V;
}
protected:
private:
vector <user> userbase_V;
};
Getters/setters are quite often misunderstood. The aim of using such functions is encapsulation which means restricting access to your data or exposing certain functions.
The reason why we don't make private members public in the first place is because there are some operations that we don't want users of our class to perform.
Consider the following class:
class userbase
{
public:
vector<user> users;
};
Let's say the goal of the userbase class is to manage a loyal, unwavering list of followers of an application. And since users is a public member, we can do whatever we want with it:
class company
{
public:
void massacre()
{
m_userbase.users.clear(); // Aaaaahhh!!!
}
private:
userbase m_userbase;
};
What? Where did all our loyal, unwavering followers go? We can't just remove our users!
The company class has access to all of std::vector's functionality on m_userbase.users. But really, from userbase's point of view, we don't want the outside to access particular functions (in this case, clear() or erase()). We want to restrict what operations can be performed (modifiers) and what attributes can retrieved (accessors). That is, we want to encapsulate the users vector.
Making userbase a private member is the first step:
class userbase
{
private:
vector<user> users;
};
Now let's add some naive "encapsulation" to see if it solves our problem. (This is where a lot of misunderstanding stems from.)
Here's our new class:
class userbase
{
public:
void setUsers(vector<user> const& newUsers) {
users = newUsers;
}
vector<user> const& getUsers() const {
return users;
}
private:
vector<user> users;
}
Can the company still clear the users vector directly? Yes.
class company
{
public:
void massacre()
{
auto users = m_userbase.getUsers();
users.clear();
m_userbase.setUsers(users); // Aaaaahhh!!!
// or simply create a new vector with no data
m_userbase.setUsers(std::vector<user>{}); // Aaaaahhh!!!
}
private:
userbase m_userbase;
};
So simply providing getters/setters doesn't solve the issue.
The common approach is to instead approach it the other way around. Instead of asking "What don't I want the outside to do?", ask "What do I want to allow the outside to do?". This way, you can figure what sort of functionality to expose. This is part of designing a good API.
Maybe our API wants to be able to: add a user, get a user's name, and count the number of users. Then we would design a class like this:
class userbase
{
public:
/// modifiers:
// Add a user to the userbase.
void addUser(User const& user);
/// accessors:
// Returns the user's name given its index.
string getUserName(size_t index) const;
// Returns the number of users belonging to this userbase.
size_t numberOfUsers() const;
private:
vector<user> m_users;
};
The takeaway is: it's up to you to decide what "the outside" can or can't do with its members. You'll need to spend more time thinking and less time writing code, but this is normal.
Further reading:
Why use getter and setters? (A good read even though it's tagged with Java.)
Related
Currently I am working on a project where I want to control a model train for a nice showcase.
I have multiple locomotives which all have a unique address (just think of it as a UUID). Some locomotives have a headlight, some of them have a flashing light, some have both and some of them have none.
My base class is this:
class GenericLocomotive : public Nameable, public Describable {
private:
uint16_t address;
public:
GenericLocomotive(const char* name, const char* description, uint16_t address);
void setFunction(uint8_t command, bool val);
Now I want to have a different class which provides the functionality to enable and disable the headlight:
class HasHeadLight {
public:
void activateHeadlight();
void deactivateHeadlight();
}
My goal is to have a specific class for every locomotive (with different functionality) which looks something like this:
class <SpecificLocomotive> : public GenericLocomotive, public HasHeadlight, public HasFlashlight,... {
...
}
The problem is, that I must have access to the private field 'address' of my GenericLocomotive class and I also have to call the function setFunction(...) from my HasHeadlight class.
I am quite new to C++ and just found out about the concept of friend classes and methods, but I can not quite get it to work, because even with the declaration of the method setFunction(...) as a friend, I can not just call something like
this->setFunction(HEADLIGHT_COMMAND, true);
from my HasHeadlight-class, because the function is not declared in 'this'.
How can I access the method from my other class? Is this friend thing even needed or is there a completely different way to structure my C++ program?
You have misunderstood how class inheritance works:
Inheritance establishes an is-a relationship between a parent and a child. The is-a relationship is typically stated as as a specialization relationship, i.e., child is-a parent.
There are many ways you can tackle what you want to achieve here, but this is not it. You're on the right track as far as treating the different train components as separate objects, and one way to achieve that would be to instead make each component a member of the specialized locomotive:
class HeadLight {
public:
void activateHeadlight();
void deactivateHeadlight();
}
class SpecialLocomotive : public GenericLocomotive {
HeadLight mHeadlight;
Flashlight mFlashlight;
public:
SpecialLocomotive(const char* name, const char* description, uint16_t address)
: GenericLocomotive(name, description, address) {
setFunction(HEADLIGHT_COMMAND, true);
}
void toggleLight(bool on) {
if (on) {
mHeadlight.activateHeadlight();
} else {
mHeadlight.void deactivateHeadlight();
}
}
/* so on and so forth /*
}
There's not enough details to go further with it. If you need to call setFunction from within Headlight, I would consider that a poor design choice, but there are other ways.
Lets say we have some association, modeled as a class, which has several bank accounts on which it accepts donations. The public can donate to each of these, or get a list of all bank accounts from the charity, pick one, and then donate directly to some specified account.
Of course, the association will only return a const& to its bank accounts so that the public cannot arbitrarily change (or even replace) them. But it would still be nice that - after getting the const& to the accounts and then picking one (by index), a user will be directly able to donate to the account - i.e using a member method of the account, and not having to go back to the association itself, remember the number of account, etc.
I came up with the following solution, which seems to work:
namespace detail {
class VirtualAssociation {
public:
virtual void donate(size_t account_number, int amount) = 0;
};
}
class DonationsAccount {
public:
DonationsAccount(detail::VirtualAssociation* association, size_t account_number) :
_association(association), _account_number(account_number), _money(0) {}
/*! put some money on this account. Of course not const */
void put(int amount) {_money += amount;}
/*! Donate some money. Will be const, but actually does the same as the put() method*/
void donate(int amount) const {_association->donate(_account_number, amount); }
/*! Get balance of this account */
int balance() const {return _money; }
private:
detail::VirtualAssociation* _association;
size_t _account_number;
int _money;
};
class Association : public detail::VirtualAssociation {
public:
Association() : _accounts() {_accounts.emplace_back(this, 0); }
/*! Donate some money on a certain account of this association */
void donate(size_t account_number, int amount) override {_accounts[account_number].put(amount); }
/*! Get the list of accounts of this association */
const std::vector<DonationsAccount>& accounts() const {return _accounts; }
private:
std::vector<DonationsAccount> _accounts;
};
int main() {
Association association;
association.donate(0,10);
// association.accounts()[0].put(); //illegal, because put is a non-const method
association.accounts()[0].donate(5);
std::cout << "Balance on account 0: " << association.accounts()[0].balance() << std::endl;
return 0;
}
gcc compiles this with no warnings, and i also get the correct print output of 15. But of course this feels like an ugly workaround, so my questions are
Does the above yield undefined behaviour? At least we (indirectly) change the object state of an association when calling a const-classified method.
In case this is undefined behaviour: will this be defined again if I declare the _money attribute of the DonationsAccount to be mutable? Could you expand on what mutable exactly does and why it helps (if it does)?
Is there a better way to achieve the above behaviour?
For further clarification, some remarks:
I am not actually dealing with accounts etc, this is just a made up example that semantically (more or less) fits. So this is not about security etc, but const-correctness of my program
To be more concrete, the Association in above example corresponds to some graph managing (and owning) nodes and edges. Nodes and edges don't exist outside of a graph, since this would be semantically meaningless. I want to grant users access to the nodes of this graph (stored in a vector), but of course not allow the user to just swap out this vector etc, so I return a const reference. It would however still make sense that the user can call stuff like "add an edge" on certain nodes, since I can control these semantically correct operations on nodes and ensure things like range-checking etc, which is handled by the graph itself.
So essentially, I would like to return a reference that is not const (since we want to allow for adding edges etc), but has a state that forbids stuff like assignment / deletion / moving the object away, but allows certain methods like "add an edge", "remove node" (this will have side effects on the graph that have to be controlled, thus this is different from just deleting the node)
Say I have the following classes:
class Car
{
...
public:
void drive(Direction direction);
void open_door();
void refuel();
double get_speed();
...
};
class SelfDrivingCar: public Car
{
CarDrivingProgram *driving_program;
...
};
class CarDrivingProgram
{
public:
virtual void drive_car(Car *car) = 0;
};
class ExampleCarDrivingProgram: public CarDrivingProgram
{
void drive_car(Car *car) override;
...
};
SelfDrivingCar is a Car in every way except the user is forbidden from manually driving it. Instead, CarDrivingProgram drives it via drive_car(...). Using public inheritance seems correct because most operations on a Car could also happen to a SelfDrivingCar. For example, the user might create an array of Cars and then refuel all the Cars in the array, some of which happen to be SelfDrivingCars.
However, using public inheritance exposes the drive(...) method, which the user should not call on a SelfDrivingCar.
One solution would be to make the drive(...) method private in SelfDrivingCar, but that's messy, requires all CarDrivingPrograms to be friends in order to access drive(...), and can be circumvented if the user casts a SelfDrivingCar to a Car and then calls drive(...) from the Car.
Another solution would be to keep a boolean flag that indicates whether a Car is currently allowed to be driven or not and printing an error if drive(...) is called when the flag is set to "false". For a SelfDrivingCar, this flag would be "false" for most of the time, and CarDrivingProgram would temporarily set this to "true" for the duration of drive_car(...). However, this catches mistakes at runtime rather than at compile time, and the user can still toggle the flag and drive a SelfDrivingCar manually if they really want to.
Using protected/private inheritance would be another solution, but that prevents the user from doing something like adding SelfDrivingCars to an array of Cars that are to be later refuelled (described earlier).
How do I cleanly forbid the user from calling drive() on a SelfDrivingCar, ideally catching things at compile thing?
For clarification: The SelfDrivingCar class still needs a drive(...) function or something like it because CarDrivingProgram needs a way to tell SelfDrivingCar the direction to drive in. CarDrivingPrograms can drive any Car, not just SelfDrivingCars. I want CarDrivingProgram to be able to drive SelfDrivingCars but for the user to be unable to. For example, the user could have an array of pairs of CarDrivingPrograms and Cars, and call carDrivingProgram[i]->drive_car(car[i]) for each pair. I could make all CarDrivingPrograms friends but that's messy.
You could do something like this:
class Car {
...
public:
void open_door();
void refuel();
double get_speed();
...
};
class NormalCar: public Car{
public:
void drive(Direction direction);
};
class SelfDrivingCar: public Car
{
CarDrivingProgram *driving_program;
...
};
This is a very clean way. When there are no reasons you can't introduce another class, this should be fine. You can still store them in an array and refuel them.
When SelfDrivingCar is a Car that can drive, you can make it a Car and call the function (like TheUndeadFish mentioned in his comment). But you can't make a SelfDrivingCar a NormalCar.
I have this class:
class Phone {
private:
string producer, color;
int weight, dimension;
public:
Phone(string &producer, string &color, int &weight, int &dimension):
producer(producer), color(color), weight(weight), dimension(dimension) {};
Phone():
producer(""), color(""), weight(0), dimension(0) {};
virtual ~Phone() {};
string getProducer(void) const;
string getColor(void) const;
int getWeight(void) const;
int getDimension(void) const;
virtual void displayInfo(void) const;
};
The problem is here caused by the fact that I expose the internal implementation of the object via getters.
But how can I prevent this?
Because usually in my code, I need to know some private data from my object (for comparision is one example), and that's why I use getters.
So then I rewrite the class to something like this:
class Phone {
private:
string producer, color;
int weight, dimension;
public:
Phone(string &producer, string &color, int &weight, int &dimension):
producer(producer), color(color), weight(weight), dimension(dimension) {};
Phone():
producer(""), color(""), weight(0), dimension(0) {};
virtual ~Phone() {};
bool isTheProducer(string& producer) const { return this->producer == producer };
bool hasWeight(int& weight) const { return this->weight == weight };
bool hasDimension(int& dimension) const { return this->dimension == dimension };
virtual void displayInfo(void) const;
};
Is this a better design (by the fact that I don't get the actual private value)?
As you might have seen from the other answers and comments, the answer is: It depends.
In fact, it depends mainly on the usecases where your class is used. Let's stick first to the example given in the question, the comparison of objects. Since it is not clearly visible from the question if we want to compare two phone objects or just a specific data member I will discuss both situations here.
Comparing a data member to out-of-class data
Let's take this usecase where we search for all phones with a weight bigger than x(just pseudocode):
for (Phone& p in phoneList) {
if (p.getWeight() > x) {
cout << "Found";
}
}
Then the first class example is perfectly fine, since this is not an intrinsic feature of the phone, and thus the phone class is not responsible for handling it. In addition, the result does not expose more than absolutely required for the task.
Comparing two phone objects
In this case both code examples are equally good (or in this case equally bad). In both cases the user has to know a lot of details about how phones are represented to compare all necessary members. If in a later revision a new member is added to the class, every code segment that compares two phones has to be adapted. To overcome this, one can add a function to the class that does exactly the comparison.
class Phone {
private:
string producer, color;
int weight, dimension;
public:
bool IsEqualTo(const Phone& other)
{
return (producer == other.producer && color == other.color &&....);
}
Non comparitive usecase
But let's go to a more advanced example. Let's assume the following task: A user enters the pin to a phone and if it is the correct one, the phone should unlock. Let's assume a very naive approach:
class Phone
{
private:
int pin;
bool unlocked;
public:
int getPin() { return pin; }
void unlock() { unlocked = true; }
};
and the corresponding call
if (phone.getPin() == enteredPin)
phone.unlock();
In this case we have a totally different situation. Here we need to consider the "tell, don't ask" rule, which basically says that it is a bad design to query the state of an object first, make a decision and then tell the object what to do. Instead we should only tell the object what we want, and let it do the work for us. In this usecase this is obvious, since unlocking the phone only when the pin is correct is a responsibility of the phone, not of the user that uses the phone class. But in more complex scenarious many programmers will do exactly what I described here.
Back to the problem: A good solution here would be for example
class Phone
{
private:
int pin;
bool unlocked;
public:
void CheckPin(int enteredPin) {
if (pin == enteredPin)
unlocked = true;
}
};
with the code
phone.CheckPin(enteredPin);
Hope this helps, and thanks to #KonradRudolph for pointing to the "tell, don't ask rule". Feel free to help me to improve the answer per commenting on it :)
The first one, even with getter, is encapsulated. Consider the color() method, which returns a string. Even if you change the implementation of Phone such that you store the color as an enum rather than a string, your method can still return a string if you do some sort of conversion first. The important part is that you can change the implementation of color() and the underlying storage without users of the class needing to change.
Compare to a class that stores color as a publicly accessible string. If you later change the data member to an enum, you need to modify every location that uses the color. This is less of a property of encapsulation and more a property of separating interface from implementation.
Encapsulation allows controlling of attributes exclusively via methods within the class. Both examples are encapsulated.
Consider the below C++ code
class B;
class A{
private:
B* mB;
};
class B{
private:
doSomethingImportant();
};
We have a Object A that contains (has a) Object B. The parent being A and child being B. Now if I want A to make B do doSomethingImportant() , I see that adding A as a friend of B is the only way to do it.
friend class A inside class B. This would enable A's functions to access B's private function.
I find this approach a little weird since creates a loophole in the Data_Hiding concept. Is there a better way to establish a parent-child relationship between the object ? or is this the best way ?
Adding my actual motivation for this question
class elevator{
private:
//The Lift box the elevator controls
liftboxControlUnit & mLiftBoxCtrlUnit;
//constructor
elevator(int Level=1, int NoOfBanks =1 );
//Destructor
~elevator();
//Triggers the search to move to the next floor if required
void moveLiftToNext();
public:
//Adds request to the queue
void addRequest(int FloorNumber){
//Add the request to the queue. The single button outside the elevator door
mLiftBoxCtrlUnit.addRequest(FloorNumber);
}
//For Emergency. Should be accessible to everyone !
void setEmergency();
void unsetEmergency();
};
typedef enum Direction{
UP,
DOWN
}direction;
class liftboxControlUnit{
private:
//The request for various floors
set<int> mRequestQueue;
//The various banks for the whole system
vector<Bank> mBanks;
//The total number of levels. Remains the same for one building
const int mTotalLevel;
//Instruction to move the box to certain level
void processRequest(){
//Do the logic to move the box.
}
//can passed to the elevator
void addRequest(int x){
mRequestQueue.insert(x);
}
//Can be set by elevator class
void setEmergency(){
//Do the required
//Set Emergency on all Banks
}
void unsetEmergency(){
//UnsetEmegency on all banks
}
void emergencyListener(){
//Listen to all the banks if emergency has been set
}
void BankFreeListener(){
//Listen to the banks if any is free
//If so then
processRequest();
}
public:
//Constructor
liftboxControlUnit(int TotalLevels, int NoOfBanks): mTotalLevel(TotalLevels){
for(int i=0 ; i lessthan NoOfBanks; ++ i)
mBanks.push_back(Bank(0,UP));
}
friend class elevator;
};
class Bank{
private:
//The dailpad inside the bank
dailpad & mpad;
//Current Location
int mPresentLevel;
//Current direction of movement
direction mDirection;
//Currently moving
bool mEngaged;
//Manipulate the bank
void move(int NoOfMoves){
setEngaged();
//Move the elevator
unsetEngaged();
}
//getters
int getPresentLevel() const;
int getDirection() const;
//setters
void setPresentLevel(int);
void setDirection(direction);
//Manipulate the engaged flag
bool isEngaged() const;
bool setEngaged();
bool unsetEngaged();
//For emergency
void reset();
//Dailpad Listener
void dailpadListener(){
}
public:
Bank(int StartingLevel, direction Direction): mPresentLevel(StartingLevel),
mDirection(Direction),
mEngaged(false),
mpad()
{
}
//For emergency . Should be available for all.
void SetEmergency();
void UnsetEmergency();
bool isEmergency();
friend class liftboxControlUnit;
};
class dailpad{
private:
//Some DS to represent the state . probably a 2D Array.
void renderDisplay();
public:
//Constructor
dailpad();
void getCommand(int x){
//Depending on the value we can do the following
//Make necessary changes to the display
renderDisplay();
}
friend class Bank;
};
IMO, for this task you should probably nest the "lift box" class inside of the controller class:
class lift_controller {
class lift_box {
open_doors();
close_doors();
move_to_floor();
};
std::vector<lift_box> bank;
};
To the outside world, there need be no evidence that lift_box exists at all. It communicates exclusively with the lift_controller, and all outside communication with a lift_box goes through the lift_controller.
In this case (only lift_controller has access to lift_box at all), it seems clear (at least to me) that any operations the lift_controller may need to invoke on a lift_box should just be made public functions of lift_box. To enforce nobody else having access to lift_box, ensure that the definition of lift_box is in the private: section of lift_controller.
Edit: I should add that quite a bit of the design you've edited into your question above makes little or no sense to me. Just for example, you have things like direction and present level for the bank. Unless I'm completely misunderstanding what you mean by a bank, this seems like a clear error to me -- the bank isn't at a particular level or moving in a particular direction. Rather, each individual elevator in the bank is at some level and (potentially) moving in some direction.
You seem to want class A to only be able to access one private function in B, B::doSomethingImportant() and no other private functions.
This usually means that B::doSomethingImportant() should really be public. Like this, A will not be able to access other private data members of B.
Further, if you do not want other classes to access B::doSomethingImportant(), they should not hold a pointer to B but instead, a hold a pointer to an interface (abstract super class) of B that does not expose B::doSomethingImportant().
Or perhaps other classes only read data from B. In that case they can hold B const * which will not allow them to call B::doSomethingImportant() unless they do a const_cast.