The static thing

The way we think reflects what we want to achieve. Humans are inherently comfortable thinking in terms of objects. It is rather strange that I was taught structural programming than an object oriented one, earlier in my academics. I am not going to speak in detail about OOPS, but concentrate on one aspect of the OOP Languages. Usage of "static".

As a norm, object-orientation avoids unnecessary "static" declarations, any entity carrying a "static" tag needs scrutiny and the relevance of static-ness needs to be questioned. This doesn’t' mean that static needs to be strictly avoided. It should be used as per the requirement.

Question : Let us think of a MVC style program where model and view are seperated. The hierarchy of model is "GenericModel", "SpecificModel" which extends "GenericModel". For simplicity let us alias them as GM and SM. GM and SM also have attributes defined within them. Not very different from other classes you may say. Now here is the catch, What if those attributes are "static" and are to be inherited. Design an object oriented specification for the above. On the face of it, the problem is obscure. So let me elaborate.
Static nature : A brief intro on static nature. Static entities are tied up to class definition rather than objects’. So static entries are accessed using class context, rather than object context. In such a case the concept of Runtime polymorphism is irrelevant and hence for static entries, the super class definitions and references take precedence over derived class ones, i.e. if GM has attr ‘x’ and SM also has another attr’ ‘x of the same type;
GM o1 = new GM();
GM o2 = new SM();
Print(o1.x);
Print(o2.x); // value printed here is same as that in above line.

You might have already observed the oddness. Most design patterns essentially rely on the fact that interfaces are available (abstraction) and use runtime polymorphism to do the trick. The situation here is different; the super class reference determines the value one gets.

Problem version1: We had two classes called "ModelElement" and "ObjectModel", the later extending the former. “ModelElement” class was contributing an attribute called "Name" and ”ObjectModel” was contributing an attribute called "Classifier". Now we have a GUI for the properties represented by an element. All instances of the “ModelElement” are supposed to have a view like “Name :: ”, and all entities represented by “ObjectModel” are supposed to have a view similar to above and in addition contribute its own “Classifier :: ”. Clearly “Name” and “Classifier” can be logically concluded to be static.

Now the complete version: We have number of attributes to be contributed rather than one per class. So we use vectors for holding all attributes in the vector and return it.

Solution 1: Not a solution, but for discussion. As this is one possibility we run into. Make the vector in super class Model protected static. This will fail for all the cases where derived class is instantiated before super class. The vector gets filled with attributes of both derived a super and when we later want attributes specific to super class it fails to do so.

Solution 2: Create a static vector in every derived class. Also, create a non static method to return this vector in every derived class. Use super. invocation to call super class method. The polymorphic behavior calls the hierarchy of classes and returns a vector of appropriate entities.Problem with this approach: Imagine a huge hierarchy, if some class in the hierarchy doesn’t’ override this method properly with super invocation; the returned values may be drastically different.

Solution 3: Use singletons to represent objects. Now inheritance among singletons is another over head. Think of the possible cases. Singleton entities may themselves be part of some other hierarchy and what about issues with Multiple Inheritance in singletons?

Solution 4: Using reflection, identify the static entities defined in the class hierarchy and return them to the user. Problem is that this approach is possible only in languages with support for reflection. This involves certain amount of hard coding of method/attribute names.

Clearly no solution described above sufficiently addresses the current concerns, If you have a cleaner solution to handle above, please feel free to mail me.