como não seguir o problema de acoplamento dentro de extends... Só o simples fator de não escrever os metodos e tornados abstrato deixa a classe como não abstrata ?
Solucionado
como não seguir o problema de acoplamento dentro de extends... Só o simples fator de não escrever os metodos e tornados abstrato deixa a classe como não abstrata ?
hoje, com a Alura e o Google Gemini
Olá Rogerio
Quando trabalhamos com orientação a objetos sempre existe o acoplamento entre classes. Sem acoplamento não conseguimos desenvolver sistemas úteis.
O problema é que quando temos muito acoplamento. Imagine um projeto simples onde queremos representar uma conta bancária e dentro dela uma operação de saque que simplesmente subtrai o valor do saque de um atributo saldo, mas não permite saques maiores do que o saldo.
Sabendo que a conta não permite saques maiores do que o saldo, eu posso utilizar esse conhecimento para implementar uma lógica que tira dinheiro da conta apenas enquanto ela tiver saldo. Como eu conheço a implementação da conta eu sei que a minha lógica está correta. Mas será que eu posso realmente assumir isso?
O que aconteceria se colocássemos um limite adicional para saques, nessa situação acabamos de quebrar a minha lógica de negócio que dependia do comportamento antigo da conta, ou seja, a lógica estava fortemente acoplada a implementação da classe Conta.
Se marcarmos o método de saque da conta como abstrato, cada classe filha pode dar uma implementação diferente para o método e a lógica que utiliza a conta não poderia contar com um comportamento padrão que não existe, o que faz com que o programador não fique tão preso à implementação concreta do saque.