Herança de filhos para pais?

5

Vendo este diagrama de classes UML:

FileHandler,UploadereDeletersãoclassesabstratas.Asquatroclassesinferioressãoimplementações.ElesseestendemnoFileHandlerInterface,querequerummétododetratamentoparavalidarocontrato.Masessemétodonãoestánasimplementações,estáemseuspais(Uploader&Deleter).

Eufizissoporquenãogosteidaidéiadeimplementarumainterfaceemumaclasseabstrata.

Embora,eusintoqueháumaenormefalhanestedesign.Ofatodequeénecessáriopassarporpaisparasabercomoacriançafuncionamefazsentirqueéumprojetoruim.

Parasermaispreciso,nãoestáclaroqueopaidiretodeUploaderCompletetenhaummétodo"manipulador", mesmo que ele precise dele. Pode ser no pai do Uploader (e recursivamente).

Onde esse design está errado e como eu posso melhorá-lo?

Obrigado.

    
por Steve Chamaillard 30.05.2016 / 14:21
fonte

1 resposta

6

FileHandler deve implementar FileHandlerInterface . Métodos abstratos comuns a todas as crianças, como handle() , devem ser hasteados para FileHandlerInterface se public, FileHandler se não.

O objetivo das classes e interfaces abstratas é definir o contrato para classes concretas e permitir o polimorfismo. Se eu tiver recebido FileHandlerInterface , eu devo ser capaz de fazer o que for necessário, independentemente da implementação real.

Com base no diagrama da pergunta, parece que o polimorfismo funcionará como esperado se você estiver passando em torno de FileHandlerInterface de referências.

No entanto, sua hierarquia é frágil . Se você fizer uma alteração em uma parte da hierarquia, isso poderá causar inconsistências com outras partes da hierarquia. Além disso, é possível definir outra subclasse de FileHandler , mas você pode esquecer de adicionar FileHandlerInterface . O fato de ser possível criar um novo manipulador de arquivos que não é efetivamente um manipulador de arquivos informa que a hierarquia está incorreta e FileHandler deve implementar FileHandlerInterface .

    
por 31.05.2016 / 06:06
fonte