Tag: Coesão

Acoplamento e Coesão em Módulos e Funcionalidades

 

No último post falamos sobre Acoplamento e Coesão, que são medidas que devemos sempre levar em grande consideração no projeto de qualquer software.

E nada melhor que entender a teoria aplicada, ou seja, vê-la na prática. Vamos começar a refletir sobre isso.

Neste post vamos falar sobre Acoplamento e Coesão em Módulos e Funcionalidades.

Acompanhe esta série de posts, pois falaremos ainda sobre estas duas medidas aplicadas em vários outros modelos/artefatos do processo de produção de software.

Qualquer software – seja um aplicativo comercial, um sistema de gestão, um website, um aplicativo mobile ou até mesmo um jogo – é composto, basicamente, de Módulos e Funcionalidades.

Um software é um todo. Módulos são conjuntos dentro deste todo. Funcionalidades são elementos deste conjunto. (more…)

Acoplamento e Coesão

Acoplamento e Coesão talvez sejam as características mais importantes de qualquer sistema.

Muitos sistemas são como um Castelo de Cartas.

Num Castelo de Cartas, ao tirar uma carta da estrutura, a probabilidade de estragos no castelo é alta. Se a carta estiver na base (parte inferior) do castelo, é quase certo que o castelo irá desmoronar.

E nos sistemas, não é muito diferente. Todo profissional da área já passou por algum sistema onde corrigi-se um bug e aparecem outros vinte; exclui-se uma funcionalidade e outras várias param de funcionar ou apresentam defeitos etc. (more…)

UML – Relacionamento entre Classes – Agregação

UML - Relacionamento de Agregação entre ClassesVocê já se perguntou o que é o relacionamento de Agregação entre Classes?

É algo que parece abstrato, mas é mais simples do que imaginamos.

Mas o uso inadequado da Agregação gera Alto Acoplamento e Baixa Coesão na estrutura de um software.

Este é o terceiro post sobre relacionamentos entre classes na UML – aqui você pode ver o primeiro sobre Dependência entre Classes, e aqui pode ver o segundo sobre Composição entre Classes. (more…)

Design Pattern Facade

Façade

Façade

Façade (ou Fachada, em português) é um termo muito oriundo da área de Arquitetura.

A grosso modo, podemos entender como a parte de fora de uma construção, que isola o mundo exterior o mundo interior.

Quando levamos o conceito para a Engenharia de Software, focando a arquitetura/estrutura de um sistema, do ponto de vista de semântica, a ideia é a semelhante.

Estruturalmente falando, isolamos partes do sistema (sub-sistema) com o uso de uma fachada (façade) e somente através dela (passando por ela) é que temos acesso ao sub-sistema.

/* Quando me refiro a “sub-sistema” pode se tratar de várias coisas: uma classe/objeto, um conjunto de classes/objetos [biblioteca, framework, API etc.], um módulo de um sistema, um conjunto de webservices etc. Neste post vamos nos referir sempre a sub-sistema, para padronizar o uso do termo no texto e facilitar o entendimento. */
(more…)

Relacionamento entre Classes – Composição

Relacionamento de Composição entre Classes - Composição - Corpo HumanoComposição no Corpo Humano

Vamos entender o relacionamento de composição entre classes através de uma analogia com o corpo humano.

O que é o corpo humano? É um sistema.

Do ponto de vista Conceitual, como um software, podemos interpretá-lo composto de Módulos, Domínios, Funcionalidades, Requisitos Funcionais, Requisitos Não Funcionais e Regras de Negócio.

Do ponto de vista Estrutural, também como um software, podemos interpretá-lo como um Namespace ou Pacotes, composto de Classes, classes compostas por outras classes, todas com seus métodos etc.

Uma Mão é composta por Dedos. Podemos entender a Mão como uma Classe, do Namespace Braço, e a classe Mão possui cinco composições da classe Dedo.

Uma mão comum é composta por cinco dedos: Polegar, Indicador, Médio, Anelar, Mindinho).

(more…)

Principio Open/Closed – SOLID – OCP

solid-open-closed

O Princípio OCP (Open/Closed Principle) é um princípio do SOLID.

O Princípio é de que no software, o código deve ser aberto para extensão, mas fechado para alteração.

Mas o que isso quer dizer? Vamos entender melhor neste post.

Todo software é dinâmico, evolui constantemente durante sua vida. Uma hora o software “morre”, torna-se obsoleto e para de evoluir. Geralmente é substituído por outro software.

Essa evolução se dá através da manutenção no software.
(more…)

Principio da Responsabilidade Unica – SOLID – SRP

Principio da Responsabilidade Unica - SOLID - SRPO Princípio da Responsabilidade Unica (SRP do SOLID) é um mantra a ser seguido, quando o assunto é fraco acoplamento e alta coesão.

Quem faz tudo não faz nada. Diz o ditado.

Onde se tem muita generalização não é possível ter especialização. E em software, especializar é boa prática, premissa para uma boa modelagem.

Misturar responsabilidades não é uma boa.

No contexto da Orientação a Objetos, o Princípio da Responsabilidade Unica (SRP) do SOLID define que uma classe deve possuir apenas uma responsabilidade, e esta responsabilidade deve estar totalmente encapsulada na respectiva classe. A seguir alguns exemplos descritivos.
(more…)