O paradigma orientado a objetos, como o próprio nome deixa claro, parte do principio que o foco de quem irá analisar/projetar/desenvolver… deve ser totalmente direcionado para os objetos. Parece ser muito simples e na verdade eu acredito que seja, pelo menos até que me provem o contrário. Sim, pois acredito – e muito – na idéia básica de que um projeto de um sistema de informação deve sempre buscar a simplicidade. Penso nisso com base em um pensamento de Da Vince: “A simplicidade é o último grau de sofisticação”, que meu amigo Wagner Andrade gosta, e muito, de citar.

Mas a bem da verdade, a maioria dos projetos que encontramos e participamos no nosso dia-a-dia não seguem essa premissa básica. Desde a escolha das tecnologias até aos processos (ou a escolha pela falta deles) que serão empregados no gerenciamento do mesmo.

Quando utilizamos orientação a objetos, não podemos ficar presos apenas a conceitos acadêmicos, como: os objetos normalmente são definidos com métodos e assim por diante. Tudo bem, até pode ser uma afirmativa verdadeira. Mas essa é uma visão um tanto quanto limitada para definirmos uma visão concreta para um objeto.

Podemos dizer que um objeto é algo – qualquer coisa, envolvida no nosso domínio de negócios – e que tem apenas uma responsabilidade: a sua. E é essa responsabilidade que determinará comportamentos ao objeto. Essa é uma definição que nos ajuda em pensar o que os objetos provavelmente irão fazer e não apenas em como o implementar.

No desenvolvimento orientado a objetos podemos usufruir de alguns princípios para nos auxiliar no projeto de um sistema de informação. Um dos mais conhecidos deles, por incrível que pareça não é o POG, mas sim o SRP – que traduzido para o português, significa: princípio da responsabilidade única. Ou seja toda e qualquer classe deve possuir apenas uma razão de ser, estar e existir. Vale lembrar que todos os seus serviços devem estar preparados para externalizar somente essa única responsabilidade. Nada além do que se vê.

Como exemplo, podemos utilizar uma classe Automóvel para entendermos a aplicabilidade do princípio. Um automóvel tem a responsabilidade básica de locomoção. Então o mesmo poderá realizar ações como: andar, parar e receber gasolina. Mas jamais poderá ele mesmo trocar os pneus, dirigir, trocar o óleo e assim por diante. Essas são tarefas, respectivamente, do mecânico, do motoristo e do frentista. E não do carro. Tudo bem que até poderia ser uma boa idéia, mas infelizmente não é o que acontece.

Com esse princípio aplicado de maneira correta, estaremos dando um grande passo pra evitarmos o acoplamento de classes, aumentando, também, as chances de termos um domínio de modelos com alta coesão. Essa idéia nos permite desenvolver o software em dois passos: fazer um projeto preliminar sem se preocupar com todos os detalhes envolvidos; e implementar o projeto alcançado anteriormente.

Uma observação: desculpa pela demora pelos posts, estou na Indonésia, trabalhando na implantação de um importante projeto a dois meses e completamente sem tempo. Prometo ser mais assíduo no meu blog de agora em diante.

Abraço a todos.