Você começa a escrever a classe GUI primeiro ou ao contrário?

Quero escrever meu primeiro programa Java, por exemplo, Agenda de telefones, e me pergunto o que fazer primeiro. Minha pergunta é: devo escrever classes GUI primeiro ou util classes primeiro? Sou desenvolvedor de banco de dados e quero conhecer as melhores práticas na criação de programas.

Em teoria, existem pelo menos cinco abordagens possíveis.

Careca:

Comece com simulações da interface do usuário ou um protótipo de papel. Transforme-os em diálogos reais e trabalhe da maneira que deseja, desde os manipuladores de botão e outros controles até a lógica e o banco de dados.

Debaixo para cima:

Comece com as estruturas de dados (provavelmente o esquema do banco de dados). Em seguida, adicione lógica (modelando processos do mundo real); finalmente, sua interface do usuário é apenas uma interface para acionar a lógica e exibir os resultados.

Lógica primeiro:

Comece com a lógica do programa, implementando o acesso a dados e uma interface do usuário rudimentar, conforme necessário. Formalize e reforce as estruturas de dados e, finalmente, aprimore a interface do usuário corretamente.

Conheça no meio:

Comece com o esquema do banco de dados e a interface do usuário e trabalhe simultaneamente para o ponto em que eles se encontram. Com essa abordagem, a lógica vem por último.

Expansão horizontal:

Comece identificando a quantidade mínima absoluta de funcionalidade que faria algo interessante e implemente toda a pilha (estruturas de dados, lógica e interface do usuário) desta parte. Poderia ser apenas um ciclo CRUD básico com uma caixa de diálogo de edição simples para apenas uma entidade. Em seguida, comece a adicionar mais recursos, implementando toda a pilha para cada recurso (daí 'horizontal').

Cada um deles tem prós e contras.

De cima para baixo fornece algo visível no início do processo e permite que você verifique seu design funcional com as partes interessadas - as simulações geralmente dizem aos usuários mais sobre um design do que fluxogramas ou paredes de texto.

De baixo para cima, você tem a chance de criar um esquema de banco de dados sólido antes de se comprometer com qualquer coisa; como um esquema de banco de dados é notoriamente difícil de modificar uma vez liberado, você deseja acertar esta parte - o impacto da modificação de uma interface do usuário é muito menor e produz bugs cada vez menos graves.

Primeiro a lógica significa que você pode testar a lógica antes de gastar muito tempo no banco de dados e na apresentação, o que é especialmente interessante se sua lógica for realmente complexa.

O meet-in-the-middle combina as vantagens de baixo para cima e de cima para baixo, mas você terá que alternar entre duas tarefas e corre o risco de acabar com uma lógica mais complexa do que o necessário, porque suas duas terminações. não se encontram naturalmente.

A expansão horizontal funciona bem com um fluxo de trabalho iterativo e tem a vantagem adicional de que, se você priorizar bem, terá um aplicativo em funcionamento a qualquer momento; portanto, se você não cumprir um prazo, terá uma versão com menos recursos, mas ainda é totalmente funcional, ao contrário de uma versão que possui um banco de dados completo, mas sem interface do usuário.

Então, qual você escolhe depende do seu estilo pessoal e das circunstâncias.

Se você é desenvolvedor de banco de dados, acho que deve começar com um modelo de dados e criar uma boa camada de abstração para facilitar a definição da interface do usuário (seja GUI ou não).

Pessoalmente, eu analisaria as preocupações do usuário e partiria daí. Idealmente, o aspecto do aplicativo que requer a maior quantidade de trabalho deve começar primeiro.

Nesse cenário, eu focaria na simulação da interface do usuário como foco principal. O cliente manifestou preocupação em oferecer suporte a um grupo diversificado de usuários finais, especialmente aqueles com impedimentos visuais, e em distribuir o sistema através de linhas culturais. Portanto, embora tenha um sistema funcional e estável seja crítico, a importância de ter uma interface que permita que os usuários realizem facilmente o trabalho é precedente.

Esse cenário teria me concentrado na lógica do domínio. O cliente solicitou um sistema com interações comerciais complexas. Ele armazenará grandes quantidades de estruturas de dados complexas. Assim, o trabalho inicial de descoberta e implementação da lógica de negócios com armazenamento da fonte de dados levará a um projeto bem-sucedido.

Se o sistema for um projeto pessoal, concentre-se no que você deseja aprender com o projeto. Se estou experimentando uma nova tecnologia, tento me concentrar em um pequeno pico e isolar a própria tecnologia para entender melhor como ela funciona. No entanto, um projeto pessoal que passa por todas as etapas terá o benefício de melhor prepará-lo para projetos "reais". Nesse caso, eu descreveria alguns dos principais objetivos e os usaria como um trampolim. Se este aplicativo de catálogo telefônico for um projeto pessoal seu, sugiro trabalhar primeiro na interface do usuário. Como desenvolvedor de banco de dados, suponho que você saiba como conectar bancos de dados à lógica do domínio e aproximadamente como escrever a lógica do domínio, mas não tenha explorado tanto as tecnologias da interface do usuário; portanto, trabalhar na interface do usuário deve beneficiar seu aprendizado mais do que começar na fonte de dados ou na lógica do domínio.

Comece com a parte do projeto que você achar mais interessante. Se você começar com a parte da qual não gosta, poderá sair antes de progredir. O ponto de partida é principalmente uma questão de preferência, assim você pode escolher o que mais deseja trabalhar.

Comece com o domínio ou o que você chama de 'classes util'. Teste-o independentemente da sua implementação de interface do usuário. Dessa forma, você obtém uma melhor compreensão de como seu aplicativo se comporta (ou deve se comportar), como a lógica é executada, independentemente de qual estrutura de interface do usuário, MVC ou outros enfeites, ferramentas, estilos que você planeja usar no final.

Vincular-se a uma implementação específica da interface do usuário geralmente é uma má ideia. Não estou dizendo que você não deve considerá-lo com antecedência. Estou dizendo que seu aplicativo não deve depender dele. A interface do usuário tende a mudar MUITO no decorrer de um projeto e, se seu domínio estiver vinculado a ele, você também mudará muito seu domínio.

Quase todo mundo terá um método diferente de desenvolvimento que se adapte ao seu estilo. Por exemplo, uma pessoa pode achar mais fácil projetar sua GUI se tiver definido a arquitetura subjacente e o armazenamento de dados. Outra pessoa pode achar, no entanto, que brincar com a GUI e obter um rascunho inicial pode ajudá-la a organizar melhor seu sistema de armazenamento e codificar seu programa de maneira mais organizada. A tarefa à sua frente será descobrir qual método (ou talvez algum híbrido dos dois) funciona melhor para você. Para mim, prefiro fazer uma maquete inicial da aparência da GUI e começar a trabalhar nas porcas e parafusos do aplicativo. Depois de fazer isso, normalmente volto e faço alterações na GUI, conforme necessário.

Este é um projeto bastante simples, onde eu diria que não é tão importante. Em muitos projetos, porém, não será imediatamente claro exatamente como você deseja que a GUI pareça e opere, e depois que você a criar, alguém poderá solicitar que você a altere. É bom fazer maquetes rápidas da GUI para que você ou quem está no comando possa tomar uma decisão concreta sobre como ela deve ser, e isso ajudará você a ver algumas das partes corretivas dos dados necessários para rastrear essas informações. você pode não ter percebido se tivesse iniciado o design dos dados.

Mais importante, você NÃO deseja que seu design de dados conduza sua interface de usuário. Em termos relativos, acredito que corrigir implementações ruins de GUI é muito mais fácil do que corrigir implementações ruins de dados. Então, eu definitivamente voto para começar com a GUI.

E eu sou mais um cara de banco de dados, apenas para sua informação.