I know,
Let me clarify. What I am trying to say is that I can still use a public
void function to set and get the value of a private variable instead of
public property in class implementation.
So, why should I use "property" in c++.net and even Visual Basic 6.0 ?
It seems to complicate the program.
To use a "public void function" to get a value from a class, you'd have to
pass another parameter by reference. That seems kind of messy to me.
Ignoring that though, yes, you're right...in other languages that do not
explicitly define the concept of a property, you can still effectively do
the same thing by implementing setter and getter functions. For example,
instead of this C# code:
private int _i;
public int I
{
get { return _i; }
set { _i = value; }
}
You could write this C++ code:
private: int _i;
public:
int GetI() { return _i; }
void SetI(int i) { _i = i; }
However, those functions don't mean anything special to the compiler in
C++. One thing about properties is that they alert the compiler that the
member is essentially a public value member of the class, as opposed to
some method that just returns some value (whether that's a number that'sa
result of a calculation, an instance of something being instantiated,
etc.) That is, it's not just the result of some computation, but rather
some value inherent in the state of the class. Thus the name "property"..
There are a variety of benefits to this, most of them relating to code
maintainability. But one of the most obvious, non-maintenance-related
benefits is that the property can be treated specially by various things..
Class serialization works because of properties, as does data binding.
You could shoe-horn stuff like that into regular C++ code, but it would be
clumsy and clearly hacked in. Properties provide a nice, clean way to
construct behavior around the idea of properties of a class.
There's a lot of stuff in .NET, and especially in C# (though I guess
managed C++ has its own versions of much of this...haven't used it much
myself, so I don't know firsthand), that does really do anything that you
couldn't do some other way. What it does do is make it a lot easier, and
maintainable.
Where you see something that "complicates the program" I see something
that actually simplifies it. Yes, it introduces yet another new concept
to the language (potentially complicating the language), but that new
concept allows you to in a much simpler way implement the same thing that
you should have been doing all along, in a way that makes that
implementation more explicit both to you, the compiler, and other
components within .NET. That very much simplifies a lot of things.
Pete
