While I was looking through the group's archives I came across a
discussion on doing properties (as known from Delphi/C#/etc) in C++. It
inspired me to do some experimenting. Here's what I came up with.
First we have an interface defining how a property can be used (read and
written - for simplicity, I ignored read-only and write-only variants).
template<typename Tclass Property
{
public:
virtual Property& operator=(const T& value) = 0;
virtual operator const T&() const = 0;
};
Then a simple implementation of that interface. Maybe "static" is not
the best word here, but what I meant was that this class implements the
property using a single, value encapsulation of the type, and not e.g. a
map or any other "dynamic" structure.
template<typename Tclass StaticProperty : public Property<T>
{
public:
StaticProperty (const T& value);
virtual Property<T>& operator=(const T& value);
virtual operator const T&() const;
private:
T value;
};
And finally an example object that publishes a property.
class Object
{
public:
Object();
const auto_ptr<Property<string property;
};
Object::Object() : property(new StaticProperty("sample value")) {}
And the pros and cons I managed to come up with:
+ the property has a simple interface which sends the message "I am
assignable to and from type T";
+ the property is a pointer, allowing for polymorphism (the sample
StaticProperty, but also more sophisticated properties with data
verification or other cool stuff);
+ access to the property is done through ordinary syntax one would
expect for a pointer to type T:
Object object;
*object.property = "another value";
string value = *object.property;
+ it avoids writing accessor functions for every property, which a)
saves time b) centralizes processing and verification of data (imagine
an EmailProperty descendant that checks e-mail address validity);
+ it avoids the unclear syntax of object.property() = "yet another" that
I've seen somewhere;
+ the const modifier ensurer that no one messes with the auto_ptr;
- it exposes the use of auto_ptr in a public interface (however I
haven't seen an intelligent pointer that would behave differently in
dereferencing contexts, which are only used by the client of the class),
which would mean bad things if one wanted to switch to something else
later on;
- code overriding the assignment and cast operators does not have access
to the internals of the class publishing the property (which is offered
by accessor functions), but:
+ it could be easily integrated with something like boost::signals,
providing everyone with be ability to track changes to a property and
react to them with zero effort on side of the containing class;
These are all the remarks I could think of. Please tell me what you
think, especially the cons, since I didn't produce much "-" points :-)
Please comment on the idea and on how it complies (or not) with good
class design practices (I mean especially the rules of hiding
implementation etc.) As for the general usefulness (or uselessness) of
properties: I did this for a very little university project involving
something similar to a database app, where things like Property<string>
where real type-savers.
--
Memfis
