by
Krull McSkull >> Tue, 12 Jan 1999 6:49:07 GMT
I have just started using JADE and would like to know if there are any performance issues with using protected attributes and a get/set method over using readonly attributes. I would like to know if JADE invokes the get method or if it is able to copy it inline.
The access 'attribute' (protected, public, readOnly) for a property is evaluated at compile-time so use of the option itself does not incur any runtime overhead. If you make your properties protected and use get/set methods then you *will* incur the overhead of the method call which is not insignificant. These user defined get/set methods are not inlined and are subject to dynamic binding overheads.
I would also like to know which is prefered and the reasons why.
Here is my 2 cents worth:
A number of people, especially those coming from Smalltalk and C++ programming backgrounds still (almost religiously) insist on defining all properties as protected and providing get/set methods in the public interface (By the way Smalltalk doesn't even give you the option). In my opinion this tends to overlook certain higher level JADE concepts which provides a neat alternative that neither sacrifices encapsulation or flexibility and at the same time has lower runtime overhead.
I generally recommend that properties which are intended to be part of the public interface of a class i.e. those properties which are intended to be accessed by other classes should be defined as readOnly. My reasoning is as follows:
1) A property when accessed in the JADE language is already equivalent both conceptually and in reality to a pair of related get and set operations implemented by the JADE object manager. When you refer to a property using the JADE language, you are doing so via the default get/set operations provided by the Object manager, never directly (you can cheat in external methods and access object buffers directly - but a bit like unsafe sex this is not recommended)
2) The 'access' option for a property defines which of the 'implicit' get/se t operations should be part of the public interface of the class (protected => none, readOnly => get only, public => both)
3) If you insist on defining and writing get method wrappers which simply return the property value, if you think about it carefully this does not increase encapsulation, all it does is incur an unnecessary runtime overhead (method call including dynamic binding).
4) If you ever need to redefine the 'behaviour' of the implicit get (or set) operations JADE has the solution: mapping methods, these can be added at any time so their is no loss of flexibility.
5) If you use the readOnly option and publish 'tidy' attribute names in the class interface such as 'name' and 'address', if you ever decide to provide a relational view say, then the view can contain attribute names such as 'name' and 'address' instead of getName and getAddress.
Now, you might ask why not define all properties as public and be done with it? The readOnly is definitely prefarable since it imposes a dicipline whereby only the methods defined in a class (the implementation) can change the state of its instances (the desirable level of encapsulation). In the majority of cases a client class will not employ individual 'set methods' to update instances of a different class, more often multiple attributes will be set or changed in a single initialise (loadSelf) or update method.
Any implementation properties should always be defined as protected, which almost goes without saying.