One of the most important language features supporting
SyntacticallyTransparentRefactorings
E.g. in
EiffelLanguage,
VisualBasic, and
PythonLanguage, but not in
CeePlusPlus or
JavaLanguage. An object may first make publicly available data members.
E.g.
struct Point { int x, y; }
Users access this directly
Point p; p.x = 1; p.y = 2;
Later, however, the internal representation may be changed, requiring a functional interface:
class Point {
private:
float angle, radius;
public:
void set_x(int);
void set_y(int);
};
Point p; p.set_x(1); p.set_y(2);
Changing from data member access to setter/getter access in
CeePlusPlus is not syntactically transparent.
In languages like
EiffelLanguage,
CeeSharp, and
PythonLanguage, however, you can declare properties. When assigned to, a property calls a set method; when read from, a property invokes a get method. In hypothetical
CeePlusPlus syntax:
class Point {
private:
float angle, radius;
public:
property int x {
int get() { return (int)( sin(angle)*radius; }
int set(int argx) { angle = atan2(argx,y);
radius = sqrt(argx*argx+y*y);
return x
}
}
property int y ....
};
Point p; p.x=1; p.y=2;
Thus, the users of the class do not need to be changed. Although they probably need to be recompiled.
"OWL", a
SmalltalkLanguage-like OO language used internally at EDS in the '80s had that property too: Properties and methods were interchangeable. In fact, one common technique in OWL was to change a property to a rule-based expert system that computed the "property" value. "Properties" and "methods" were just two of a dozen or more different ways a class could respond to messages. Several different rule based expert system processors could be used instead, and you could write your own.
Very interesting tool, that "OWL" was. -- JeffGrigg
In the following languages, direct access of properties implicitly invokes invisible getter and setter functions, which can be overridden.
AccessOrientedProgramming takes another approach to solve this problem.
The way you deal with this in
CeePlusPlus and
JavaLanguage, of course, is to follow the advice that any introductory course in these languages is happy to give you.
Make all data members private. And write getter/setter functions
as needed, which may be never, or only a few. (Unless you're writing a
JavaBean, or a
UnitTest, in which case you may find you need to write a lot).
"Properties" are mere
SyntacticSugar for the above, as
DylanLanguage and
JavaScript both demonstrate. Smalltalk does this by convention as well--though in Smalltalk, slots and messages occupy a separate namespace, so "foo" can both be a slot name and an accessor functions (and "foo:" is the name of the mutator). That said, properties are quite
useful SyntacticSugar.
CeePlusPlus progammers might try the following: (Java progammers, lacking a preprocessor--even one as lousy as cpp--are screwed).
#define PROPERTY(type,name) private: type m_##name; public: type &get_##name () const { return m_##name; } void set_##name (const type &long_name_because_no_hygenic_macros) { m_##name = long_name_because_no_hygenic_macros; }
Just put PROPERTY(int,age) or whatever in your class definition and
BobsYourUncle. Feel free to adjust the above macro to match the coding conventions at your site.
CategoryRefactoring