For example, java.io.File is just a concrete class. My replacement for it supports resolving Windows shortcuts. I need to preprocess constructor parameters to resolve possible .lnk files because the FileSystem object that does normalizing/canonicalision/resolving on the abstract paths is not accessible. The need for preprocessing rules out pure subclassing – can’t do preprocessing before calling super(…) and File is immutable. So I extend File and use a delegate, overriding all of File’s constructors and methods (calling super(”) in all constructors).
This works nicely, but is obviously not ideal – if File changes, I will not have overridden any new methods or constructors and this will expose the underlying empty abstract pathname. Am I missing something obvious? It seems like there should be a simpler/better way.
In the specific case you suggest it looks to me like you’re better off with a separate factory class that makes the decisions about normalizing/canonicalision/resolving.
Then you can just let File be File. Simpler.