Como programadores, sinto que nosso objetivo é fornecer boas abstrações no modelo de domínio e lógica de negócios fornecidos. Mas onde esta abstração deve parar? Como fazer o trade-off entre abstração e todos os seus benefícios (flexibilidade, facilidade de alteração etc.) e facilidade de entender o código e todos os seus benefícios.
Acredito que tento escrever código excessivamente abstraído e não sei como é bom; Costumo escrever como se fosse um micro-framework, que consiste em duas partes:
Esta é uma boa abordagem na programação? Que, tendo código de mudança muito fragmentado em muitos módulos e muito fácil de ser entendido e não alterar código muito complexo a partir da abstração POV? Deveria todo o código ser uniformemente complexo (que é o código 1 mais complexo e interligado e o código 2 mais simples) para que qualquer pessoa que o analise possa entendê-lo em um tempo razoável, mas a mudança é cara ou a solução apresentada acima é boa, "alterar código" é muito fácil de ser entendido, depurado, alterado e "vincular código" é um pouco difícil.
Nota: isto não é sobre a legibilidade do código! O código em 1 e 2 é legível, mas o código em 2 vem com abstrações mais complexas, enquanto o código 1 vem com abstrações simples.
As primeiras palavras do TC ++ PL4:
Todos os problemas em ciência da computação pode ser resolvido por outro nível de indireção, exceto pelo problema de muitas camadas de indireção. - David J. Wheeler
(David Wheeler foi meu orientador de tese. A citação sem a última linha importante às vezes é chamada de "A primeira lei da Ciência da Computação".)
Sim, definitivamente. O problema é que nenhuma abstração é perfeita. Todos os detalhes da camada sobre a qual as abstrações estão lá estão por um motivo, e isso pode simplificar muitas coisas, mas se essa complexidade não fosse necessária em algum momento, provavelmente não estaria lá em primeiro lugar. E isso significa que, em algum momento, todas as abstrações vazarão de alguma forma.
E é aí que está o verdadeiro problema. Quando as abstrações falham, quanto mais você tem camadas entre o código que você escreveu e o que está realmente acontecendo, mais difícil é descobrir o problema e consertá-lo, porque há mais lugares onde o problema pode estar. E quanto mais camadas houver, mais você precisa saber para rastreá-las.
Sim, com certeza.
A analogia que eu gosto de usar para explicar a programação é a de um Tailor. Ao fazer um terno, um bom Tailor sempre deixará uma pequena quantidade de tecido em locais estratégicos dentro do vestuário para permitir que a peça seja levada para dentro ou para fora, sem alterar sua forma ou estrutura geral.
Bom Alfaiate não deixe resmas de tecido em cada costura apenas caso você cresça um terceiro braço, ou fique grávida. Demasiado material nos lugares errados contribuirá para uma má adaptação e vestuário mal utilizado, o tecido extra simplesmente fica no caminho do uso normal. Para o tecido pouco eo vestuário é propenso a lágrimas e não será capaz de ser alterado para lidar com pequenas alterações no corpo do seu portador, efetuando o modo como a peça fica.Talvez um dia, nosso bom alfaiate será encarregado de fazer um vestido tão apertado que ele tem que costurar a usá-lo. E talvez o nosso Bom Alfaiate seja convidado a fazer roupas de maternidade, onde o estilo e o ajuste são os segundos do conforto e da capacidade de expansão. Mas antes de empreender qualquer desses trabalhos especiais, um bom Alfaiate seria sábio o suficiente para conscientizar todos os compromissos que estão sendo feitos para alcançar esses objetivos.
Às vezes, esses compromissos são o caminho correto a seguir e as pessoas estão dispostas a aceitar suas consequências. Mas, na maioria dos casos, a abordagem de deixar um pouco mais importante será superior a qualquer benefício percebido.
Então, relacionando isso de volta à abstração. É absolutamente possível ter muitas camadas de abstração, assim como é possível ter muito pouco. A verdadeira arte do programador, como os nossos alfaiates amigos, é deixar um pouco o que conta mais.
Voltando ao assunto.
O problema com o código geralmente não é abstração, mas dependências. Como você apontou, é o código que conecta objetos discretos que é um problema, porque há uma dependência implícita entre eles. Em algum ponto, a comunicação entre coisas só precisa ser concreta, mas julgar onde esse ponto geralmente requer alguma adivinhação.
Dito isso, "Micro" é geralmente uma indicação de que você supergranulou o layout do objeto e provavelmente está usando Type como sinônimo para o que deve ser Data . Ter menos coisas também significa menos dependências necessárias para se comunicar entre elas.
Sou um grande fã de mensagens assíncronas entre sistemas por esse motivo. Você acaba com dois sistemas dependentes da mensagem , ao invés de um ao outro. Dando-lhe menos acoplamento entre sistemas de comunicação. Nesse ponto, se você precisar ter uma dependência entre os sistemas, precisará considerar se possui os bits dependentes no (s) local (is) certo (s). E é frequentemente o caso que você não faz.
Finalmente, o código complicado será complicado. Não há muitas maneiras de contornar isso. Mas o código que tem menos dependências é muito mais fácil de entender do que aquele que depende de vários estados externos.
I feel that our goal is to provide good abstractions on the given domain model and business logic.
Eu tenho uma visão diferente: nosso objetivo é resolver um problema de negócios. Abstrações são apenas uma técnica para organizar uma solução. Outra resposta usa a analogia de um alfaiate fazendo roupas. Eu tenho outra analogia que eu gosto de pensar: um esqueleto. O código é como um esqueleto e as abstrações são as juntas entre os ossos. Se você não tem juntas, então você acaba com um único osso que não pode se mover e é inútil. Mas se você tem muitas articulações, você acaba com uma pilha de geléia desleixada que não pode ficar de pé sozinha. O truque é encontrar o equilíbrio certo - articulações suficientes para permitir o movimento, mas não tanto que não haja uma estrutura ou forma definida real.