#include <iostream>
#include <conio.h>
using namespace std;
class Dog
{
public:
void setAge(int age); //setters
void setWeight(int weight);
void setColour(string colour);
int getAge(); //getters
int getWeight();
string getColour();
void bark();
private:
int age; //store data
int weight;
string colour;
};
void Dog::setAge(int age)
{
this -> age = age;
}
void Dog::setWeight(int weight)
{
this -> weight = weight;
}
void Dog::setColour(string colour)
{
this -> colour = colour;
}
int Dog::getAge()
{
return age;
}
int Dog::getWeight()
{
return weight;
}
string Dog::getColour()
{
return colour;
}
void Dog::bark()
{
cout << "WOOF!\n";
}
int main()
{
Dog Fido;
Fido.setAge(3);
Fido.setWeight(15);
Fido.setColour("black");
cout << "Fido is " << Fido.getAge() << " years old\n";
cout << "Fido weighs " << Fido.getWeight() << " kg\n";
cout << "Fido is a " << Fido.getColour() << " dog\n";
getch();
return 0;
}
Private Class Members
Can someone explain in greater detail what the "this ->" is, and the benefits of storing data privately, thanks.
"this" is a pointer to the current object. It is implicity included whenever you refer to member variables inside member functions. "this->" is a shortcut for "(*this).". Using a private member ensures that only the class itself can use the member. This reduces programmer error (the compiler will spit out a nasty error at you if you try to access the member outside of the class).
To elaborate, due to the member variable and the method parameter 'age' being named the same, the writer of that code just wanted to make it clear that the parameter age was being assigned to the member variable age.
1. Use [ source ] instead of
, it gives a nicer window.<br><br>2. Member functions in C++ have what is called an "implicit this pointer", which is, the object that the function is being called on. So the function:<br><br><pre>void Dog::setAge( int age )</pre><br><br>is a function in the Dog class, but you'd call it on a Dog object. Within the function, you can access members of that particular Dog directly. The this-> notation simply makes it explicit, to state that the variable you are accessing is the one belonging to the object the function has been called on - you could remove the this-> and it would still work fine. However, some people like to use this-> as it makes it obvious (and, when you type this-> in an IDE, Intellisense offers you a list of members).<br><br><b>Edit</b>: looking at the code, in this case removing this-> might not work fine! It's <i>usually</i> used only for emphasis, but here, as the class data members and the function parameters have the same name, the this-> is necessary to identify which parameter is being used. So:<br><br>this->age = age;<br><br>is saying, "set the age of the current object to the age that we've just been given." Sorry for the confusion.<br><br>For this reason, it's a common convention to prefix class data members with m_, for example m_age.<br><br>3. Storing data privately helps with encapsulation. This is also known as "data hiding", because clients that use your class do not need to know the internal layout of it in order to use it. To continue with the dog example, age is stored as an int. Suppose you decided it would be better stored as a short or unsigned char - you could change the underlying type, while the external getAge() function would still look exactly the same.<br><br>In a more complex class, making the data private prevents others from editing things they shouldn't. If your class was a Car, for example, and others were freely able to edit the RemainingFuel data member, things would very quickly get out of control as anyone could set the fuel level to whatever they wanted. Instead, you might make RemainingFuel private, and publicly offer a GetRemainingFuel() function so people could find out how much fuel was left, but probably not a SetRemainingFuel() function - it wouldn't make much sense, you'd have something like Refuel() instead.<br><br>Encapsulation and data hiding are very powerful techniques that are invaluable in reducing the complexity of a class's outward appearance (it's interface), this makes working with the class much simpler and easier (and often, more correct).
From a quick scan of the code, I think perhaps part of the mystery of private encapsulation may come from the rather confusing fact that for each data member, you have had to provide a get() and set() function. Looked at in these terms, it does appear to cause more work than benefits.
This is typically not the best way to take advantage of using objects as a programming paradign. Generally with a good object design, the methods of a class describe actions rather than just access data.
For example, in your example you need to ask the question - Why do I need to know the age of the dog? Why do I need to know its weight?
In this simple example, it is purely to output the dog's details. If this were the only requirement, this entire action would be better expressed as a method of its own right (there are nicer ways of doing this by providing a << operator for the ostream, but that would just muddy the discussion in my view):
Using this approach, you could add a whole new attribute to Dog, say Color, and only need update the Output() method of Dog, which is kind of local when you add the Color attribute, and all the code that uses Dog remains unchanged.
The fundamental idea, if this is not a bit too textbook, is that a class should present an interface that does not depend upon the implementation of the interface. Having data private means that any attempts to directly access the implementation of the class can be stopped by the compiler with meaningful error messages.
However, this is a large topic and my answer is very simplistic.
This is typically not the best way to take advantage of using objects as a programming paradign. Generally with a good object design, the methods of a class describe actions rather than just access data.
For example, in your example you need to ask the question - Why do I need to know the age of the dog? Why do I need to know its weight?
In this simple example, it is purely to output the dog's details. If this were the only requirement, this entire action would be better expressed as a method of its own right (there are nicer ways of doing this by providing a << operator for the ostream, but that would just muddy the discussion in my view):
class Dog{private: int Age,Weight;public: Dog(int A=1,int W=10) : Age(A),Weight(W) { } void Output();};void Dog::Output(){ std::cout << "I am " << Age << " years old and weigh " << Weight << ".\n";}int main(){ Dog D(4,23); D.Output(); }
Using this approach, you could add a whole new attribute to Dog, say Color, and only need update the Output() method of Dog, which is kind of local when you add the Color attribute, and all the code that uses Dog remains unchanged.
The fundamental idea, if this is not a bit too textbook, is that a class should present an interface that does not depend upon the implementation of the interface. Having data private means that any attempts to directly access the implementation of the class can be stopped by the compiler with meaningful error messages.
However, this is a large topic and my answer is very simplistic.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement