El uso de subclases para sustituir una clase Java que no implementa una interfaz

Question

Por ejemplo, java.io.File es sólo una clase concreta. Mi reemplazo para él apoya la resolución de accesos directos de Windows. Necesito parámetros preproceso constructor para resolver los eventuales archivos .lnk porque el objeto de sistema de archivos que hace normalizador / canonicalision / resolver en los caminos abstractos no es accesible. La necesidad de pre-procesamiento descarta subclases pura - no puede hacer procesamiento previo antes de llamar a super (...) y el archivo es inmutable. Así que extiendo de archivos y el uso de un delegado, anulando todos los constructores y los métodos de archivos (super ( "") en todos los constructores llamando).

Esto funciona muy bien, pero obviamente no es lo ideal - si los cambios de archivos, no me he anulado nuevos métodos o constructores y esto expondrá la vía de acceso abstracta vacío subyacente. Me estoy perdiendo algo obvio? Parece que debe haber una manera mejor / más simple.

Answer 1

En el caso específico sugieres que me parece que está mejor con una clase de fábrica por separado que toma las decisiones sobre normalización / canonicalision / resolver.

A continuación, puede simplemente dejar que sea Archivo Archivo. Más simple.

Answer 2

Si realmente desea la ruta subclase, se puede engañar a la exigencia de que una llamada a super() tiene que ser la primera línea de un constructor de la subclase colocando su código de limpieza fuera de su clase, o en un bloque estático:

public class MyFile extends File {

    public MyFile(String path) {

        // static blocks aren't ideal, this is just for demo purposes:
        super(cleanPath(path)); 
    }

    private static String cleanPath(String uncleanPath) {...}

}

El patrón de la fábrica sugerido por krosenvold es otra buena solución.

Answer 3

  

Esto funciona muy bien, pero obviamente no es lo ideal - si los cambios de archivos, no me he anulado nuevos métodos o constructores y esto expondrá la vía de acceso abstracta vacío subyacente. Me estoy perdiendo algo obvio?

No, ha detectado un problema con el uso de la herencia - que consiguen subclases estrechamente unidas a superclases y su interior, por lo que puede ser frágil. Por eso Effective Java y otros dicen que debe favorecer la delegación antes de la herencia, si es posible.

Creo que la solución de krosenvold suena limpio.

Answer 4

Me parece que la solución de krosenvold es el camino a seguir.

Sin embargo, si usted necesita para mantener el registro de la ruta original que creó el archivo se puede implementar una clase contenedora.

public class FileWrapper {

    private File file;
    private String path;

    private FileWrapper(String path) {
        this.path = path;
        file = new File(preProcess(path));
    }

    private String preProcess(String path) {
        // process
        return path;
    }

    public File getFile() {
        return file;
    }

    public String getPath() {
        return path;
    }
}