Programação Orientada a Objetos com C# (Parte 6.1) – Interface » Link Sinergia
Programação Orientada a Objetos com C# (Parte 6.1) – Interface
Este tema da série Programação Orientada a Objetos com C# irá demandar mais publicações. Sendo assim, a numeração sequencial desta parte da série passou de 6 para 6.1 (vide título) e assim seguirá (6.2, 6.3…) mediante a necessidade de conclusão.
Encapsulamento, Herança, Polimorfismo, Propriedades, Classe, Objeto.
Com a alteração das classes UnicoEstudante e Program apresentando mensagens em uma janela de console através da relação destas (vide post anterior), fica compreendida a declaração, criação e utilização dos elementos básicos que compõem o Polimorfismo, o próximo passo na Programação Orientada a Objetos com C# será entrar no conceito de Interface.
Resultado da Execução da Aplicação
Apesar das últimas alterações realizadas serem concentradas na atenção e acompanhamento da classe UnicoEstudante, todas as outras Classes Descendentes e suas regras particulares não foram descartadas do exemplo anterior e sua exibição final.
Sabe-se portanto que, a classe Program é executada logo que se inicia a Aplicação, em seguida as classes Unitario, EspecialDesempregado, UnicoComum e UnicoEstudante (filhas da Classe Bilhete) são executadas à partir da classe Program.
Classe Pai ou Base Bilhete:
Classe Bilhete
Classes Descendentes Unitario, EspecialDesempregado, UnicoComum e UnicoEstudante, que herdam de Bilhete:
Classe Unitario x Classe EspecialDesempregado x Classe UnicoComum x Classe UnicoEstudante
Classe Program:
Resultado após a execução:
Esta publicação visa apresentar o cenário disposto até este momento da série de uma forma ampla, com as Classes Bilhete (Classe Pai ou Classe Base), Unitario, EspecialDesempregado, UnicoComum, UnicoEstudante (Classes Descendentes) e Program (Classe de Execução).
O resultado correto da execução, revela a importância dos elementos e a organização que compõe a estrutura de cada classe envolvida.
Por exemplo, seria catastrófico se as classes que representam a categoria Bilhete Único (Classe UnicoComum e UnicoEstudante), não implementassem os Métodos CobraTarifa(), Debita() e Saldo().
Vale ressaltar que, Modificadores de Acesso, quando declarados em Métodos pertencentes a uma Classe, fornecem apenas permissões de acesso as Classes que irão acessá-los ou sobrescrevê-los, não obrigando estas classes a utilizá-los.
"Haveria portanto a possibilidade de forçar as classes que acessam ou sobrescrevem métodos, a implementá-los de forma obrigatória?"
A dúvida acima foi criada de maneira proposital, tendo em mira um ponto de partida para utilização prática de Interface, que virá posteriormente.
Na próxima publicação, ainda sexta parte da série: Programação Orientada a Objetos com C# será apresentado o segundo post sobre Interface, o leitor irá conferir a continuidade do tema entre outros aspectos relevantes a este assunto.
Link permanente para este artigo: http://linksinergia.com.br/2016/08/03/programacao-orientada-a-objetos-com-c-parte-6-1-interface/