Tipo Funcionario instanciando Diretor

Cara, não se atenta muito em o que é melhor ou pior nesses exemplos. Nesse curso o professor só está ensinando como criar classes e não no melhor jeito de criar elas. (Eu me senti igual a você da primeira vez que fiz esse curso). O melhor jeito de criar elas será visto mais pra frente no curso de refatoramento e no curso de design patterns.

Tive a mesma dúvida. Valeu André.

Olá Anderson, Essa dúvida vai ficar bem mais clara com cursos futuros, quando você começar a fazer seu código ser mais orientado a objetos permitindo alcançar todas as características desse paradigma.

Bem, para o momento acredito que basta esclarecer que quando você declara um objeto de um tipo PAI você cria a possibilidade desse objeto ser modificado por outro tipo.

Nesse caso, se em algum momento você precisasse trocar a referencia para outro tipo de funcionario, você conseguiria, pois ambos seriam funcionários. O contrário não seria permitido.

Gosto muito de uma frase que ajuda nessa parada: "Onde entra um pai, todos os filhos entram. Mas onde entra o filho, o pai não vai."

Valew, Abraços e espero ter ajudado.

Seria como o caso de uma promoção? O Programador Jr. é um funcionário, assim como o Gerente de Desenvolvimento. Então em uma promoção a variável funcionário, que era ProgJr vai receber uma instância de GerDev sem que seja necessário criar uma nova variável?

Acredito que o professor usou este exemplo mais pra fins didáticos. Quando entrar no tópico de interface, tudo faz mais sentido.

Não seria um caso de promoção. Isso é utilizado para permitir a mudança de tipo em momento de execução.

Quando a gente tipa com a especialização, esse tipo nunca será modificado.

Quando se utiliza Orientação Objeto da forma certa, a gente tem que pensar muito nas possibilidades de mudança no momento de execução (ver: SOLID, Designer Pattern).

O maior ganho é a facilidade de modificar, melhor, refatorar o código.

Existe um conceito de defende muito o teu exemplo: "Programe para interfaces" - isso quer dizer que sempre crie acoplamento com as classes genéricas ou interfaces, isso trará um baixo acoplamento ao código.

E aí Anderson, conseguimos ajudar no seu entendimento ?

Na verdade não plenamente. Procurei em outros lugares, inclusive em livros que tenho em casa e não encontrei nada tão específico a esse ponto. Mas continuarei estudando. Obrigado.