Thread: some design questions

Hello

Im unsure about next situations:

Code:

class test {
public:
  int someint() { return m_someint; }
private:
  int m_someint;
};

When I want to access m_someint from the test class I would just do m_someint and if I want to access it from another class I would do some_test_object.someint();

Is this a 'good' way? What do you guys do in this situation?


Another question:

Suppose I have some class and I want to modify/change some data in it:

Code:

class someclass {
private:
  int m_somedata;
public:
  void set_somedata(int i) { m_somedata = i }
};

I have seen a lot of code that uses special method/function to change data this way:
set_somedata(20);
But I prefer accessing m_somedata directly (so I'd set class that wants to access data as a friend), because I dont like writing new function for each data object..

What do you think about that?

It only makes sense to have set functions if your class needs a way for unrelated code to set those values individually.

Don't add a set function just for the internal class to use unless it does something different than just set the variable.

If you add a set function because external code needs to set those variables, and you end up with a bunch of them, it's ok (although if you have too many then you may be able to combine some in their own class).

Originally Posted by Daved

although if you have too many then you may be able to combine some in their own class.

Can you be please more specific about that?


Another question:

If I decide to use set/get functions from now on, is it okay to define them in a header? Will that affect my application's size?

Originally Posted by l2u

Would you also use set/get functions if you call it from a local/parent class (class test in this case) ? That doesnt make much sense though.

Well, in the end it's really all about what you're comfortable with. This is the type of thing that really won't hurt your program in one way or another. If you are the only one that will be working on a project and you are more comfortable with using the variables then that's fine.

And here's some examples of how it would be used in code just to get an idea of how it looks outside the class declaration:

Code:

person.setAge(21);
if(person.getAge() >= 21) drink = true;

// or

person.age = 21;
if(person.age >= 21) drink = true;

As you can see, both ways will have the exact same result. It's just a question of what is easier to read. Something to consider in this is what if later you need to add more data to the age. Perhaps you want to store the birthday also. If you have to change the way age is stored, you will simply just change the getAge() and setAge() functions. However if you are using the second method, you may end up getting rid of the age variable and putting it into some data structure. Then you would have to go back and change all the instances of person.age.

Hope that made sense

Originally Posted by l2u

Would you also use set/get functions if you call it from a local/parent class (class test in this case) ? That doesnt make much sense though.

If setting/getting some value is always accompanied by some other operation, even when the object itself does it, then the object should call the set/get function. If you are even remotely unsure whether you will add such code in the future, just make it easy and use the setter/getter function so that if it does change, everything stays correct.

However, if your setter/getter functions do nothing but set/get the value of a variable, and nothing else, and you do not expect your implementation to change (perhaps because it's obvious, or incredibly simple), then it might be better to expose those variables as publics instead. But that's a dramatic decision to make, one you shouldn't make unless you're sure.

>> Can you be please more specific about that?

For example, if you have a customer class that includes name, ID, street address, city, state, zip, country and other fields, you might realize that the combination of street address, city, state, zip and country are an address by themselves. So you create an address class that encapsulates that concept and have the customer class contain an address instance.

Similarly, if you notice you have two copies of each of those values, one for mailing and one for billing, then you can combine them into address and have the customer class contain a mailing address variable and a billing address variable.

It only makes sense to combine member variables into a new object if they logically combine to form an object. However, when you have lots of member variables you can often find such a case.

So lets say I have a class with some container member. Now I want to push_back element to this container from another class..

It would be logicaly to make a new function for each thing I want to do with this container if I would have get/set methods for other things as well..

For instance (set function in a customer class):

Code:

void add_customer_nickname(std::string &str) {
vector.push_back(str);
}

..or would you do it differently?

There have been quite some good arguments why to use get/set methods I think, thats why I'm going to use them in a future.

>> It would be logicaly to make a new function for each thing I want to do with this container
Yes it would, as long as you are exposing things that it makes sense for external code to do.

>> There have been quite some good arguments why to use get/set methods I think, thats why I'm going to use them in a future.

I thought you were asking about using get and set functions when accessing member variables from inside the class?

Originally Posted by Daved

>> It would be logicaly to make a new function for each thing I want to do with this container
Yes it would, as long as you are exposing things that it makes sense for external code to do.

Have been thinking - doesnt in this case returning container's reference make more sense since container/s have all the methods already in place and cannot be modified?

Originally Posted by Daved

I thought you were asking about using get and set functions when accessing member variables from inside the class?

From inside the class and from the other classes.

>> From inside the class and from the other classes.

Ok. A set function is usually better than making a member public when deciding how to expose the data to users of the class. From inside the class, if you already have the set function, then using it is fine and often makes sense. Creating a simple set function for use solely within the class makes little sense to me.

>> doesnt in this case returning container's reference make more sense since container/s
>> have all the methods already in place and cannot be modified?

No, because you don't want the outside code to be able to have access to all those methods (in most cases). That's encapsulation. Your object is using a container to hold some data, and your class should decide how that data can be read and manipulated. If you expose the entire container, you no longer have any control over the data.

Expose only those operations that make sense to the user of the class, and do so behind a sensible interface. Which container you use is an implementation issue and the user of the class should only program to the interface.