Recentemente participei do desenvolvimento de um projeto para implementar novas funcionalidades em um sistema de ERP criado em VB6. Sim, VB6 não é uma linguagem O.O., mas possui diversos recursos que se aproximam, como encapsulamento, herança entre outras. Apesar de ser um sistema com mais ou menos uns 10 anos, é um bom sistema. Sua arquitetura é dividida em camadas, possui estrutura de persistência de dados, apesar de estar anos luz de um NHibernate. Coisa que para a época de seu desenvolvimento é muito raro se encontrar hoje no mercado!
Uma única coisa me incomodou: os DESENVOLVEDORES. Apesar da arquitetura ser muito boa, muitos desenvolvedores que tiveram contato com a aplicação e não tinham conhecimentos de projeto de software guiado por responsabilidade. Se tivessem, com certeza manutenibilidade da aplicação seria bem melhor.
Esta não é uma visão isolada. A falta de comprometimento e conhecimento dos desenvolvedores é em maior instância a grande causadora de sistemas deficientes. Pensando nisso vou iniciar um série de diversos artigos apresentando e exemplificando a utilização dos Princípios de Orientação a Objetos e Padrões de Projetos. A ideia apresentar uma forma de raciocinar sobre como projetar objetos de software inserindo conceitos de responsabilidade, papéis e colaboração.
Projeto Guiado por Responsabilidade
A UML define uma responsabilidade como “um contrato ou obrigação de um classificador” [OMG03b]. A ideia de responsabilidade de um objeto (esse raciocínio pode ser aplicado a um escala maior de interação como um componente) é dado pelo seu papel e as obrigações que deve executar, ou seja, pelo seu fazer e conhecer.
As responsabilidades de fazer de um objeto incluem:
- Fazer algo propriamente dito, como criar um objeto ou executar um cálculo.
- Iniciar uma ação em outro objeto.
- Controlar ou coordenar atividade em outros objetos.
As responsabilidades de conhecer de um objeto incluem:
- Ter conhecimento de dados privados encapsulados.
- Conhecer objetos relacionados.
- Ter conhecimento sobre coisas que ele pode derivar ou calcular.
Responsabilidades não é a mesma coisa que um método – é uma abstração – porem métodos satisfazem às responsabilidades. Craig Larman – Utilizando UML e Padrões.
Design Patterns
Em engenharia de software, um padrão de projeto de software (ou o termo em inglês Design Pattern) é uma solução reutilizável para um problema comum em software. Design patterns não é uma solução final que pode ser transformada em código. Ele é uma descrição ou template para como resolver um problema e pode ser utilizado em diferentes situações e tipicamente mostram a relação e interação entre objeto.
GRASP – General Responsibility Assignment Software Patterns
Também conhecido como Princípios de Orientação a Objetos são padrões auxiliam na resolução de alguns problemas, e em quase todos os casos estes problemas são comuns para quase todos os projetos de desenvolvimento de software.
Os princípios de orientação a objetos define 9 padrões, que auxiliam no projeto e desenvolvimento de qualquer objeto na definição de suas responsabilidades, eles são:
- Creator (Criador)
- Information Expert (Especialista de Informação)
- Low Coupling (Baixo Acoplamento)
- High Cohesion (Alta Coesão)
- Controller (Controlador)
- Polymorphism (Poliformismo)
- Pure Fabrication (Invenção Pura)
- Indirection (Indireção)
- Protected Variations (Variações Protegidas)
Conclusão
Dominar o conhecimento e racionar sobre objetos guiado por responsabilidade e entender os princípios de orientação a objetos é é vital para o desenvolvimento de qualquer aplicação orientada a objetos. Não é a utilização de linguagem OO (como C# ou Java) que torna um aplicação orientada a objetos e sim o domínio dos conceitos acima.
