1

Short question

As I know, most OOP languages do not enable to inherit static fields. (C++, Java, C#)
On the other hand, OOP says that you shouldn't duplicate code.

  • Is there a common way in OOP languages, that makes something like "static field inheritance"?
  • Do you know an easier, language-specific unique way to solve the problem?
  • Are there languages which have that "integrated"? (I mean like a keyword.)

(Anyway, I know the basic intent of the static fields, I just want to go deeper and avoid any duplication.)

My concrete problem

I want to make a framework (C# or Java), and make it the easier way to expand. Therefore I want the constrains and informations about inherited classes to put in a base class as soon as possible.

I know, that each inherited class must have an own static field. (I want to make an object counter per subclass.)
Therefore it seems logical to make something like "static field inheritance" - where the static field is needed for the subclasses, not for the base class.
I've seen some tricky solutions (for example: in C#, used generics in C# abstract class static field inheritance) , but i can't believe there is no easier way.
If there is no easier way, please explain me how should I find out to use generics?
How should I look on generics in this context? What kinds of problems should i associate with them?
(In school we learned it only "to avoid code duplicating", the static field detachment was not emphasizing! It seems to me in this context, that generics are classes and instanties at the same time, but i have not found any understandable, logic approach for that yet.)

Community
  • 1
  • 1
PEZO
  • 441
  • 4
  • 14
  • I think, the [CRTP](http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern) could be a **common** solution. But not sure if it works in any OOP language. – PEZO Jun 04 '13 at 14:37

3 Answers3

3

@Pezo, you are misunderstanding both static fields and generics.
Static fields are not inheritable because they are accessible without an instance, and utilizing the concept of inheritance only applies to objects, not to classes.

Unless you have an instance of a class derived from a given base class, you cannot use an inherited [non-static] field from that base class. But you can ALWAYS use a static field, from ANY class, whether you have an instance of it or not, or an instance of anything else for that matter. They are accessible by every instance of the class, as well as accessible without any instance of any class.

As to Generics, Generics and static fields are different topics that have very little in common. Generics allow you to write a definition or a pattern for a class (or a method) that is not type specific, so that later, you can use it to create an actual concrete class by specifying the type you want it to use. It can contain static and non-static fields and properties and methods the same as a on-generic can.

Charles Bretana
  • 143,358
  • 22
  • 150
  • 216
  • 1
    I'm sorry if I was equivocal. I am aware of what you have written, that's why I used quotation marks. The question is: how to make *some field*, that operates in subclass as a static field, because I don't want to write in each subclass a static field. I think, that would be code duplication. – PEZO Jun 04 '13 at 12:52
  • That's the point, you don't NEED to write a static field in any other class. It is accessible everywhere, from any code, in any class, or in any instance, without doing that. Simply type `[ClassName].[FieldName]`. If you did duplicate a static field in another class, it would be a second, *different* static field, in a *different* memory location, with *different* value. – Charles Bretana Jun 04 '13 at 13:40
  • Yes, that's what I need: "different static field, in a different memory location, with different value." But I don't want to duplicate in each subclass, because I can state in present, that I will need them in subclasses. – PEZO Jun 04 '13 at 14:10
  • You want to create a different static field, one for each defined class, with only one statement ??? Then they are NOT the same static field, they are different static fields, and you need to declare each one individually, with it's own individual name [`namespace.ClassName.MemberName`]. Otherwise, how, when you attempt to access one from somewhere in your code, would the compiler know which one you want???? – Charles Bretana Jun 04 '13 at 16:52
  • And even then, they will all be available, individually and independently, the same way you would access them from the class they are defined in, or from outside the class, by using same syntax (`namespace.className.MemberName`), regardless of whether the code is running in an instance of the class they are declared in, a subclass, a base class, or any other completely unrelated class that is not even a part of the hierarchy of that class, even if it's in another assembly. – Charles Bretana Jun 04 '13 at 16:55
  • Yes, basicly I understand what you have written, and I think the same way. As I said, I don't want to use "the *real* static fields", I want something that *mimics* as an individual static field in each subclasses. Please check the two links I found about that (one in question, and one as its comment), and I think it will be clear. I believe it is a good common OOP solution for the problem, but I'm intrested is there another or better one? – PEZO Jun 04 '13 at 17:24
  • @CharlesBretana : the fields are indeed each one "different static field, in a different memory location, with different value", but they are NOT independent, since they should share the same name and be automagically assigned to any class that chooses to inherit from the particular root class defining the field. – C.B. Sep 25 '13 at 22:49
  • @C.B. if they "share the same name", then they are the same field. Otherwise, how could the compiler know which one you mean? AutoMagically, indeed!!! This would truly be magic. You want a compiler able to reach back in time and read the mind of the developer writing the code? – Charles Bretana Jan 07 '15 at 20:37
3

You are trying to misuse a simple mechanism (static fields) for something much more complicated. Don't do it. It seems you fixed yourself to the idea of using static fields to hold some singleton-like information for each of your descendant classes while unifying access to it somehow, but that's a completely wrong approach.

Forget static fields, and build a separate facility to hold the information you need for each class. It can essentially be a Dictionary<Type, Something> static field somewhere, or something a lot more complicated. Depends largely on your use case. You will then see that you won't repeat yourself, and gain a lot more good features.

You should also read something about Inversion of Control and Dependency Injection. It may be that what you are trying to achieve was already successfuly solved by many IoC frameworks (like Ninject or Structure Map to name just a few).

Side note: Consider finding a suitable framework instead of building your own.

Ondrej Tucny
  • 27,626
  • 6
  • 70
  • 90
0

Is there a common way in OOP languages, that makes something like "static field inheritance"?

No.

PEZO
  • 441
  • 4
  • 14