S.O.L.I.D
"Bons sistemas de software começam com um código limpo. Por um lado, se os tijolos não são bem feitos, a arquitetura da construção perde a importância. Por outro lado, você pode fazer uma bagunça considerável com tijolos bem feitos. É ai que entram os princípios SOLID."
Bob defende que os princípios SOLID nos diz como organizar as funções e estruturas de dados em classes e como essas classes devem se relacionar.
Single Responsibility Principle - S.R.P
Um módulo deve ser responsável por apenas um ator. Um módulo pode ser entendido como sendo um grupo coeso de funções e estruturas de dados. A forma de identificar a violação desse principio, é observando se uma classe faz o que não deve. Exemplo: classe Funcionário tem método para calcularPagamento, algo que deveria ser feito por um departamento de contabilidade, etc. Basicamente, o SRP diz para separarmos o código que diferentes atores dependam dele.
Caso um módulo tenha suas partes quebradas em muitas outras para atender a esse princípio, talvez o padrão Facade seja uma solução.
Em um nível arquitetural, esse princípio aparece como o "Eixo de mudança (Axis of change)", responsável pela criação de limites arquiteturais.
Open Closed Principle - O.C.P
O princípio do aberto-fechado defende que algo deve estar aberto para crescimento mas fechado para mudanças. Um exemplo disso, é considerarmos uma interface que gera relatórios financeiros. Essa interface não deve depender de mudanças em classes de baixo nível usadas para satisfazer a necessidade de gerar relatórios, digo, claro que são elas que fazem o trabalho pesado, mas a interface não deve mudar em detrimento do código contido nas classes de baixo nível. Todavia, essa interface deve estar aberta para carregar novos comportamentos.
O objetivo da OCP consiste em fazer com que o sistema seja fácil de entender sem que a mudança cause um alto impacto. Para isso, organizamos um sistema em uma hierarquia de dependência que proteja os níveis mais altos das mudanças dos componentes de nível mais baixo.
WIP.