Recursos opcionais: método padrão ou interface separada

8

Interfaces dedicadas parecem ser uma boa maneira de expor os recursos opcionais em uma hierarquia de tipos específicos de domínio. No entanto, eles impedem o uso de decorador e padrões compostos, o que também é comum nesse tipo de hierarquia.

Especialmente, provavelmente ninguém deseja implementar um decorador / composto para cada combinação possível dessas interfaces; portanto, mais frequentemente, eles implementam todas as interfaces opcionais e usam a verificação de tipo para encaminhar seletivamente as chamadas, o que anula o propósito de ter interfaces separadas.

Uma alternativa, que a estrutura Java Collection usa, é incluir todas as operações no tipo base e preenchê-las com implementações fictícias. Os métodos padrão no Java 8 facilitam ainda mais esse uso.

De certa forma, isso parece o debate das colunas anuláveis no mundo dos bancos de dados. Existe algum argumento forte contra a última abordagem mais prática?

java design-patterns interfaces

— billc.cn
fonte

Você está limitado a Java ou JVM? Porque Scala tem isso perfeitamente resolvido

— Frank

@Frank Eu sonho em ser capaz de usar Scala ou qualquer linguagem que tem traços, mas, infelizmente, usando Java 8 já é um grande salto para a minha empresa ...

— billc.cn

2

Uma solução para esse problema que usei no passado (em que um grande número de decoradores adiciona facilidades a uma base relativamente simples, com muitas interfaces possíveis) é ter uma classe base para os decoradores e as classes que eles envolvem, independentemente de interface implementada, que possui um método declarado (usando a sintaxe de Java):

    public <T> T findImplementation (Class<T> cls) {
       if (cls.isAssignableFrom(getClass())
           return cls.cast(this);
      return wrapped.findImplementation (cls);
   }

Obviamente, implementações que não são decoradoras retornam nulo, em vez de repassar a solicitação, pois não há onde passar nesse caso.

— Jules
fonte

Solução muito interessante. (Eu finalmente acrescentou um getWrappedInstance()método para o meu tipo de hierarquia para fazer algo semelhante Gostaria de ter pensado nisso..)

— billc.cn

1

O desafio da alternativa é dificultar a adição / alteração / remoção de recursos opcionais. Por exemplo, se adicionarmos um novo recurso opcional, agora precisamos alterar a classe base e, em seguida, alterar todas as subclasses para adicionar o recurso ou o não-recurso. Isso pode ser um pouco atenuado se houver um padrão razoável, como um não operacional, portanto, apenas os subtipos que suportam o recurso precisam substituir as partes necessárias. Se esses recursos opcionais forem poucos, relativamente estáveis e improváveis de serem alterados, apenas adicioná-los ao supertipo pode ser suficiente. Caso contrário, a manutenção pode começar a ficar pesada.

O padrão de design mais comum para recuperar o tipo do supertipo é o padrão de visitante . Isso pode ser complicado na sua situação, pois um único objeto pode implementar várias interfaces, mas ainda é possível com algumas modificações.

— cbojar
fonte