Jump to content
  • Advertisement
Sign in to follow this  
Meta Adam

Why not make everything public in a class?

This topic is 5013 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
Consider a string class which does keep track of its length. You want that length to be modified by operations that affect the contents of the string, but you don't want people to arbitrarily modify that field, possibly to invalid values, making it inconsistent with the actual text the string contains.

Some other times, you will have broken down a class operation into multiple, elementary functions. You probably don't want people to call those functions (they might need to be called in a specific order, under specific conditions...), but only those which are properly part of the class interface.


Making things private is thus a way to protect your class invariant, as well as hiding implementation details by forcing people to use a specified interface (Encapsulation).

If your class is just a data holder with no invariant to preserve, making everything public is perfectly fine. Protected really means "public to derived classes", so the principles above still hold, just for a different audience.

Share this post


Link to post
Share on other sites
Sometimes you aren't the only person that modifies code that you have written. If that was the case then perhaps it wouldn't matter. But one reason I can think to make it private is to ensure your data is only accessed through a set method that you write therefore prohibiting that variable from being assigned certain values. Let's say you have a class:

class Student{

private age;

public setAge(int a){
if(a<0)
age = 1;
else
age = a;
}
}

Now without the private accessibility anyone reusing your code could simply make an object of the student class:

Student stud = new Student();

and then set age like:

stud.age = -5; //wrong!

Since age is private he is forced to modify it with the public setAge method ensuring it is never negative.

stud.setAge(-5); //age variable set to 0

That's one example I can think of. I am sure there is a lot of technical jargon that could better explain good software design principles but that's how I understand it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Meta Adam
The name says it all..
Why make something private or protected in a class?


Another way to think about is if you make an analogy between a class and your life - would you really want everything public for your parents as well as others [smile]. With that said I agree with HughG and Fruny. Moreso with silly analogy's, since im on a roll [lol], think about all your money as being a class - would you let everyone know how much you had and that they could use it however they like?

Just a few examples. I hope it helps!

- Drew

Share this post


Link to post
Share on other sites
Thanks for your replies. =)
Is this the right way to use it though?

class dog {
private:
int age, height, weight;
public:
int set_age(int) {
int dogage = age;
};
void bark() {
cout<<"Bark bark"<<endl;
};
int set_height(int) {
int dogheight = height;
};
int set_weight(int) {
int dogweight = weight;
};
dog();
~dog();
}


p.s. I forgot how to post code the right way.. what are the tags for it?

[Edited by - Meta Adam on January 3, 2005 9:23:11 PM]

Share this post


Link to post
Share on other sites
Those set/get functions are commonly referred to as setters/getters. In your example it doesn't make much sense to return anying but void (unless you're doing error checking, in which case you may want to return a 1 if the set was succesful and a 0 otherwise.) The thing about setters/getters to watch out for is making sure they don't unnecessarily overcomplicate your code. Fruny's example is a good case where using setter/getter functions would be a good idea, because you don't want someone changing the string without the size variable changing as well (afterall, this may break code). Just keep that in mind when designing classes and you'll be fine. The string class is really good candidate for operating overloading, because you'll be able to use normal symbols (+, =, ==, etc), but they'll actually be calling an overloaded function which can do anything you want them to do.

Share this post


Link to post
Share on other sites
Yea, but i dont understand why it couldnt just be:

#include <iostream>
using namespace std;
class dog {
public:
int age;
int weight;
int height;
void bark();
{cout<<"bark bark."<<endl;}
}
int main() {
dog fido;
fido.age = 4;
fido.weight = 5;
fido.height = 14;
cout<<fido.age<<fido.weight<<fido.height<<endl;
bark();
return 0; }

Share this post


Link to post
Share on other sites
generally I don't bother with get/set. A single overloaded access function for each property is enough:
int age();
void age(int);
Also since the majority of my classes seem to be public access, & I always inherit public - I use structs instead of classes.
Only difference with structs is that they are public by default (whereas classes are private)

Share this post


Link to post
Share on other sites
Quote:
Original post by Meta Adam
some code


dogage, dogheight and dogweight only exists in those functions you still have no way of setting age, height and weight(well at least I think you don't). This is probably what you are looking for:


class dog {
private:
int age, height, weight;
public:
void set_age(int dogage) {
age = dogage;
};
void bark() {
cout<< "Bark bark" << endl;
};
void set_height(int dogheight) {
height = dogheight;
};
void set_weight(int dogweight) {
weight = dogweight;
};
//I've added these. You need some way to access your private data too.
int get_age() {
return age;
};
int get_height() {
return height;
};
int get_weight() {
return weight;
};

dog();
~dog();
}



Quote:
Original post by Meta Adam
p.s. I forgot how to post code the right way.. what are the tags for it?

[ source ] and [ /source ] (without spaces)

EDIT: Damn you people post fast

Share this post


Link to post
Share on other sites
Quote:

Yea, but i dont understand why it couldnt just be..


One of the issues is you're seeing fairly simple examples (and one could argue that the classes you're presenting aren't really classes, just collections of data). However, keeping the accessor / mutator (sounds so much cooler that getter / setter) theme running...

Say you're programming an RTS. Each unit has a public health field. Everytime something damages a unit, it has code like this:

tank.health -= 10

Half way through your development you decide that units that are damaged more than 50% have reduced speed. Now you have to go through your code and find all 3-gazillion occurences of the above code, and add:

if(tank.health < tank.maxhealth/2)
tank.speed /= 2;

Instead, if you had a mutator, you'd just change the code in the mutator (ie in one place), and every single occurence now does the right thing.

HTH,
Jim.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!