Acontece que o projeto pára e seu desenvolvimento se torna impossível. Não raro, o motivo dessa falha é a arquitetura malsucedida estabelecida no início do desenvolvimento. Ou você tem que discutir sobre qual das "duas cadeiras" é melhor, ou talvez até participar e não entender sinceramente como o seu oponente pode pensar assim!?
Depois, tentaremos não entender muitas abstrações, de onde elas vêm e o que fazer com elas.
Segundo a Wikipedia, a abstração é uma generalização teórica como resultado da abstração. Por sua vez, a abstração é uma distração no processo de cognição de partes não essenciais, propriedades, relações de um objeto (objeto ou fenômeno), a fim de destacar suas características regulares e essenciais.
A partir da definição, podemos concluir que apenas significativo pode ser uma abstração. Nesse caso, a percepção é apenas uma projeção do mundo real. Acontece que todas as reflexões sobre o real são reflexões sobre nossos modelos do real.
As abstrações formam hierarquias e podem ser identificadas com entidades privadas e combinar entidades semelhantes em abstrações de nível superior.
Abstrações de consciência
Além do prisma da percepção, nossos modelos estão sujeitos a mais uma distorção: as entidades reais são extremamente complexas e têm diferentes aspectos e parâmetros. Ao pensar ou falar sobre algo, sempre há um contexto em que um modelo existe. E às vezes acontece que os interlocutores desse contexto são diferentes. E ainda por cima, a presença ou ausência de experiência (global) leva a uma mudança ainda maior em nossos modelos de acordo com essa experiência. Como resultado, duas pessoas diferentes podem ter percepções muito diferentes das mesmas entidades do mundo real.
Acontece que toda pessoa está constantemente lidando com abstrações, resta aprender a vê-las e gerenciá-las claramente. Pode-se apresentar a tese de que o código do programa é uma simulação de pensamento com base em abstrações formalizadas. Portanto, na minha opinião, o desenvolvimento de software é um dos melhores simuladores para bombear o pensamento abstrato.
Abstração em desenvolvimento
As interfaces de programação são talvez a abstração formalizada mais óbvia. Todo supérfluo é cortado e apenas "o que faz" permanece sem "como faz".
Ao implementar a interface, criamos um modelo mais realista de comportamento ou interação, que já pode responder à pergunta "como". Ao combinar interfaces entre si, podemos criar uma arquitetura de código comum. Com habilidade e destreza adequadas, a arquitetura criada dessa maneira manterá sua estrutura no futuro. Enquanto a implementação de interfaces compostas pode mudar além do reconhecimento.
Essa arquitetura simplifica alguns pontos do trabalho. O teste de unidade se resume a escrever implementações de teste de abstrações "vizinhas" e métodos de teste que comparam entrada e saída. O isolamento dos módulos permite realizar a refatoração com segurança. Além disso, se a refatoração foi malsucedida e tudo quebrou, será necessário reverter apenas um módulo. Um módulo suficientemente abstrato pode ser usado para tarefas semelhantes, mas diferentes. Ao mesmo tempo, uma má implementação não afetará o trabalho de outras pessoas - o isolamento do govnokod.
ExemploHá um módulo para processar dados de entrada, existem várias opções para obtê-los: do banco de dados; do arquivo; por http. Esse problema pode ser resolvido destacando uma interface comum para recebimento de dados e implementando cada canal e canal de dados para teste. Agora, um manipulador pode resolver vários problemas semelhantes usando o parâmetro "canal de dados". E se uma das implementações for uma curva, ela poderá ser refeita para afetar outros módulos.
Abstrações não são mais necessárias
Não há soluções perfeitas e, portanto, com abstrações, as coisas não são tão fáceis. Primeiro, as abstrações são subjetivas, elas podem causar um debate sobre onde uma começa e outra começa. Há também o problema de abstração excessiva, quando uma abstração diferente é criada para cada tipo e tonalidade de um espirro. Em segundo lugar, essa abordagem aumenta a complexidade do código adicionando novas entidades e novos níveis de hierarquia. Estou certo de que ainda haverá deficiências nessa abordagem, algumas delas serão subjetivas, em parte situacionais, mas haverá
Deve haver um equilíbrio em tudo. Para mim, deduzi o seguinte memorando.
- Se você estiver escrevendo um módulo grande e importante - é melhor desativá-lo.
- Se o módulo for usado muito e / ou em lugares diferentes, é melhor escondê-lo atrás de uma abstração.
- Se o módulo deve ser distribuído como uma biblioteca separada, é melhor usar abstrações.
- Se for possível alterar algoritmos ou caminhos de interação, é melhor implementar a interação de abstrações.
- Se a classe for usada em outra classe e em nenhum outro lugar - você pode pensar em combiná-las ou deixá-las como estão.
- Se esta é uma pequena tarefa "única" - é melhor não se preocupar com sua complicação.
- Se este é um módulo que provavelmente nunca mudará - você pode exibir sua interface e é melhor deixar tudo como está dentro.
Total
As abstrações são uma ferramenta incorporada em nossas mentes, como qualquer outra que tenham seus prós e contras, mas conhecer as alternativas só ajuda a encontrar uma maneira melhor.