General responsibility assignment software patterns (GRASP)
Conjunto de padrões e princípios para auxiliar no desenvolvimento de arquitetura de software para sistemas orientados a objeto.
Esses princípios são divididos em tópicos, que podem ser aplicados na arquitetura de um sistema. São eles: controller, creator, indirection, information expert, high cohesion, low coupling, polymorphism, protected variations e pure fabrication.
Dentre eles serão destacados apenas 3, que vão fazer mais sentido de maneira geral em qualquer sistema computacional.
Controller (Controlador)
O padrão Controller trabalha com o conceito de objetos para controle de regras de negócio. Os objetos definidos neste padrão não possuem atributos ou métodos relacionados com UI ou acesso a dados. Nele devem estar as regras de como os dados serão processados, e a camada UI deverá interagir com ele através de métodos.
Essa separação pode ser vista no modelo MVC.
Visão ->> Controle ->> Modelo.
Dessa forma podem ser criadas várias interfaces (visões), que vão comunicar com um mesmo objeto de controle que irá tratar as requisições da mesma maneira.
Exemplo: um sistema com interface Web e Mobile.
Essa separação pode ser vista no modelo MVC.
Visão ->> Controle ->> Modelo.
Dessa forma podem ser criadas várias interfaces (visões), que vão comunicar com um mesmo objeto de controle que irá tratar as requisições da mesma maneira.
Exemplo: um sistema com interface Web e Mobile.
High cohesion (Alta coesão)
Alta coesão significa que atributos e métodos que são intimamente relacionados entre si, ficam definidos em um mesmo objeto, pacote ou módulo. Essa alta coesão facilita a interpretação (e a manutebilidade) de um sistema, pois as rotinas e funções ficam divididas entre os objetos que possuem responsabilidade específicas.
Pelo contrário, num sistema com baixa coesão, podem existir classes ou módulos de função, ou arquivos com tantas funções com propósitos diferentes, que é difícil entender o que está lá dentro, e é difícil aproveitar trechos de código para outros propósitos.
EXEMPLO:
Em um sistema com alta coesão:
Classe Colaborador com métodos que validam idade, informações estão cadastradas corretamente, chamar as rotinas de persistência do banco de dados.
Classe Contrato com métodos que validam valor do contrato, categoria do contrato, chamar as rotinas de persistência do banco de dados.
Em um sistema com baixa coesão:
Classe Sistema com todos os métodos das classes que acabei de citar acima + rotinas de validação de CEP, CPF, etc.
Agora sua tarefa é criar uma classe colaborador em um outro sistema e copiar apenas os métodos pertinentes.
Qual é mais fácil?
Além disso, para realizar uma manutenção numa classe grande, a atenção deve ser maior, pois podem existir variáveis globais, constantes globais, e aí a coisa começa a complicar.
Pelo contrário, num sistema com baixa coesão, podem existir classes ou módulos de função, ou arquivos com tantas funções com propósitos diferentes, que é difícil entender o que está lá dentro, e é difícil aproveitar trechos de código para outros propósitos.
EXEMPLO:
Em um sistema com alta coesão:
Classe Colaborador com métodos que validam idade, informações estão cadastradas corretamente, chamar as rotinas de persistência do banco de dados.
Classe Contrato com métodos que validam valor do contrato, categoria do contrato, chamar as rotinas de persistência do banco de dados.
Em um sistema com baixa coesão:
Classe Sistema com todos os métodos das classes que acabei de citar acima + rotinas de validação de CEP, CPF, etc.
Agora sua tarefa é criar uma classe colaborador em um outro sistema e copiar apenas os métodos pertinentes.
Qual é mais fácil?
Além disso, para realizar uma manutenção numa classe grande, a atenção deve ser maior, pois podem existir variáveis globais, constantes globais, e aí a coisa começa a complicar.
Low coupling (baixo acoplamento)
O Baixo acoplamento é a característica que indica que um sistema possui pouca interdependência. Isso significa que os objetos possuem todo o conhecimento para operar sozinhos, e somente para dar vazão ao fluxo é que se comunicam com outros objetos.
Os fatores positivos desse são:
• Baixa dependência entre objetos
• Portabilidade de objetos entre sistemas (para reutilização)
• Mudanças em um objeto tem poucas chances de que seja necessário alterar objetos que interagem com ele.
De <https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)>
Os fatores positivos desse são:
• Baixa dependência entre objetos
• Portabilidade de objetos entre sistemas (para reutilização)
• Mudanças em um objeto tem poucas chances de que seja necessário alterar objetos que interagem com ele.
De <https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)>
Nenhum comentário:
Postar um comentário