Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login

Guia de Referência Orientação a Objetos em C#

Neste Guia de Referência você encontrará todo o conteúdo que precisa para aprender a programar Orientado a Objetos na linguagem C#.

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (5)  (0)

Introdução

Normalmente, quando começamos a programar, o primeiro paradigma que conhecemos é o estruturado. Ele facilita o aprendizado por não trazer consigo tantos conceitos, como os que fazem parte da Orientação a Objetos. Imagine começar a criar algoritmos e, ao mesmo tempo, conciliar conceitos abstratos para poder programar as primeiras soluções? Não seria fácil.

Portanto, é natural percorrer o caminho: Programação Estruturada -> Programação Orientada a Objetos. O único porém desse processo é que algumas vezes acabamos levando algumas características da primeira para a segunda, características essas que podem prejudicar um pouco o nosso código (Figura 1). Pensando nessa etapa de transição, preparamos o seguinte artigo:

Programação Estruturada x Orientação a Objetos
Figura 1. Programação Estruturada x Orientação a Objetos

No entanto, também existem cursos que nos introduzem à programação já com o paradigma orientado a objetos. Para aprender sobre ele, independentemente do caminho que você esteja seguindo, acesse os posts abaixo:

É válido ressaltar que a Orientação a Objetos também não é uma “bala de prata”, não é a opção ideal para tudo. Ela possui vantagens e desvantagens. Para conhecer esses pontos, assim como alguns mitos que foram criados em torno dela, acesse os artigos:

Pilares da Orientação a Objetos

Após o primeiro contato com a Orientação a Objetos, você deve ter observado termos como abstração, encapsulamento, herança e polimorfismo. Estes são os fundamentos, os quatro pilares da POO. Para aprender sobre eles, algo fundamental para programar corretamente com esse paradigma, acesse:

Coesão e acoplamento

E agora, como saber se estou programando orientado a objetos, se estou aplicando corretamente seus conceitos? Uma maneira de sanar essa dúvida é observar se seu código está coeso e com baixo acoplamento.

Um código coeso é aquele que implementa apenas o que de fato é de sua responsabilidade, por exemplo: um método responsável por imprimir um relatório não deve saber como acessar o banco de dados. Se ele sabe como fazer isso, dizemos que ele tem baixa coesão, o que deve ser evitado.

Já um código fortemente acoplado é aquele que depende de muitos pacotes, classes e/ou métodos para prover uma funcionalidade. Quando se deparar com situações assim, cuidado. O post a seguir expõe como melhorar a qualidade do seu código, o ajudando a reduzir o acoplamento entre classes.

Princípios SOLID

Ao avançar seus estudos em OO, logo você se deparará com os Princípios SOLID. Esse termo representa cinco regras que são avaliadas por arquitetos e programadores como as boas práticas para uma programação orientada a objetos, nos auxiliando na construção de um código de fácil leitura, manutenção e extensão.

O nome SOLID também representa um acrônimo, e como apresentado a seguir, é formado pela junção da primeira letra do nome de cada um dos princípios:

  • Single Responsibility Principle: De acordo com esse princípio, cada classe deve ser planejada para possuir apenas uma responsabilidade. Sobre ele, temos alguns posts específicos, os quais indicamos a seguir:

  • Open Closed Principle: Esse princípio determina que uma classe deve ser fechada para modificações e aberta para extensões. Sobre ele, recomendamos os posts:

  • Liskov Substitution Principle: Esse princípio está relacionado à herança e indica que devemos ser capazes de substituir a classe filha pela classe pai sem que o sistema apresente problemas;

  • Interface Segregation Principle: Já o princípio da segregação dita que precisamos planejar interfaces específicas, com propósito bem determinado, de modo que quando implementada a classe que o faz não precise codificar métodos desnecessários;

  • Dependency Inversion Principle: Por fim, o princípio da inversão de dependência sinaliza que o recomendado é depender apenas de classes abstratas, e não de classes concretas.

Para aprender sobre todos esses princípios, acesse:

Na prática

Agora que você já conhece os conceitos, que tal colocá-los em prática programando com a linguagem C#? Os artigos e o DevCast a seguir lhe ensinarão como aplicar os conceitos da Orientação a Objetos com os recursos do C#:

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Ajude-nos a evoluir: você gostou do post?  (5)  (0)

Para avaliar você precisa ser um assinante MVP :)

Ficou com alguma dúvida?