Como determinar se o Padrão de Design foi implementado corretamente?

Consigo dimensionar com êxito todos os meus aplicativos antigos que não estavam usando Padrões de Design documentados. Qualquer que seja o padrão, não sei. Em grande parte, senti apenas a necessidade de usar conceitos simples de POO.

O conceito Design Patterns é complexo e difícil de entender. Quando implementado, como determinar se a implementação está correta e o aplicativo possui um acoplamento frouxo real?

Para manter a resposta concisa, eu diria que se as seguintes características são visíveis no seu código, você pode ter certeza de que os padrões estão em vigor, mesmo que você não tenha feito esforços deliberados (o que não é um problema) para isso.

Características desejadas:

1. Sua base de código é testável no nível da unidade
2. Sempre que você estiver implementando alguma solicitação de mudança, estará fazendo alterações apenas nas classes relevantes que se relacionam no domínio.
3. Sua base de código não está exibindo entropia de software .

Se você ainda está curioso para identificar e marcar seu código com os nomes dos padrões reais, recomendo que você execute as seguintes ações para fazer a bola rolar.

1. Faça engenharia reversa de sua base de código para gerar alguns daigrams UML.
2. Compare visualmente os diagramas com qualquer referência pronta do material de referência de padrões.

Isso deve lhe dar uma idéia justa.

Você menciona os padrões de design e o acoplamento. Estes são conceitos separados, por isso vou lidar com eles separadamente. A única conexão real é que os padrões de design tendem a promover acoplamentos frouxos (já que esse é um aspecto importante do bom design).

Padrões de design

O conceito de Design Patterns é bastante simples: eles são apenas um conjunto de modelos de como lidar com vários problemas comuns. Existem 2 razões principais pelas quais eles são populares:

1. Eles são 'comprovados': já foram usados ​​muitas vezes e os benefícios / desvantagens de cada um são geralmente conhecidos, em particular quaisquer problemas sutis que possam causar grandes problemas são conhecidos.
2. Eles fornecem um conjunto comum de terminologia e, portanto, facilitam a comunicação. Se alguém disser que "a classe X desempenha o papel de observador no padrão de observador", os desenvolvedores familiarizados com o padrão poderão entender imediatamente o que está acontecendo.

Como você sabe que o implementou corretamente? Essa é complicada. Para a maioria dos padrões, é simples - você grocou ou não. Alguns padrões são menos claramente definidos que outros - por exemplo, model-view-controller . Padrões como esse são melhor usados ​​como diretrizes gerais. As especificidades de como você o implementa são menos importantes do que entender as razões pelas quais o padrão existe e o que ele pretende realizar.

Os padrões de design não são "o único caminho verdadeiro". Frequentemente, você precisará adaptá-los para seus propósitos específicos ou, às vezes, não haverá padrões que atendam aos requisitos. Forçar um padrão de design onde ele não se encaixa é uma má idéia; é como usar um martelo muito bom quando o que você realmente quer é uma chave de fenda.

Acoplamento

Esta é uma ideia realmente importante em ciência da computação. Como os requisitos para a maioria dos projetos de software mudam com o tempo (às vezes significativamente), é importante a capacidade de um design para lidar com as mudanças. O acoplamento é basicamente a medida de "quão difícil seria trocar esse componente por outro?" O 'componente' pode ser um método, classe, pacote, biblioteca etc.

Existem vários tipos de acoplamento listados neste artigo da Wikipedia .

A resposta é realmente o objetivo que você deseja escrever padrões de design desde o início. Por que você deseja flexibilidade?

Isso é mudança; mudança de requisitos. Tente alterar algo em seus requisitos que reflita na alteração do código e veja como é fácil / difícil fazer isso.

O uso de padrões de design é uma ação preventiva. Você usa padrões de design para facilitar seu trabalho ao dimensionar o aplicativo posteriormente. Obviamente, para facilitar seu trabalho mais tarde, você deve fazer um pouco mais de trabalho agora. então a verdadeira questão é quanta mudança você pode esperar no futuro e qual é essa mudança. Se você não precisar de escalabilidade e flexibilidade, poderá acabar com os padrões de design.

Os próprios padrões de design são uma implementação dos Princípios de Design Orientado a Objetos. Contanto que você siga esses princípios, seus aplicativos serão flexíveis e escaláveis; mesmo se você realmente não tiver um padrão de design real. Como Joachim Sauer comentou acima, são soluções comuns para problemas comuns.