Ocultação de nomes Java: a maneira mais difícil

Tenho um problema com a ocultação de nomes que é extremamente difícil de resolver. Aqui está uma versão simplificada que explica o problema:

Existe uma classe: org.A

package org;
public class A{
     public class X{...}
     ...
     protected int net;
}

Então há uma aula net.foo.X

package net.foo;
public class X{
     public static void doSomething();
}

E agora, aqui está a classe problemática que herda Ae deseja chamarnet.foo.X.doSomething()

package com.bar;
class B extends A {

    public void doSomething(){
        net.foo.X.doSomething(); // doesn't work; package net is hidden by inherited field
        X.doSomething(); // doesn't work; type net.foo.X is hidden by inherited X
    }
}

Como você vê, isso não é possível. Não posso usar o nome simples Xporque está oculto por um tipo herdado. Não posso usar o nome totalmente qualificado net.foo.Xporque netestá oculto por um campo herdado.

Apenas a classe Bestá em minha base de código; as classes net.foo.Xe org.Asão classes da biblioteca, então não posso alterá-las!

Minha única solução é a seguinte: eu poderia chamar outra classe que, por sua vez, chamaria X.doSomething(); mas essa classe só existiria por causa do nome clash, que parece muito confuso! Será que não há solução em que eu posso chamar diretamente X.doSomething()a partir de B.doSomething()?

Em uma linguagem que permite especificar o namespace global, por exemplo, global::em C # ou ::em C ++, eu poderia simplesmente prefixar netcom este prefixo global, mas Java não permite isso.

Você pode converter um nullpara o tipo e, em seguida, invocar o método naquele (o que funcionará, já que o objeto de destino não está envolvido na invocação de métodos estáticos).

((net.foo.X) null).doSomething();

Isso tem os benefícios de

• sendo livre de efeitos colaterais (um problema com a instanciação net.foo.X),
• não requer renomeação de nada (para que você possa dar ao método Bo nome que deseja; é por isso que um import staticnão funcionará no seu caso),
• não exigindo a introdução de classe de delegado (embora isso possa ser uma boa ideia ...), e
• não exigindo a sobrecarga ou complexidade de trabalhar com a API de reflexão.

A desvantagem é que esse código é realmente horrível! Para mim, isso gera um aviso, e isso é bom em geral. Mas, uma vez que está contornando um problema que, de outra forma, seria totalmente impraticável, adicionar um

@SuppressWarnings("static-access")

em um ponto delimitador apropriado (mínimo!) irá desligar o compilador.

Provavelmente, a maneira mais simples (não necessariamente a mais fácil) de gerenciar isso seria com uma classe delegada:

import net.foo.X;
class C {
    static void doSomething() {
         X.doSomething();
    }
}

e depois ...

class B extends A {
    void doX(){
        C.doSomething();
    }
}

Isso é um tanto prolixo, mas muito flexível - você pode fazer com que ele se comporte da maneira que quiser; além disso, ele funciona quase da mesma maneira com staticmétodos e objetos instanciados

Mais sobre objetos delegados aqui: http://en.wikipedia.org/wiki/Delegation_pattern

Você pode usar uma importação estática:

import static net.foo.X.doSomething;

class B extends A {
    void doX(){
        doSomething();
    }
}

Cuidado com isso Be Anão contém métodos nomeadosdoSomething

A maneira correta de fazer as coisas seria a importação estática, mas no pior cenário absoluto, você PODERIA construir uma instância da classe usando reflexão se souber seu nome totalmente qualificado.

Java: newInstance de classe que não possui construtor padrão

E então invoque o método na instância.

Ou apenas invoque o próprio método com reflexão: Invocando um método estático usando reflexão

Class<?> clazz = Class.forName("net.foo.X");
Method method = clazz.getMethod("doSomething");
Object o = method.invoke(null);

Claro, esses são obviamente os últimos recursos.

Não é realmente A resposta, mas você pode criar uma instância de X e chamar o método estático nela. Essa seria uma forma (suja, admito) de chamar o seu método.

(new net.foo.X()).doSomething();

Não há necessidade de fazer qualquer elenco ou suprimir quaisquer avisos estranhos ou criar qualquer instância redundante. Apenas um truque usando o fato de que você pode chamar métodos estáticos da classe pai por meio da subclasse. (Semelhante à minha solução hackeada aqui .)

Basta criar uma classe como esta

public final class XX extends X {
    private XX(){
    }
}

(O construtor privado nesta classe final garante que ninguém possa criar acidentalmente uma instância desta classe.)

Então você está livre para ligar X.doSomething()por meio dele:

    public class B extends A {

        public void doSomething() {
            XX.doSomething();
        }

E se você tentar obter o gobalnamespace, já que todos os arquivos estão na mesma pasta. ( http://www.beanshell.org/javadoc/bsh/class-use/NameSpace.html )

    package com.bar;
      class B extends A {

       public void doSomething(){
         com.bar.getGlobal().net.foo.X.doSomething(); // drill down from the top...

         }
     }

Essa é uma das razões pelas quais a composição é preferível à herança.

package com.bar;
import java.util.concurrent.Callable;
public class C implements Callable<org.A>
{
    private class B extends org.A{
    public void doSomething(){
        C.this.doSomething();
    }
    }

    private void doSomething(){
    net.foo.X.doSomething();
    }

    public org.A call(){
    return new B();
    }
}

Eu usaria o padrão de estratégia.

public interface SomethingStrategy {

   void doSomething();
}

public class XSomethingStrategy implements SomethingStrategy {

    import net.foo.X;

    @Override
    void doSomething(){
        X.doSomething();
    }
}

class B extends A {

    private final SomethingStrategy strategy;

    public B(final SomethingStrategy strategy){
       this.strategy = strategy;
    }

    public void doSomething(){

        strategy.doSomething();
    }
}

Agora você também desacoplou sua dependência, para que seus testes de unidade sejam mais fáceis de escrever.