GOOP: Class Attributes vs Object Attributes

[Francois Normandin]

I've got a theoretical question on GOOP Classes.

I'm usually defining my object attributes for anything that could be different from one object to the other (ID, init parameters, position, speed, etc.) and, as I understand it, the class attributes are for everything that is class invariant (let's say supply voltage, material, dimensions, etc.). But I usually never use the class attributes and put all the fixed parameters in the object attributes, initialize them once with "Object_Create" and never change them in the course of my program. I think it's not optimal design but it works rather simply and it's more readable for colleagues less familiar with OOP.

I would like to know if it is good practice to simply ignore the class attributes? My concern is as to what would happen if in the future I were to create a sister-class and make these two classes inherit from a parent. Those sister classes will have different class attributes... How well does it scale up? Will I run into a wall one way or the other? Any comments?

thanks,

Francois.

[TG]

QUOTE (normandinf @ Nov 21 2008, 07:37 PM)

I've got a theoretical question on GOOP Classes.

I'm usually defining my object attributes for anything that could be different from one object to the other (ID, init parameters, position, speed, etc.) and, as I understand it, the class attributes are for everything that is class invariant (let's say supply voltage, material, dimensions, etc.). But I usually never use the class attributes and put all the fixed parameters in the object attributes, initialize them once with "Object_Create" and never change them in the course of my program. I think it's not optimal design but it works rather simply and it's more readable for colleagues less familiar with OOP.

I would like to know if it is good practice to simply ignore the class attributes? My concern is as to what would happen if in the future I were to create a sister-class and make these two classes inherit from a parent. Those sister classes will have different class attributes... How well does it scale up? Will I run into a wall one way or the other? Any comments?

thanks,

Francois.

I can only share my experience with class attributes.

I have learned to ignore them in the few limited GOOP designs I have attempted, however there must most assuredly be uses for them..

To me cLass attributes are those that do not vary and are common to the class, hence limited usage since everything that is designed will ultimately vary to some degree.

The concept "find what varies and encapsulate it" is not served well by class attributes (at least to me they are not).

Anyway, Ive never been able to use them much..

[MikaelH]

I use Class Attributes from time to time.

The definition if of cause that this data is shared between all objects of the same type.

If you e.g. have a common TCP/IP server all objects should communicate with, it's good to save the IP-address here.

If you need to change the IP-address in the middle of the execution you just change it in one place instead of changing all objects.

On thing I often use it for, is to save a references of all created objects in.

Then I can create a ClassMethod (Static) that can return reference to a particular object type.

Static Method: GetInstrumentByType

Statis Attributes: InstrumentsName & InstrumentsRef

But to get this working you have to use the Class Attributes in a special way.

The class attribute of a VdLabelPrinter objects will not have anything in common a VdDigitalContoler object. So I can't really use a Static method GetInstrumentByType, from the Base class VdTestInstrument to get these objects.

So I have to store the references to all objects in a Class Attribute that is Common for all created objects that is derived from the VdTestInstrument base class.

If you lock and unlock the class attributes without wiring a reference in to the VI (Reference value=0), you can save class attributes in a memory that isn't aware of any derived classes.

So you actually have 2 different class attributes to store data in.

1) If you wire the lvclass wire into the lock attribute, you will get a unique shared memory for a objects of that type.

2) If you don't wire the reference into the lock attribute, you will get a unique shared memory that you can access between all classes that derives from this class.

Cheers,

Mikael

[Francois Normandin]

QUOTE (MikaelH @ Nov 23 2008, 04:09 PM)

I use Class Attributes from time to time.

The definition if of cause that this data is shared between all objects of the same type.

If you e.g. have a common TCP/IP server all objects should communicate with, it's good to save the IP-address here.

If you need to change the IP-address in the middle of the execution you just change it in one place instead of changing all objects.

That's a good point indeed. I had thought only of invariant properties, but this is a good peeble... since I'm also working on a TCP client-server!

QUOTE (MikaelH @ Nov 23 2008, 04:09 PM)

But to get this working you have to use the Class Attributes in a special way.

The class attribute of a VdLabelPrinter objects will not have anything in common a VdDigitalContoler object. So I can't really use a Static method GetInstrumentByType, from the Base class VdTestInstrument to get these objects.

So I have to store the references to all objects in a Class Attribute that is Common for all created objects that is derived from the VdTestInstrument base class.

So you actually have 2 different class attributes to store data in.

1) If you wire the lvclass wire into the lock attribute, you will get a unique shared memory for a objects of that type.

2) If you don't wire the reference into the lock attribute, you will get a unique shared memory that you can access between all classes that derives from this class.

That's exactly the answer I was looking for. Not only was I wondering what would happen if I changed inheritance or created new related classes, but I see there are two possible implementations based on how I really want to share information between the objects. And that's a trick that will hopefully keep me from running in the wall when I try to design it.

thanks Mikael.

QUOTE (TG @ Nov 23 2008, 02:25 PM)

I have learned to ignore them in the few limited GOOP designs I have attempted, however there must most assuredly be uses for them..

Sounds a lot like me!

Well now that I know of the TCPIP address example, I'll try to find other ways to make use of them.