Quando pensamos no conceito de Programação Orientada a Objetos – POO (na realidade é um paradigma) – é comum haver certa confusão sobre do isso realmente se trata.
Entender o conceito de Objetos, no contexto da programação e da modelagem, é fundamental para se entender “de fato” o que é Polimorfismo, Herança, Abstração e Encapsulamento, que formam a base da POO.
Quando falamos de Objetos, no contexto da Programação Orientada a Objetos, é importante exercitarmos nossa abstração para entendermos do que se trata.
Na prática, no bit, um objeto será um ponteiro alocado na memória. Mas conceitualmente é diferente.
Por exemplo, num projeto de um software para hospital teremos conceitos como Paciente, Leito, Remédio, Doença, Seringa, Atendimento, Médico etc.
Podemos considerar coisas como Doença, Atendimento ou Preço como Objetos?
São coisas não-palpáveis, imateriais!
São, mas na estrutura de um sistema Orientado a Objetos, podem ser consideradas objetos, mesmo que não sejam objetos na vida real – mas são conceitos da vida real.
É usual pensar em objetos como Entidades, às vezes fica mais simples de entender. Mas um software não é feito de só de classes do tipo Entidade, não podemos restringir a isso. Tem também as classes de Negócio, Dados, Utilitário e vários outros tipos. Todas estas classes serão objetos quando o sistema estiver sendo executado.
/* Importantíssimo entender que Classes não são Objetos, mas a estrutura de um Objeto. Uma classe Cliente só “vira” objeto quando é instanciada e vai para a memória do computador, adquirindo um ponteiro para si própria. Aí teremos o Objeto Cliente. Ao encerrar a instância da classe com um “dispose” ou passagem de garbage colector o objeto Cliente deixa de existir, e resta somente sua estrutura – classe Cliente – que neste momento não existe mais na memória do computador, apenas em seu disco rígido como um arquivo executável ou arquivo qualquer a ser interpretado.*/
Software escrito conforme a “vida real”
Uma das melhores coisas que a Programação Orientada a Objetos nos trouxe é a ideia de aproximar a estrutura do software à vida real, refletindo nos modelos e elementos do projeto a realidade do problema o qual o sistema busca solucionar.
No melhor dos mundos, um sistema que atende a este objetivo e possui boa qualidade empregada em seu projeto torna-se uma espécie de um livro, onde para entendê-lo basta que, com atenção, foco e a técnica necessária, abra-se os arquivos de seu código fonte e leia-se as linhas de código. Ou seja, um sistema Orientado a Objetos bem modelado e codificado dá uma excelente visão sobre o problema que foi resolvido, pois espelha a vida real.
/* Lembrando que a Programação Orientada da Objetos não é algo novo – já tem mais de 30 anos – mas ainda é muito mal utilizado por muitos profissionais, pois (infelizmente) é possível projetar/construir software que utiliza alguma linguagem OO (C#, Delphi ou Java, por exemplo) sem fazer um software orientado a objetos “de verdade”; realizando algo mais procedural que POO, violando a maioria dos princípios de um bom design OO. Mas compila…*/
E é neste sentido que uma boa semântica torna-se algo super importante.
Um projeto com uma boa semântica se aproximará mais em termos conceituais do problema solucionado pelo software (da solução), e os benefícios disso são incalculáveis. O sistema passa a ser inteligível para qualquer Analista que saiba Programação a Orientada a Objetos, fica fácil entender, dar manutenção, gerar documentação, evoluir etc.
Exemplos
Vejamos um mesmo contexto, implementado de uma maneira adequada, do ponto de vista de POO, e outro logo em seguida, com uma implementação muito ruim. A diferença é chocante!
Imaginemos um sistema de Vendas que tenha em seu escopo a figura de um Cliente.
Em nossa arquitetura temos camadas de Entidade e Negócio. Abaixo segue uma representação das classes de Entidade e Negócio de Cliente, com uma boa semântica, legível e que aproxima-se muito bem do conceito de Cliente do sistema de Vendas, na vida real do negócio de Vendas.
Ao bater o olho na classe ClienteEntidade fica claro que trata-se de uma estrutura que representa um Cliente, com seus atributos bem definidos, coesos, claros. Fazendo o mesmo na classe NegocioCliente não ficam dúvidas sobre o que cada método/operação realiza com Cliente.
Agora vejamos outra estrutura para atender o mesmo cenário, mas com uma semântica praticamente ausente, com as classes e atributos quase indecifráveis.
A diferença é gritante não é mesmo?
Agora imagine isso num sistema que tenha trezentas entidades. E de enlouquecer!
Abreviações devem ser evitadas ao máximo, pois tira clareza na leitura, demanda regras para uso de acrônimos, dá margem a entendimentos dúbios etc.
É como comparar duas receitas médicas – uma digitada no sistema do hospital e outra escrita à mão pelo médico. Conceitualmente é a mesma coisa, mas uma é impossível de entender.
Concluindo
Um software feito com Programação Orientada a Objetos de boa qualidade é como uma redação bem escrita: tem início, meio e fim bem delimitados, parágrafos adequados, respeita as regras de gramática e concordância etc. E uma redação bem escrita é uma redação bem interpretada!
Grande abraço!