Attributes vs instance variables

As an alternative to defining "numberObjs" as an attribute, it could be defined as an instance variable, with a "get_numberObjs" method also defined for retrieving its value. Instance variables are declared in an implementation statement, as shown below:

   interface Hello
   {
   string get_msg() ;
   void set_msg(in string msg);

   #ifdef __SOMIDL__
   implementation
   {
       string message;
   };
   #endif
   };

As demonstrated in this example, one disadvantage to using an instance variable is that the "get_msg" and "set_msg" methods must be defined in the implementation file by the class implementor. For attributes, by contrast, default implementations of the "get" and "set" methods are generated automatically by the SOM Compiler in the .ih and .xih header files.

Note: For some attributes (particularly those involving structures, strings, and pointers) the default implementation generated by the SOM Compiler for the "set" method may not be suitable. This happens because the SOM Compiler only performs a "shallow copy," which typically is not useful for distributed objects with these types of attributes. In such cases, it is possible to write your own implementations, as you do for any other method, by specifying the "noset/noget" modifiers for the attribute. (See the subtopic "Modifier statements" in Chapter 4 "SOM IDL and the SOM Compiler.")

Regardless of whether you let the SOM Compiler generate your implementations or not, if access to instance data is required, either from a subclass or a client program, then this access should be facilitated by using an attribute. Otherwise, instance data can be defined in the "implementation" statement as above (using the same syntax as used to declare variables in C or C++), with appropriate methods defined to access it. For more information about "implementation" statements, see the topic "Implementation statements" in Chapter 4.

As an example where instance variables would be used (rather than attributes), consider a class "Date" that provides a method for returning the current date. Suppose the date is represented by three instance variables-"mm", "dd", and "yy". Rather than making "mm", "dd", and "yy" attributes (and allowing clients to access them directly), "Date" defines "mm", "dd", and "yy" as instance variables in the "implementation" statement, and defines a method "get_date" that converts "mm", "dd", and "yy" into a string of the form "mm/dd/yy":

   interface Date
   {
           string get_date() ;

   #ifdef __SOMIDL__
   implementation
   {
       long mm,dd,yy;
   };
   #endif
   };

To access instance variables that a class introduces from within the class implementation file, two forms of notation are available:

somThis->variableName

or

_variableName

For example, the implementation for "get_date" would

access the "mm" instance variable as somThis->mm or _mm,
access "dd" as somThis->dd or _dd, and
access "yy" as somThis->yy or _yy.

In C++ programs, the _variableName form is available only if the programmer first defines the macro VARIABLE_MACROS (that is, enter #define VARIABLE_MACROS) in the implementation file prior to including the .xih file for the class.