Os princípios fundamentais de design de software!

O que torna o design de software sustentável? Lógica bem expressa por meio de linguagem poderosa e seu açúcar sintático? Ausência de código clichê? Coesão apertada e solto acoplamento? Usar padrões de design e evitar antipadrões? Falar nomes de classes, métodos e variáveis?

Eles são úteis de tempos em tempos, mas não garantem nada e são difíceis de raciocinar objetivamente. Línguas profundamente açucaradas tendem a ser mais complexas para ler e estudar e mais difíceis para impor padrões de qualidade. O uso excessivo de padrões de design geralmente leva a um excesso de design. Há décadas de métricas para estimar a coesão e o acoplamento e nenhuma delas é precisa o suficiente para fazer decisões. E certos nomes podem significar coisas completamente diferentes em diferentes contextos.

Todos nós sentimos a dor quando o código que mantemos é uma bagunça, mas o que significa "uma bagunça" que normalmente não podemos formular presencialmente. Encontrei para mim o melhor, o menor, o mais simples e o mais universal critério de manutenção. E funciona especialmente impecável com Elegant Objects.

Os principais princípios que descrevi são os seguintes:

-Cada componente reutilizável auto-suficiente de alguns softwares deve ser abstrato ou concreto. -Os componentes abstratos são bons para definir um propósito de aplicação e intenções de suas partes, enquanto os componentes concretos são bons para implementar os requisitos de software do usuário final. -Componentes abstratos devem ser estáveis, enquanto componentes concretos devem ser fáceis de mudar. -Componentes abstratos nunca devem depender de componentes concretos.

Na verdade, isso é tudo que você precisa saber sobre o design. Para aplicar esses princípios, a única coisa que resta é decidir como abstrato ou concreto é cada componente do seu sistema e restringi-lo de acordo. Tudo o mais - padrões, antipadrões, paradigmas e conceitos errôneos, construções de linguagem e recursos de frameworks - derivam essa ideia central e ajudam os desenvolvedores a segui-la, ou levar a problemas, especialmente quando incompreendidos. Os princípios que descrevi acima são aplicáveis ​​em qualquer sistema, consistindo de partes de código auto-suficientes e reutilizáveis. Essas peças podem ser qualquer coisa - classes / interfaces, procedimentos, funções, bibliotecas, módulos ou até mesmo processos e microservices: se eles podem ser reutilizados em vários locais do sistema, eles são a fonte dos mesmos problemas de design. A reutilização é impossível sem o acoplamento, e o acoplamento sempre torna a manutenção do sistema mais difícil em algum grau. Seguindo estes quatro princípios, você pode manter o impacto na manutenção do acoplamento no mínimo.