As notícias entre os inesperadamente agradáveis despertaram todo tipo de lembranças, doces e não tão. Eu também cheguei a este artigo e imediatamente me cansei de nostalgia, e queria tocar uma elipse tão pesada nos últimos sete anos.
Dephi era uma solução absolutamente brilhante. Bem, você sabe, como os Beatles, como uma interface gráfica de computador com controle de mouse, como um mecanismo de combustão interna. A solução engenhosa que surgiu em nossas vidas tão amplamente que você nem consegue acreditar que ela não existia, e desenhar janelas, caixas de seleção e botões no Windows pode ser uma verdadeira dor de cabeça.
A parte engenhosa, absolutamente, do Delphi era o VCL - o mesmo conjunto de caixas de seleção e botões para janelas do Windows, que de repente se tornou tão fácil e simples arrastar e soltar um sobre o outro e criar aplicativos Windows bonitos e incomuns.
E, como qualquer interface decente, funcionou, é claro, de acordo com o modelo do evento. OnClick no objeto button descreveu tudo o que o botão faz, OnChange ao entrar em um campo de texto, tudo é como nos adultos. Mas daqui em diante - além disso, infelizmente, ainda não havia nada.
Nada do que sabemos agora, quero dizer. O MVC, por exemplo - Delphi, considera que ele consiste em um V, então tudo permaneceu à mercê do desenvolvedor. Diretamente do OnClick para puxar uma solicitação para o banco de dados? Sim por favor No OnChange, abra algum arquivo e tente gravá-lo, e se o arquivo no lugar não travar silenciosamente com algo como Violação de acesso à memória - a cada passo (no entanto, isso não tem nada a ver com o Delphi como plataforma).
E devo dizer que por muitos anos foi completamente feliz para todos, e alguns ainda bastante felizes com isso. Os benefícios de uma biblioteca esbelta e bonita de componentes de interface do usuário são imediatamente visíveis, os benefícios de quaisquer controladores e modelos tornam-se aparentes não no primeiro ano de desenvolvimento, nem nos primeiros cem kilobytes de códigos-fonte.
E mesmo que tenha se tornado - é fácil esquecê-lo, há uma armadilha mental aqui, como aquelas ilusões ópticas e sonoras sobre as quais são ferozmente debatidas na Internet. Então, deixe-me tentar lançar uma pequena ponte do Delphi para um entendimento moderno da interface do usuário e podemos descobrir o que acontece.
Portanto, a ideia principal: separamos a apresentação dos dados, o widget separadamente, todo o trabalho com as informações nele contidas. Quão separado? Digamos, o botão ainda tem uma inscrição e, às vezes, um ícone. O próprio usuário pode direcionar essa inscrição para o campo de texto e, às vezes, o campo de texto possui outra inscrição que explica ao usuário exatamente o que ele dirige. Regra geral: o widget está empenhado em exibir, pelo menos (SIC!) Lógica, o que possa estar presente nele deve ser associado apenas à exibição e nada mais. Digamos, se o botão não estiver pronto para esticar junto com a inscrição - a inscrição deve ser cortada de alguma forma (por exemplo, mostrar as reticências e a versão completa na dica de ferramenta) ou cometer um erro ao tentar definir o valor mais do que o adequado (embora isso a idéia é mais ou menos assim, é provável que esse erro já saia durante a execução do programa, no momento mais inoportuno).
Um campo de entrada de texto pode apagar as conversões de carro do texto se for de linha única, mas não é necessário, por exemplo, inserir apenas números nele - esse não é o trabalho dele. Assim como no manipulador de cliques no botão, não são necessárias verificações, nem redesenhar chamadas, o manipulador de botões deve receber o código externo, que já é responsável pela lógica da interface do usuário e de todo o aplicativo.
E se você mora em um belo mundo novo de jatos, desprezando toda essa confusão de eventos OOP, o princípio permanece o mesmo: pressionar um botão muda seu estado adicionando a Ação correspondente e, em seguida, algum código, o código não associado aos elementos da interface do usuário, consulte esta ação, tire as conclusões apropriadas e altere o estado para que haja algo a ser exibido na interface do usuário.
Ou seja, independentemente do ambiente, plataforma e paradigma, os próprios elementos visuais carregam um mínimo de funcionalidade e nenhuma lógica em si mesmos. Eles recebem informações da forma mais geral; portanto, se você tem um TextBox, também é Input, também é um campo para inserir texto, pega uma string e fornece uma string. E a tarefa de transformar uma linha em um número, o nome de alguém ou algo mais esperto não é mais para o widget.
Bem, então o Controller ou Presenter processa o resultado e produz o resultado. Ligue para ele como você está acostumado, apenas não insira nenhum elemento visual nele.
Qual é o lucro? Listo em ordem do mais óbvio para o mais, na minha opinião, o essencial.
Em primeiro lugar, reutilização. Pode-se gastar bastante tempo entendendo que um campo para inserir um endereço de correspondência, para inserir um sobrenome e para inserir uma soma é, de fato, o mesmo campo. Um e o mesmo widget, com o mesmo conjunto de recursos que se resume a puxar um evento de entrada de texto ou atualizar um estado. E apenas a lógica de trabalhar com o texto dentro dele pode ser diferente. Um exemplo de "como não fazer" na vida: crie um campo para inserir uma quantia em dinheiro (até duas casas decimais) e depois mexa por um longo tempo, refazendo-o para que às vezes você possa inserir uma quantidade no mesmo campo (até 4 casas decimais) . Interrompa no processo todos os locais em que o valor é inserido no aplicativo e repare-os emergencialmente no meio da noite. Isso apesar do fato de que, de acordo com a lógica de seu trabalho, eles tinham diferenças na terceira casa decimal. Você pode escrever poemas sobre como os campos para inserir endereços de email se transformam em campos para inserir endereços geográficos usando herança e as palavras de Deus.
Segundo: testabilidade. Você também pode testar a interface do usuário. Quase qualquer interface do usuário. Mas será caro, em termos de tempo e recursos gastos no desenvolvimento de testes e na execução de testes, e é improvável que eles sejam lançados a cada reconstrução, mas quando os testes falharem no lançamento, isso será de força maior. Porém, os componentes da interface do usuário são os mais arriscados em termos de falhas, em geral, eles quebram, com mais freqüência, de forma mais clara e dolorosa. Mas o código, extraído dos próprios widgets, é realmente coberto por testes de unidade. E os testes de unidade são muito mais baratos - é mais fácil escrever, e você pode executá-lo literalmente após qualquer alteração, e sempre verifique se nada quebrou.
E terceiro, o mais importante, na minha opinião. Desenhar uma parte da interface do usuário juntamente com a lógica como uma única peça é extremamente difícil de derrotar a preguiça e pensar mais profundamente em como ela funciona. Para elaborar cenários, exceto o idealmente positivo, quando o usuário digitou exatamente o que era esperado dele, fez exatamente o que era necessário e recebeu exatamente o que queria. Esse mesmo programador sagrado "tudo funciona para mim".
A separação entre a parte visual e a lógica faz você pensar, primeiro, como a parte visual funciona: o que entra, o que sai dela, o que acontece se algo que não se esperava que entre ou saia não funcione. E escrever a lógica separadamente do controle obriga a escrevê-la nos casos, ou seja, de acordo com os cenários possíveis para o uso de um aplicativo específico em um local específico, incluindo erros de processamento que surgem aqui e ajudando o usuário nas dificuldades que ele experimenta aqui. Bem, sim, nem sempre, ou melhor, não em tudo, uma solução em geral é melhor do que uma solução personalizada para um caso específico.
Para resumir. Você pode escrever no Delph, ou um aplicativo para iOS, torturar a longínqua web por algum tipo de 0 ou rebitar algum jogo de microcontrolador no Python, se o seu código tiver superado a fórmula "um molde, uma consulta, um resultado" - eu lhe direi Eu recomendo fortemente separar os widgets de qualquer lógica do trabalho deles, e então existe a chance de que haja menos moscas em suas costeletas. E, apesar da perfeita não óbvia inicial das vantagens de uma solução, quanto mais você trabalha com ela, mais essas vantagens aparecerão para você.