Managed classes have one other feature you might want to use: properties. You have probably written classes like this: class Employee { private: int salary; //dollars // remaining member variables public: int getSalary() {return salary;} void setSalary(int s) {salary = s;} // remaining public methods }; Even with slightly more complicated code for setSalary() , with some kind of error checking, the basic concept is the sameit's a private variable with public get and set functions. Not every variable is treated like this, of course: A bank balance, for example, shouldn't be settable from outside, but should instead be changed by various business operations such as deposits and withdrawals. But many classes follow this "get and set" paradigm. The benefit to this, of course, is encapsulation. You are free to add error checking to either the get or the set method after your system is partially built or in a follow-on phase. You can even change the type of the variable and simply adjust the code to reflect the change. Encapsulation is a great thing, and no wise programmer will give it up. The downside is the way your code looks when you're using get and set functions. If you have a pointer to an instance of the Employee class, e , and you want to give that employee a $5000.00 raise, here's the code: e->setSalary(e->getSalary() + 5000); That works, but it's not exactly pretty. But in the .NET Framework, you can have your cake and eat it too. You just have to change your definition of Employee slightly (the changes are shown in bold): __gc class Employee { private: int salary; //dollars // remaining member variables public: __ property int get_Salary() {return salary;} __ property void set_Salary(int s) {salary = s;} // remaining public methods }; Now the class has a Salary property. It's directly tied to the salary member variable, but there's no requirement that it should be, and in fact the name of the property cannot be exactly the same as the name of a member variable, which is why in the Employee class, the property name (which appears after the get_ and set_ of the function names ) is Salary and the member variable is salary . To use the property, you write code that treats it like a public member variable: e->Salary = 10000; e->Salary = e->Salary + 5000; You can use any of the familiar C++ operators with a property: e->Salary += 5000; Yet behind the scenes, your get and set functions, with all their attendant error checking, are being called. You have all the benefits of encapsulation, yet your code is as easy to read as if all your member variables were public. |