Solucionado
Imagem: Relações representadas
Tudo em paz?
Na imagem acima consegui compreender as relações de "extends" (herança) e "implements" (interface), mas estou com dúvida em relação a CalculadorImposto com Tributável. Esta relação é a composição dita no vídeo?
Oie Thomaz, tudo bem contigo?
Sim, essa relação se encaixaria como composição.
Podemos observar isso no código nessa parte aqui:
public void registra(Tributavel t) {
double valor = t.getValorImposto(); // exemplo de composição
this.totalImposto += valor;
}Espero ter conseguido ajudar!
Se ainda tiver restado qualquer dúvida estarei por aqui :)
Olá Igor, tudo em paz?
Vamos lá!
A Classe CalculadorImposto não implementa Tributável.
O método registra é que recebe um Tributável como argumento.
O que não entendi, foi o que motiva e qual relação é indicada por aquela seta que une CalculadorImposto à interface Tributável?
Se for composição, torna CalculadorImposto (relação "é um") uma interface. Ou não?
====================================================
Minha compreensão deste cenário:
1 - SeguroDeVida e ContaCorrente herdam de Conta e precisam informar seu valor de imposto, logo implementam Tributável o que as "obriga" a criar um método específico para cada uma delas.
2 - Para executar o cálculo do imposto total foi criada uma classe CalculadorImposto que recebe um tipo mais genérico possível (polimorfismo). Neste caso a interface Tributável.
====================================================
Mais uma vez, obrigado pela força!
Valeus!
Oie Thomaz, tudo bem contigo?
Perdão pela demora.
Na realidade você não deve levar esse diagrama ao pé da letra, já que o instrutor só fez para conseguir exemplificar e explicar melhor o conteúdo.
Respondendo suas perguntas:
1) Aquela relação mostrada pela seta serve unicamente para mostrar que eles se relacionam de alguma forma. Essa relação como sabemos, se encaixaria como composição, já que a partir do uso de uma interface conseguimos aplicar o polimorfismo, fazendo com que o método public void registra(Tributavel t) possa receber qualquer objeto que implemente a interface "Tributavel", e o momento da composição é quando chamamos o método t.getValorImposto();, já que esse método vem de alguma classe que implementa "Tributavel".
2) Quando vamos ao código as vezes as leis que aplicamos nos diagramas acabam não sendo aplicadas da mesma forma, mas se formos falar apenas de diagrama então sim, a classe "CalculadorImposto" estaria "contida" na interface "Tributavel".
De resto suas conclusões estão corretas!
Como percebi que você tem um certo interesse em diagramas, segue alguns artigos sobre esse tema:
Espero ter conseguido ajudar!
Boa noite e paz, Igor!
Dúvida sanada!!! (Não verdade, ela acabou quando você falou pra relevar o diagrama! XD)
Obrigado pelas referências de UML.
Sim, eu curto diagramas pois me ajudam a organizar, "materializar" a abstração.
Mais uma vez, valeus!!!!
Ps: Creio que os diagramas nos dão suporte para a abstração, mas por algum acaso estão obsoletos no dia a dia? Apenas curiosidade de iniciante, pois se estiver, tenho que imediatamente abandonar esta forma de construir modelos.
Oie Thomaz, tudo bem contigo?
Fico feliz que tenha entendido!
Quanto a sua dúvida:
A resposta é depende, no geral ainda é bastante usado o digrama de classes, mas no decorrer do código as vezes uma coisa ou outra acaba mudando e se ninguem atualizar o diagrama ele pode acabar ficando desatualizado. E muito por conta desse fator estático de sempre ter que atualizar o diagrama, muitos times acabam apenas usando no começo do projeto e depois acabam deixando de lado. Mas isso não é absoluto, você com certeza vai achar lugares que fazem questão de ter toda a documentação UML atualizada o tempo todo, por isso acaba dependendo muito do time no qual você se encontra.
Espero ter te ajudado! Se tiver qualquer outra dúvida é só mandar!
Bons estudos!