Java: static abstract (again) - best practice how

问题:

I theoretically understand the point why there is no abstract static in Java, as explained for instance in Why can't static methods be abstract in Java .

But how do I solve such a problem then?

My application uses files of a few types, which I want to assign static properties like a description of that file type (like "data file", the other being "config file", etc.). Obviously, I would put that into a static String so that the description is accessible without instancing a file (useful for the GUI f.i.). On the other hand, obviously all file types should have some common methods like getStatus(), which obviously I want to inherit from a common superclass MyFileType.

getDescription() would of course be abstract in the superclass.

Tried using a combination of a superclass and an interface, but similar problem: A static implementation of an abstract method is not allowed.

How would a Java guru solve this? Is it really such a bad implementation that I want to create?

Many thanks, Philipp

回答1:

To restate the problem: you want your per-file-type classes to have statically available information on the type (e.g., name and description).

We can easily get part-way there: create a separate class for your type info, and have a static instance of this (appropriately instantiated) in each per-file-type class.

package myFileAPI;

public class TypeInfo { 
    public final String name;
    public final String description;

    public TypeInfo(String name, String description) {
        this.name = name;
        this.description = description;
    }
}

and, say:

package myFileAPI;

public class TextFile {
    public static final TypeInfo typeInfo
                   = new TypeInfo("Text", "Contains text.");
}

Then you can do stuff like:

System.out.println(TextFile.typeInfo.name);

(Of course, you could also use getters in TypeInfo to encapsulate the underlying strings.)

However, as you said, what we really want is to enforce the existence of a particular signature static method in all your per-file-type classes at compile time, but the 'obvious' design path leads to requiring an abstract static method in a common superclass which isn't allowed.

We can enforce this at run-time though, which may be good enough to ensure it is coded correctly. We introduce a File superclass:

package myFileAPI;

public abstract class File {

    public static TypeInfo getTypeInfo() {
        throw new IllegalStateException(
                    "Type info hasn't been set up in the subclass");
    }

}

If TextFile now extends File, we will get this exception when calling TextFile.getTypeInfo() at runtime, unless TextFile has a same-signature method.

This is quite subtle: code with TextFile.getTypeInfo() in still compiles, even when there is no such method in TextFile. Even though static methods are bound at compile time, the compiler can still look through the class hierarchy to determine the compile-time static call target.

So, we need code like:

package myFileAPI;

public class TextFile extends File {

    private static final TypeInfo typeInfo
                      = new TypeInfo("Text", "Contains text.");

    // Shadow the superclass static method
    public static TypeInfo getTypeInfo() {
        return typeInfo;
    }

}

Note that we are still shadowing the superclass method, and so File.getTypeInfo() can still be 'meaninglessly' called.

回答2:

This sounds like a great time to pull out the Fundamental Theorem of Software Engineering:

Any problem can be solved by adding another layer of indirection.

The problem you have right here is that a file carries around multiple pieces of information - what the type of the file is, a description of the file, the file contents, etc. I'd suggest splitting this into two classes - one class representing a concrete file on disk and its contents, and a second that is an abstract description of some file type. This would allow you to treat the file type class polymorphically. For example:

public interface FileType {
     String getExtension();
     String getDescription();

     /* ... etc. ... */
}

Now, you can make subclasses for each of the file types you use:

public class TextFileType implements FileType {
     public String getExtension() {
         return ".txt";
     }
     public String getDescription() {
         return "A plain ol' text file.";
     }
     /* ... */
}

You can then have some large repository of these sorts of objects, which would allow you to query their properties without having an open file of that type. You could also associate a type with each actual file you use by just having it store a FileType reference.

回答3:

annotations could be fine for your purpose.

@FileProperties(desc="data file")
public class DataFile extends XFile { ... }

FileProperties props = DataFile.class.getAnnotation(FileProperties.class);
String desc = props.desc(); 

Accessing the info still requires reflection, however it's a little better than using static field/method.

Java compiler does not enforce that all subclasses are annotated as such. You can add your logic to the compiler (using annotation processing) but that's too complicated. It's ok to check it at runtime.

Update:

This is also possible:

@FileInfoClass ( DataFileInfo.class )
@public class DataFile

回答4:

The question is not clear enough to provide an objective answer. Since I cannot give you a fish, this answer is more on the lines of "Teach you to fish"

When faced with design issues like these where you think "duh..now sure why such a simple thing is so hard" more often than not, you are either designing it blatantly wrong or you are over complicating things. If I am empathizing correctly, the design issue seems like a "common requirement" yet the language is not allowing it.

• Trace back your design steps/decisions
• question all the "obvious" and "off course" you are basing your design on (you are using quite a few of them above)
• see if things can be simplified (don't take any of the OO concepts to its extreme. Make compromises based on ROI)

...and you will most likely arrive at an acceptable answer.

If you still don't, post back the classes and interfaces you think you want (with compile errors since language is not allowing certain things) and maybe we can help you tune your design.

回答5:

Sounds like you need to use a singleton. Basically, you call a static method like MyFileTypes.getDataFileInstance() which creates a single instance (or reuses if already created) of an object and when you first create it setup the 'constants' as needed. I'll see if I can find you a good example but your post isn't very clear about how you want to use it.

回答6:

You could create a FileMetadata class that has all the info you need. When your app starts up, you could create instances of FileMetadata, and keep static pointers to them so you can access them from anywhere in the JVM.

This way you put the abstract stuff in the actual instances; anything the stuff that does not call for abstract semantics can be static...

回答7:

I don't know how a java guru would solve it, but I'd probably create a resource bundle with all the descriptions in a properties file like this:

com.bigcompany.smallapp.files.DataFile=Data file
com.bigcompany.smallapp.files.ConfigFile=Config file

Handling the bundle can conveniently be placed in the superclass or elsewhere.

Another option is to use reflection to access the static fields in each subclass, but then you need to make sure that all the subclasses have a static field with the same name.

There could be other options too, even refactoring the code so that the subtypes aren't represented by a separate class each, but in general there's no watertight solution.

回答8:

Instead of putting your static properties actually in static properties, put a reference to MyFileTypeDescription as a static property.

i.e.

class MyFileType {
   static MyFileTypeDescription description;
   ...
   <your regular attributes>
}
abstract class MyFileTypeDescription {
  String name;
  abstract String getDescription();
}

Something along this way, if I understood your problem correctly.

回答9:

I basically had the exact same problem.

You may want to look at the solutions suggested to me in my question

I liked Bozho's idea, but according to himself it was a bad idea. :) I suppose better programmers can explain why it is so. Ralph's and Jon Skeet's solution also works.