Duvida: modificador acessível somente a class e subclass

É possível criar um novo modificador em Java, para então criar um método que seja acessível somente a classe e à subclasses?

Estava criando uma interface “controladorMovimento” que possui os métodos

default void updateControl(){
    a();
    d();
    w();
    s();
}

private void d(){
    if(InputManager.getInstance().isPressed(KeyEvent.VK_D)){
        onPressedD();
    }
}
private void a(){
    if(InputManager.getInstance().isPressed(KeyEvent.VK_A)){
        onPressedA();
    }
}
private void w(){
    if(InputManager.getInstance().isPressed(KeyEvent.VK_W)){
        onPressedW();
    }
}
private void s(){
    if(InputManager.getInstance().isPressed(KeyEvent.VK_S)){
        onPressedS();
    }
}

void onPressedA();
void onPressedW();
void onPressedS();
void onPressedD();

O que acontece agora é o seguinte:
Digamos que eu crie um objeto Entidade.

public class Entidade implements controladorMovimento {
    @Override
    public void onPressedA() {
    }

    @Override
    public void onPressedW() {
    }

    @Override
    public void onPressedS() {
    }

    @Override
    public void onPressedD() {
    }
}

e agora o objeto:

Entidade ent = new Entidade();

dessa forma é possível chamar os métodos onPressed diretamente no objeto.

ent.onPressedD();

ou seja, ele realizaria a operação sem passar pela verificação se a tecla foi ou não pressionada! Uma falha grave.
E eu não posso dar o Override nos métodos onPressed trocando o modificador de acesso para private!
Eu gostaria que somente o método updateControl pudesse ser chamado.

ent.updateControl();

Se alguém souber uma maneira de contornar esse problema eu ficaria muito feliz.
Basicamente minha dúvida se resume a: existe alguma maneira de alterar na subclasse o modificador de acesso de um método criado na superclasse? Neste caso, eu nem sequer estaria tentando aumentar a visibilidade, pelo contrário, queria reduzi-la.

Não que eu saiba, pois como a JVM saberia do que se trata? O modificador de acesso protected dá acesso à própria classe (lógico), às suas subclasses e a classes que estiverem no mesmo pacote. É um meio termos entre o public e o private. Para mais detalhes, sugiro que leia o seguinte tutorial: Java Tutorials - Controlling Access to members of a Class.

Bom, depois de procurar bastante, desisti. O design de desenvolvimento que eu estava querendo não é possível no Java a menos que de duas uma:
– Ou permitir a criação de métodos “abstract protected” nas interfaces.
– Ou permitir herança múltipla de classe.

Queria uma forma de ter um conjunto de funções pré programadas para quando fosse criar uma nova classe e precisasse daquele grupo de funções, já ter pronta, mas…
Queria que alguns métodos pré prontos não ficassem expostos para o mundo todo, isso causaria problemas como o que eu já citei lá em cima.
E segundo, queria poder instanciar a classe a partir da implementação dessas funções.
Assim como chamar minha classe pelo nome da interface que ela implementa.

Imagine que eu tivesse a interface de gerenciar teclas específicas do teclado e realizar uma função caso uma fosse pressionada.
Como no exemplo da interface que coloquei a cima, eu gostaria de apenas poder implementar a função de cada tecla nos métodos “onPressed” mas esse método não deveria ficar público, caso contrário poderiam instanciar a função do botão sem o botão ter sido pressionado de fato!

Se pudesse ter múltiplas heranças, tudo seria resolvido. Batava criar classes abstratas e adicioná-las conforme a necessidade. Bataria escrever a roda uma única vez! Java ainda não permite isso e pelo que vi, nunca vai.

Ao invés de usar uma interface com método default, utiliza uma classe abstrata com métodos protected, ou métodos sem modificador, caso suas subclasses estejam no mesmo pacote da classe abstrata.

Se quiser fazer algo mais robusto, substitua os métodos por uma estrutura de listeners, assim você pode tratar os “eventos” individualmente através de inner classes ou expressões lâmbda.

1 curtida

Herança múltipla se resolve através de herança de interfaces e composição de classes e delegação de comportamento.

1 curtida