Loading
Nota de Estudos
Study Reminders
Support
Text Version

Interfaces De Linha De Comando para Interfaces Gráficas do Usuário

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Olá, bem-vindo ao desenvolvimento moderno de aplicativos. Nesta semana, estudaremos a transição das interfaces de linha de comando para interfaces gráficas de usuários. E como parte dessa transição, aprenderemoslições sobre quais tipos de novas ideias precisam estar envolvidas quando fazemos a transição de nossos aplicativos básicos de processamento de lote de processamento de lote para aplicações interativas com interfaces gráficas de usuários,e mais tarde nessas lições irá se traduzir para o mundo do desenvolvimento de aplicações web.(Consulte o Tempo do slide: 00:48)
Era uma vez todo mundo usava interfaces de linha de comando porque essa era a única tecnologia que estava ao redor. Como o nosso progresso de tecnologia inventamos a ideia melhor de uma interface gráfica do usuário. Nesse ponto, se você tivesse perguntado aos nossos usuários exatamente de que maneira nossa interface gráfica com o usuário é melhor, então eles podem ter dito algo como como eles vão ficar melhor, e que eles sãomais fáceis de usar.
Mas como programadores, precisamos desempacotar essas afirmações para entender precisamente o que é quetorna as interfaces gráficas de usuários melhores. E o que é que torna as interfaces gráficas mais fáceis de usar.O “ look better ” parte em alguma medida vem da pura beleza das gráficas, especialmente emnosso dia, onde interfaces gráficas se tornaram extraordinariamente elegantes e esteticamentesatisfatórias. Mas há um outro lado para ele.Além disso, os looks sendo puro e simples, interfaces gráficas de usuário são mais coisas como se sentiammais próximos de nossa experiência de vida real em usar as coisas que estão ao nosso redor. Por exemplo, botões são um exemplo clássico dede algo que se traduz muito bem do mundo real na interface do usuário.Desde os dias de lâmpadas elétricas, os botões foram onipresentes, e por isso eles são muitonaturais para usarmos.
Os botões pareciam naturais antes de nos habituarmos a sistemas elétricos não me parecenecessariamente verdadeiro para mim. Essa ideia às vezes é chamada de skeuomorfismo, a ideia de que você émimetizando as coisas no mundo real e usando-as como interfaces para coisas que não são reais no computador. Sendo assim, esse é um sentido em que as interfaces gráficas de usuário são mais fáceis. Mas há mais a issodo que até mesmo apenas a aparência ou a semelhança com coisas do mundo real.O que encontramos é que a natureza da interação, a própria experiência que o usuário tem do que acontecequando usam interfaces gráficas é diferente da de usar uma interface de linha de comandos. Parauma coisa com GUIs podemos interagir várias vezes com um programa sem ter que começar eparar aquele programa todo o tempo. E isso significa que o app agora pode reter contexto porque ele aprendeda história, ele se lembra do que estava acontecendo, e você pode usar essas informações para melhorar a interação do usuário.
Vamos ver um exemplo simples de como o gerenciamento do contexto histórico torna as coisas mais fáceis, começandocom uma versão simples do nosso app. Mas o geral, mais real-vida, versão do exemplo simplesque veremos é vem sob um tópico chamado design de interação. Isto não é apenas sobre como um
A aplicação parece mas como é que um usuário pode encontrar o aplicativo natural para usar sem interação muito.
Um famoso livro chamado About Face by Alan Cooper fez pela primeira vez a ideia de design de interaçãopopular, a primeira edição deste livro em meados da década de 90s, e talvez aquele livro tenha falado sobre desktopapps e a última edição em cerca de 2014 agora abrange, por exemplo, coisas como aplicações móveis.Nosso exemplo será muito simples. Mas, quando se trata de aplicativos complexos, vale a pena manterem mente as distinções entre vários aspectos do design do app.Um aspecto do design do app é o design de software interno do programa, que rege coisas comocomo é fácil para um programador entender e alterar a aplicação. Outra dimensão diferenteé o design visual, que analisa se gostamos ou não dos looks do app. Esse é o lado mais artístico do desenvolvimento. E um terceiro tipo de design é o design de interação, que fala sobre como o usuárioexperimenta suas interações com a sua aplicação. Agora vamos seguir ao nosso exemplo simples.(Consulte o Tempo de Slide: 05:02)
Aqui temos um screenshot de uma maneira direta de mapear o nosso simples aplicativo de linha de comandopara um formato gráfico. Consideremos quais podem ser os recursos de tal app. Por exemplo, como
a CLI, podemos registrar um usuário. E parece claro que a forma como registramos deve ser digitar o nomedo usuário no texto superior irá atingir o botão de cadastro, e o usuário deverá ficar registrado.Obviamente, o nome do usuário vai para o campo de texto.similarmente, parece claro que devemos inserir despesas no campo de texto e, em seguida, atingir o botãode despesa. A área de texto inferior é onde obteremos respostas como o que acabou de acontecer e quandovocê pressiona o botão de relatório, é aí que veremos a saída. Quantos de vocês concordariamque parece natural que as funções do campo de texto e da área de texto maior sejam óbvias. Não é eleinteressante que muitos de nós, mesmo os usuários não técnicos poderão fazer esse caso sobre o queo app está fazendo, e, portanto, nos dar uma maneira bem fácil para que o app possa ser se tornar utilizável,sem nunca ter que ler um manual, ou instruir as pessoas em como fazer essas coisas.Essas idiomias de como nossa interface com o usuário deve ser organizada ou por agora tão natural para nós, que elasse sentem óbvias. E há ainda mais que consideraríamos óbvios. Por exemplo, podemosesperar que o app lembre quem é o usuário atual, e não nos exigir de novo e novamente especificaro usuário que é algo que temos a fazer em caso de aplicação da linha de comando, por exemplo.E até mesmo nossos amigos não técnicos, se mostrarmos a eles este app e eles tiverem que digitar seu nomenovamente e novamente, eles farão definitivamente uma sugestão que não o seu app, basta lembrarnosso nome. Outra maneira que poderíamos ter projetado o app é simplesmente copiar o que quer que seja o nosso app de linha de comandos, e exigir que o usuário digitando todo o comando no campo de texto. Masque não se sentiria tão diferente como um app que se lembra do contexto.Então, nesse sentido, essa aparência de contexto, que persiste em várias interações é o que éexclusivo sobre interfaces gráficas de usuários, como comparado a interfaces textuais de usuário oferecidas pelo comandoaplicativos de linha.
(Consulte O Tempo De Deslizamento: 07:42)
Agora vamos ver o que acontece quando começamos a usar o contexto em um ainda mais, digamos, inventivoou energeticamente. Como exemplo do que pode acontecer, no app simples que consideramos todos os 3botões do app foram possíveis de serem pressionados assim que o app se abrir. Mas isso não é realmente muitoútil porque até que o usuário foi registrado, ele não é como se você puder fazer qualquer coisa com os outros 2botões. Mas esse conhecimento nos diz que devemos realmente ter algum tipo de maneira de dizer ao usuárioque certos botões não são de uso certo agora. E a gente entende como fazer uma coisa dessas. Então, a ideia usual deaqui é de cinza certos botões, se atualmente eles não têm nenhum uso. Esse gradiamentofora e recursos como esse switch começam a tornar-se sensível ao contexto, ou uma das principais fontes decomplexidade de interfaces gráficas de usuário. Por exemplo, no app da linha de comando, todas as strings de linha de comandossão consideradas válidas quando enter.E vamos anunciar que há um erro se assim acontecer que o usuário insere algum tipo de string ilegal. Agora, a questão é o que devemos fazer no caso da interface gráfica do usuário. Uma resposta é comoa gente viu: ralar fora dos botões. Mas decisões como esta não são realmente claras. Alguns designers de interaçãopodem sentir que o estilo de mensagem de erro é de fato superior. Pois se você pressionarum botão que não deve ser usado, então o programador poderia oferecer uma mensagem de erro agradável queexplica claramente por que este botão não está disponível agora, e o que o usuário pode fazer em vez disso.
Dessa forma, o contexto muda muitas das possibilidades de interação. Como a história fica mais profunda, ea quantidade de recursos que o aplicativo oferece se torna mais complicado, a interação entreo que aconteceu até agora e, portanto, o que pode acontecer o futuro torna-se mais difícil de entender.Desafortunado ou felizmente como usuários, ao invés de como programadores, acontece que pequenas nuancescomo esta são realmente apreciadas pelos usuários.E, portanto, acontece que muitos designers de interação, e até mesmo nós experimentados como usuários deoutras aplicações, dirão que é uma boa ideia ter características tão sensíveis ao contexto. As condiçõesno núcleo do app no entanto, à medida que adicionamos essas coisas começam os balonetes, e requer um bom diálogoentre os designers de interação e programadores para descobrir o que é viável e o que ésustentável no longo prazo.(Consulte o Tempo de Slide: 10:38)
Reliance sobre o contexto para falar sobre o que um app deve e não deve fazer ou pode e não pode fazer,naturalmente leva à ideia de uma sessão. Uma sessão começa quando um app é lançado. Há uma sériede interações e, em seguida, o app é finalizado. Uma sessão mantém contexto na memóriaespecialmente para ferramentas de desktop. E é bastante natural ser capaz de saber facilmente o que está acontecendo emum app no qual tais informações podem ser mantidas diretamente na memória.
A espécie de contexto mais comum, por exemplo, é a identidade do usuário. Em nosso registro de app funciona uma espéciede like login, e podemos dizer ao usuário atual, após eles se registrarem, que o restante das operações iráacontecer no contexto de sua identidade. Como mostrado no screenshot, nosso aplicativo pode organizarfacilmente para lembrar a identidade registrada. É importante mostrar isso aos usuários porque entreoutras coisas pode ser possível que vários usuários possam utilizar esse app.E mesmo que isso não aconteça em contexto muito comum, também é importante sinalizar para os usuáriosque algum aspecto da interação anterior, e exatamente qual aspecto, será refletido no aplicativo. Por sermos tão familiarizadas com sessões, a ideia de uma sessão pode parecer sersimples. E é claro, como usuários é uma ideia simples. No entanto, para um implementador de aplicativos, as sessõesnão são tão fáceis de implementar.A razão é que a ideia de uma sessão, e a quantidade cada vez maior de contextos diferentes que poderiamexistir, comece a adicionar mais e mais dimensões aos detalhes internos de um programa. Por exemplo,suponhamos que além da identidade, adquirimos uma noção do projeto atual que um aplicativotem que lidar, uma vez que há um projeto atual agora para cada estrutura de dados única no programa,aqui para pensar para qual identidade e para qual projeto.Em breve os casos começam a se multiplicar e então alguns recursos são permitidos para alguma identidade, alguns sãopermitidos para alguns projetos, alguns são para algumas combinações, e alguns são despermitidos. E quandoesses tipos de opções se multiplicam, a complexidade se mantém em aumento. Por exemplo, pense na distinçãoentre o administrador de um servidor versus o usuário de um serviço. Essas 2 identidades,mesmo que elas sejam a mesma pessoa em momentos diferentes, podem ter consequências radicalmente diferentes.E assim, a lógica interna do aplicativo deve lidar com esses tipos de variações. Mas particular propriedadeque é comumente associada a sessões adiciam mais complexidade. E este éinfelizmente, a propriedade muito comum da identidade.
(Consulte O Tempo De Deslizamento: 13:41)
Aqui está um pequeno exemplo de como poderíamos usar a identidade. Suponhamos que existam 2 usuários Avinash eKalyan e então Kalyan gasta 40 rúpias e depois pede uma reportagem. Relatório pode usar as informaçõessobre o usuário atual para craft sua saída de uma forma legível. É implícito quem está usando o aplicativo, e isso é útil. Mas como veremos, no caso da web, isso pode tornar as coisasbem difíceis.A maioria de nós está tão acostumada a se registrar em nossas máquinas, e a gente toma para conceder que a nossa identidadeestará implícita em todas as nossas interações. Também estamos acostumados a pensar em fazer login, logando ode máquinas compartilhadas como a própria definição de sessões. Mas a identidade é difícil até mesmo para aplicativos de desktop. Como exemplo, uma vez por vez, os computadores pessoais foram pensados para serem verdadeiramentepessoais, o modo como os telefones são, e assim foram projetados com uma pessoa de qualquer maneira.Mas aconteceu que a família começou a compartilhá-los e as instituições começaram a oferecer PCs compartilhados. Eagora a ideia de um computador pessoal quebrou. A transição de um único usuário para o múltiplo usuárioexigiu mudanças profundas no sistema. Por exemplo, tivemos que adicionar a ideia de proprietário a cada sistema de arquivosúnico. E assim, algo que era usado apenas para armazenamento sem pensar muito sobre quem eleé para todos de repente teve que lidar com a dimensão da identidade.
Se a identidade é difícil para apps de desktop, é ainda mais difícil para aplicações web. Porque a identidade no casoda web causa problemas como a personalização dos usuários e agora é preciso lidar com não apenasa identidade como usada internamente ao app para distinguir entre as coisas, mas também lidar comvalidando IDs de usuários, determinando possíveis fakes e coisas do tipo. No caso dos aplicativos locais CLI eGUI desde que nosso acesso é protegido fazendo logon em uma máquina física.A distinção que estou fazendo pode não parecer importante, mas uma vez que você se torna um designer de aplicativos, verifica-se que muitos sites estão sob constante ataque de várias pessoas que iriamgostar de entrar e usar suas instalações para todo tipo de coisas estranhas, incluindo coisas como mineraçãobit moedas em seus servidores. No caso da web, a personificação torna-se uma questão muito séria. Umadécada ou tão atrás, era possível personiver um outro usuário meramente compartilhando corretamente URLs de.
Hoje Em Dia, a maioria dos sites tem defesas contra tais coisas, mas mesmo que você tenha cuidado você podeabrir seu site para ataques inadvertidamente, e vamos passar algum tempo tentando entender asramificações de segurança quando elas surgirem. Por enquanto, vamos seguir em frente aos outros aspectos de aplicativos interativosque precisamos entender. A diferença chave além da sessão e da identidade é a noçãode um loop de eventos, que altera a natureza do fluxo de controle que está disponível para um aplicativo.
(Consulte O Tempo De Deslizamento: 17:02)
Um aplicativo de linha de comando tem um fluxo de controle muito simples, aceite entrada e produza o resultado.Este é muito parecido com como funciona o trabalho em uma linguagem de programação. Em contraste, o fluxo de controle deum aplicativo GUI interativo é mais confuso. Não há nada como ele em programação usualidiomas em que podemos contar para alguma experiência. O comportamento padrão da GUI quando ele começou ébem diferente do comportamento padrão de um app de linha de comando.Considerando que um app de linha de comando está imediatamente fazendo exatamente o que você disse a ele e nada mais,o comportamento padrão da GUI quando ele começou é mostrar a interface e então não fazer nada, excetoesperar a nossa entrada. Quando uma entrada é recebida, ele executa o comando e volta a fazernada. Em geral, surpreendentemente em nossas máquinas, a CPU o disco etc. ficam ociosa na maioria das vezes,a menos que somos programas como clientes que verificam se você recebeu uma mensagem por e-mail ouWhatsApp ou algo assim, diferente daquela máquina não tem nada a fazer, a não ser fazero que quer que seja que o usuário deseje.
Então tal espera de espera é surpreendentemente o suficiente um loop infinito, este é um dos raros casos em que um loop infinitoé exatamente o que você deseja, normalmente e um loop infinito em programação normal, talcomo um erro, mas neste caso, é exatamente o que você quer de fato, o programa deve loop para sempre,
basta aguardar a entrada do usuário, e toda vez que ele receber entrada, faça algo útil, tais entradas que sãorecebidas por este loop de espera infinito são conhecidas como eventos. E assim, o loop é chamado de evento. Emo menor loop do evento ou os eventos que loop pode estar interessado são coisas como movimentos do mousee keystrokes e GUI ele irá se reunir com os sistemas operacionais determina seo mouse que é clicado em uma determinada parte da tela deve ser interpretado como tendo acionadoum botão.
Então, por exemplo, ele converte efetivamente o evento pressionado pelo mouse de nível inferior em um pressionamento de botão de nível superior, e os programas GUI e web são escritos em termos de tais eventos de alto nível. Então, nãosó é o fluxo de controle incomum, precisamos de um novo tipo de terminologia para lidar com isso, que é onoções de eventos e loops de eventos e resposta a eventos. Um loop de eventos em um programa GUI érelativamente simples de entender, e assim nós vamos passar algum tempo falando sobre isso. Mas loops de eventosem programas web podem existir no servidor, ou no cliente o navegador, ou ambos. Além disso, o eventoloops nos sistemas web pode servir simultaneamente a vários usuários, ao contrário do habitual evento GUIloops que atendem apenas um usuário.Nos slides seguintes, veremos como os eventos de sessões, e o código GUI se parece em nosso app. Nósconstruiremos então neste conhecimento para estudar construções semelhantes em aplicações web.
(Consulte O Tempo De Deslizamento: 20:24)
Vamos começar com a visão geral da estrutura básica do aplicativo de interface do usuário, é possível acriar um app simples de UI onde o push de um botão é diretamente mapeado para uma chamada de função. E esta chamada de funçãocomo qualquer outra chamada de função em um programa normal iria ao redor da atualização de várias estruturas de dados. Várias ferramentas simples de construção de UI fazem essa abordagem porque essa abordagem émais fácil de ser iniciada com.No entanto, a experiência mostrou que, embora seja fácil começar com um programa, em que a UIcontrola como botões e campos de texto diretamente acionar funções, tais apps se tornam ingerenciáveis à medida que surgem novos requisitosnovos requisitos. O que acontece é que o programa para cada botão é pensar em termos deesse botão, e não em termos do grande quadro. Se um programador diferente depois quiser entendero que está acontecendo, alguns recursos podem surgir acidentalmente, como resultado de interações estranhas entreelementos diferentes de entrada e saída de um programa.E você realmente precisa de mais organização para tentar fazer sentido do que realmente está acontecendo no aplicativo de interface do usuário. Isso acontece muito rapidamente, até mesmo para simples apps de selos. Por isso, éque vale a pena fazer uma abordagem mais estruturada para a construção de um aplicativo de interface com o usuário. Esta solução, ou uma solução para este problema de estruturação, é algo que a maioria dos programas de interface com o usuário
terá que lidar em um ponto ou em outro. E a solução é simples o suficiente de que é melhor parausá-la logo desde o início. Como veremos, ele pode ser usado de uma maneira muito leve e nãotem que ser tão complicado em tudo.O que percebemos historicamente, foi que esse tipo de separação precisa dos 2 elementos seguintes. Nósestruturamos a aplicação em partes majoritariamente independentes, geralmente, pelo menos 2 partes e muitas vezes 3 ouainda mais partes.Uma maneira de separar as complexidades do que um aplicativo foi fazer versus como apresentar queinformações é considerar que há 3 aspectos. Há estruturas que são necessárias para o cálculo de. Esta parte que é responsável pela computação é chamada de modelo. Outra parte chamadauma view, gerencia todo o código direto para criar a interface do usuário e assim torna-se responsável pordisplay.E tem que haver uma terceira parte que conecta o modelo e a visualização, para que saiamos qual elementoda visualização afeta quais elementos do modelo e nós podemos conectá-los juntos. Este componenteé uma espécie de como um método de fiação que conecta um botão a uma lâmpada. Se houverlâmpadas múltiplas e múltiplos botões do que é a fiação que decide qual botão afeta quallâmpada nessa metáfora.Às vezes essa fiação é programada explicitamente e em outros estilos chamada programação reativae muitos outros tipos de coisas. A fiação é inferida a partir da estrutura do programa. Para os nossos propósitos, permanecemos com um simples estilo de fiação explícito de programação. Então, uma vez que essas 3partes estão no lugar, o que está acontecendo? A ideia é que o usuário de um aplicativo que esteja, em sua maioria,interessado no lado de exibição, e não na estruturação interna, veja a visualização e interaja comit. Mas os dados que a visualização mostra vem do modelo subjacente. Efetivamente, a visualização ofereceuma maneira de um usuário manipular o modelo subjacente. Então, isso é sobre a estrutura estática.E quanto ao caso dinâmico, e quanto ao comportamento? Por esse comportamento, também nos organizamos em uma sequênciade 3-phases:1. Na primeira fase um usuário trabalha com a visualização e a visualização aceita entrada de usuário,2. ele então determina qual parte do modelo deve ser afetada pela entrada atual,
3. e então a fiação transmite o significado do gesto do usuário, eventualmente para o usuário através da visualização.
Uma vez que o modelo sabe o que o usuário deseja, o cálculo ocorre em diferentes partes dos dados modernos deatualizados, então, alterações na visualização computadas com base no que ocorrem alterações no modelo. Essa maneira de pensar de 3 fases de 3 fases nos ajuda a organizar claramente o programa. Para entender isso, iniciaremosde desconto com uma versão ainda mais simples do aplicativo que já temos, e veja como funciona o modeloreestruturando.(Consulte o Tempo do slide: 25:35)
Este slide mostra um simples aplicativo de usuário e até mais simples, o que simplesmente registra usuários enão faz mais nada. Aqui quando o botão de registro é clicado, o usuário atual é atualizado e o resultadoé show. Nosso modelo aqui é apenas uma variável simples que conhece o usuário atual. Então:• Na primeira imagem que você vê, o aplicativo é como você o vê ao lançá-lo.• E o segundo é depois de registrar um único usuário, você pode ver o usuário atual refletido emo rótulo que mostramos.
Aqui como eu disse, o modelo é na verdade uma coisa muito simples. É meramente o que quer que seja que detém o nomedo usuário atual. A visualização consiste no botão, no campo de texto e no rótulo. E agora 2conexões existem entre a visualização: o campo de texto e o botão e outra parte da visualização,que é o rótulo.Quais tipos de conexões são estas? o campo de texto e o botão atuem como dispositivos de entrada que mudaramo valor realizado atualmente do modelo. E o rótulo funciona como um dispositivo que mostra qual é o valor atual do modelo.
Então, um par desses 2 elementos, o TextField e o botão estão atuando como sistemas de entrada e o rótuloestá atuando como sistema de saída. O fluxo de 3 fases neste caso é particularmente simples. Na fase de entrada, o usuário preenche o textfield e pressiona o botão. Na fase de computação, o modelo armazenao valor atual do textfield, pois esse é todo o cálculo necessário neste caso.E então não há nada muito acontecendo diferente disso, a saída tem que ser mostrada sempre que o modelomuda. Então, este é o exemplo central. Mesmo em algo tão simples quanto este, essa discussãoda distinção entre a visualização e o modelo e o sistema de saída de entrada de 3 fases, faz com que eleajude um pouco a entender como um pode sair por aí estruturando até mesmo o simples programa de UIcomo este. Ok, agora para algo mais complicado, onde vamos dar uma olhada em como essas ideiasfuncionam quando olhamos para maiores detalhes.
(Consulte O Tempo De Deslizamento: 28:11)
Então, vamos dar uma olhada na estrutura conceitual do que está acontecendo no caso de uma aplicação de modelo de visualização. Neste slide, estudaremos como o código é realmente organizado. Por isso, se você dar uma olhada,você verá que no topo há o triângulo representando no usuário. Há um retângulo arredondadoque representa a visualização e ao redor dessa visão há uma construção em loop chamada de loop de eventoscomo falamos, a visualização por sua vez interage com o modelo via elementos chamados handlers, e o modelointerage com o armazenamento de dados via storage IO.O usuário interage com o loop do evento via eventos, e o loop de eventos organiza a interação com o usuárioe fornece a eles um após outro à vista. Por isso, quando construímos nossa interface real de usuário, nóstemos elementos no programa que correspondem diretamente a esses blocos conceituais. Esses elementosdo programa foram listados abaixo. E já que estamos construindo isso em Java, a maioria dos elementosreferem-se às classes Java que são usadas para construir esses sistemas.Então, correspondente à visualização, temos classes Java UI, tal JButtton, JTextArea e JTextFieldcorrespondentes aos manipuladores, as classes de manipuladores Java como ActionListener são usadas para conectara visualização ao modelo. O modelo para os tipos de sistemas que estamos olhando são simplesmente dadosestruturas como HashSet e HashMap, e claro que quaisquer outras classes que você possa desejardesign e uso para computação.
A parte de IO storage é manipulada pelo arquivo IO, JDBC e várias outras classes de IO, algumas das quais vocêjá encontrou na escrita a aplicação da linha de comandos. E a data store para o nosso caso de usode qualquer maneira, é apenas um simples banco de dados em arquivo. De alguma forma, então todo o código real que escrevemos tem que se encaixarnesse tipo de modelo para ter a estrutura que gostaríamos, para que possamos entender o queas dependências são e qual – como o aplicativo cresce, como gerenciar a distinção entreo que é necessário para visualização e o que é necessário para modelagem.Vamos ver como a 3-fase do loop de saída de cálculo de entrada se encaixa nesse modelo. Então, neste caso, o que temos é que há o usuário que digessa alguma coisa, e quando o usuário fazalgo, ele chuta para fora do loop do evento, que então dirige o ActionListener. Depois esta é a parteonde aceitámos a entrada.Neste ponto os manipuladores são acionados, e o modelo é apanhado. Esta é a parte de computação. Euma vez que o cálculo do novo estado do modelo esteja completo, por sua vez, o modelo diz à visualizaçãoque existem alguns aspectos da visão de que os objetos de visualização devem ser atualizados. E esta é a partea onde o fluxo de controle estabelece em cima das estruturas de dados que temos visto. No restante deisso, não falaríamos muito sobre a data store, ela só estará lá em segundo plano.Porque não há nada de novo que esteja acontecendo aqui comparado com o aplicativo da linha de comando.Next, vamos dar uma olhada no código que corresponde às estruturas conceituais que temosvisto.
(Consulte O Tempo De Deslizamento: 31:56)
Então, vejamos. Ok, aqui vamos nós ok. Então, deslize o número 12. Neste slide, estamos olhando para partes deo código que foram escritos para criar o aplicativo que já vimos. Nessa coisa, como vocêolha para a direita, eu estou usando o Eclipse, mas não há nenhum motivo particular por que eu quero dizer que eu não estou fazendonenhuma recomendação sobre qual IDE você deve usar, use o que você estiver confortável.Aqui, vemos aquelas partes do aplicativo que correspondem às coisas conceituais que temosvisto.
E como você pode ver os elementos que são usados para criar o modelo e a visualização são muito, muitosimples. Não temos nem muito por meio de objetos, é claro, coisas como Sets, etc., ehá objetos Java nas bibliotecas. Mas este design não é particularmente orientado a objetos. A razãoera que eu não queria nenhuma estrutura extra. Eu só queria mostrar que mesmo estruturas simples podemmapear muito claramente na estrutura de visualização do modelo que já vimos.Para facilidade de referência, replicei o diagrama de visualização do modelo na parte inferior esquerda deste slide.Então, vamos fazer um rápido caminhado do código que vemos aqui. Então, a classe é chamada deModelViewExampleParts, e ela começa mostrando-lhe o modelo. O modelo neste casoconsiste em realmente 2 variáveis, uma delas é um conjunto, e a outra, que é uma string. myUserssão todos os usuários que se cadastraram, e um string currentUser é o usuário que realmente iremosmostrar no rótulo.
Abaixo que é a visualização geral contém, ele é um quadro, que é um dos estilos padrão Java deorganizando GUI em código Java. E o elemento da visão de que estamos interessados é claro,apenas um JLabel. Tudo isso é dirigido o tipo usual de programa principal. E então você tem os seguintes métodos3, que constituem os elementos que levam ao fluxo de controle de 3 fases que temosdiscutido.