Orientação a objeto
básica
Motivação problemas
do paradigma procedural
Orientação à
objeto é uma maneira de programar que ajuda na organização e resolve muitos
problemas enfrentados pela programação procedural.
Consideremos o
clássico problema da validação de um CPF. Normalmente, temos um formulário, no
qual recebemos essa informação, e depois temos que enviar esses caracteres para
uma função que irá validá-lo, como no pseudocódigo abaixo:
Cpf = formulario->campo_cpf
Valida (cpf)
Alguém te
obriga sempre validar esse CPF? Você pode inúmeras vezes, esquecer de chamar
esse validador. Mais considere que você tem 50 formulários e precise validar em
todos eles o CPF. Se sua equipe tem 3 programadores trabalhando nesses
formulários, quem fica responsável por essa validação? Todos!.
A situação
pode piorar na entrada de um novo desenvolvedor, precisaríamos avisá-lo que
sempre devemos validar o CPF de um formulário. É nesse momento que nasce
aqueles guias de programação para o desenvolvedor que for entrar nesse projeto
(às vezes é um documento enorme). Em outras palavras, todo desenvolvedor
precisa ficar sabendo de uma quantidade enorme de informações, que na maioria
das vezes não está realmente relacionado a sua parte no sistema, mas ele
precisa ler tudo isso, resultando um entrave muito grande.
Outro ponto
onde fica o problema da programação procedural é quando nos encontramos na
necessidade de ler o código que foi escrito por outro desenvolvedor e que somos
usuários desse pedaço do sistema. Um sistema bem encapsulado não deveria gerar
essa necessidade. Em um sistema grande simplesmente não temos tempo de ler uma
grande parte do código.
Considerando que
você não erra aí e que sua equipe tem uma comunicação muito grande (perceba que
comunicação excessiva pode ser prejudicial e atrapalhar o andamento), ainda
temos outro problema, imagine que agora em todo formulário você também quer que
a idade do cliente também seja validada, precisa ser maior de 18 anos. Vamos ter
de colocar um IF..., mas onde? Espalhado por todo seu código... Mesmo que se
crie outra função para validar, precisaremos incluir isso nos nossos 50
formulários já existentes. Qual é a chance de esquecermos um deles? É muito
grande.
A responsabilidade
de verificar se o cliente tem ou não tem 18 anos, ficou espalhada por todo seu
código. Seria interessante poder concentra essa responsabilidade em um só
lugar, para não ter chances de esquecer isso.
Melhor ainda
seria se conseguíssemos mudar essa validação e os outros programadores nem
precisassem ficar sabendo disso. Em outras palavras, eles criariam formulários
e um único programador seria responsável pela validação, os outros nem sabem da
existência desse trecho de código. Um mundo ideal? Não, o paradigma da
orientação a objeto facilita tudo isso.
O problema é que não existe uma
conexão entre seus dados. Não existe uma conexão entre seus dados e suas
funcionalidades, a idéia é ter essa amarra através da linguagem.
Quais as vantagens
Orientação a objetos vai ter
ajudar muito a se organizar e escrever menos, além de concentrar as
responsabilidades nos pontos certos, flexibilizando sua aplicação, encapsulando
a lógica de negócios.
Outra enorme vantagem, de onde
você realmente vai economizar montanhas de código, é o polimorfismo das
referências, que veremos em um post posterior.