Para sair um pouco da teoria, o próximo passo no bootcamp é um exercício (que eles chamam de desafio de projeto). Achei interessante colocar uma parte prática para sedimentar o conteúdo abordado até aqui.
O que foi pedido foi para criar um projeto que simule uma única conta em um banco, contendo número da agência, número da conta, nome do cliente e saldo. Esses dados devem vir do terminal e ao final, deve ser exibida uma mensagem informando que a conta foi criada com sucesso e mostrando quais foram os dados inseridos. A descrição original pode ser vista aqui.
Bom, parece bem simples. Mas uma coisa que eu gosto muito de fazer em qualquer tarefa que eu recebo é quebrar em passos bem curtinhos, pra que eu tenha um caminho claro de onde seguir. Eu faço isso também porque enquanto estou desenhando o fluxo na minha cabeça, consigo entender se ele faz sentido com o que foi pedido e posso rapidamente mudar o curso de ação se achar que não está batendo.
Sendo assim, os passos a seguir são os seguintes:
Não parece algo exatamente complexo. Começando pelo passo 1, temos o seguinte:
TerminalAccount.java
public class TerminalAccount { // eu sei, sou muito criativo private int branch; private String account; private String clientName; private double balance; public void createAccount(){ // aqui a mágica acontece } }
Apesar de modificadores de acesso não terem sido abordados com muita profundidade até agora no curso eu optei por deixar todos os campos privados, imaginando que em um sistema bancário, os dados de agência, conta, titular e saldo devem ser bem protegidos e só a própria classe deve ter acesso a eles.
Além disso, o método createAccount não deve retornar nada, apenas exibir uma mensagem no console, por isso seu retorno é void.
É nesse método que começa algumas das coisas que me irritam no Java. Em vez de ter um método genérico que captura qualquer tipo de informação que o usuário inserir, a classe Scanner, que é usada para isso, tem métodos específicos para cada tipo primitivo. Ou seja, tem um Scanner.nextLine() para Strings, Scanner.nextInt() para números, Scanner.nextBoolean para booleanos...
Em comparação, no C# temos um método de entrada padrão que sempre retorna uma String, que ter seu tipo alterado em seguida:
String input = Console.ReadLine(); int.TryParse(input, out number) Console.WriteLine(number) //completamente válido
Tem que escrever um pouco mais? Tem. Mas pelo menos eu não preciso lembrar da sintaxe de todos os métodos, basta apenas um e converter para o tipo que eu quero em seguida. Muito mais intuitivo.
Mas sigamos, que ainda tem muito chão pela frente para resolver esse problema. O próximo passo, então, é pedir para o usuário inserir os dados do cliente para o registro.
TerminalAccount.java
public class TerminalAccount { private int branch; private String account; private String clientName; private double balance; public void createAccount() { Scanner sc = new Scanner(System.in); System.out.print("Por favor, insira o número da agência: "); this.branch = sc.nextInt(); System.out.print("Por favor, insira o número da conta: "); this.account = sc.nextLine(); System.out.print("Por favor, insira o nome do cliente: "); this.clientName = sc.nextLine(); System.out.print("Por favor, insira o saldo inicial: "); this.balance = sc.nextDouble(); System.out.println("Olá " this.clientName ", obrigado por criar uma conta em nosso banco. sua agência é " this.branch ", conta " this.account " e seu saldo " this.balance " já está disponível para saque."); } }
Bom, aparentemente está tudo certo. Vamos instanciar essa classe no nosso método main e ver o que dá.
Main.java
public class Main { public static void main(String[] args) { TerminalAccount account = new TerminalAccount(); account.createAccount(); } }
Oxe? Porque o input do número da conta foi ignorado e o algoritmo já pediu o nome do cliente?
Lendo a documentação da classe Scanner, é explicado que ela quebra o input em tokens usando algum tipo de caractere como delimitador, para saber onde parar. No caso dos métodos .next() e .hasNext() (e suas variantes, como o .nextInt() e o .hasNextInt()), o delimitador é um whitespace global (\s ) como espaços, tabulações e quebras de linha.
O que o método faz é pegar o token precedido pelo delimitador, converter para o tipo especificado e retornar esse valor. O resto continua no buffer do input.
Beleza, até aí ok. O problema é que o método .nextLine(), usado para capturar Strings consome o caractere de quebra de linha (\n), em vez de descartar. Aí, quando usado na sequência de outro que faz o descarte, ele lê o que ficou pra trás e imediatamente encerra sua atuação, passando para a próxima linha do código.
Parece confuso, e é mesmo. Fiz um diagrama para ajudar a compreender a loucura que é esse fluxo:
Tá, e como consertamos essa lambança? Simples: adicionando um novo Scanner.nextLine() logo depois do .nextInt() para "limpar" o que sobrou. É bonito? Não, mas resolve.
Dá pra mudar o delimitador para aceitar a quebra de linha (\n ) em vez de um whitespace comum (\s ), mas isso poderia quebrar a forma com que as informações são quebradas em tokens, então é melhor deixar pra lá.
TerminalAccount.java
public class TerminalAccount { private int branch; private String account; private String clientName; private double balance; public void createAccount() { Scanner sc = new Scanner(System.in); System.out.print("Por favor, insira o número da agência: "); this.branch = sc.nextInt(); sc.nextLine(); //... } }
Mais feio que bater na mãe.
Beleza, funcionou. Poderíamos dizer que o exercício está completo, mas vamos por um segundo imaginar que o usuário, sem querer, digitou uma letra na hora de colocar o número da agência:
Eita lasqueira.
Isso acontece porque, como já sabemos, a tipagem do Java é estática e o Scanner está esperando um número mas quando colocamos uma letra junto com um número, essa cadeia se torna uma String. O input que estava esperando um int recebeu uma String e ficou confuso tal qual uma criança que recebe meias de presente de natal.
Para remediar essa situação, podemos criar um loop simples, que informe para o usuário que a informação que ele inseriu está incorreta de acordo com as especificações do sistema e pedir que ele insira os dados novamente (de maneira correta, dessa vez). Como não sabemos quantas tentativas o usuário vai levar para inserir os dados corretamente, um while parece adequado.
public class TerminalAccount { private int branch; private String account; private String clientName; private double balance; public void createAccount() { Scanner sc = new Scanner(System.in); boolean isBranchNumberInputCorrect = false; do { try { System.out.print("Por favor, insira o número da agência: "); this.branch = sc.nextInt(); sc.nextLine(); isBranchNumberInputCorrect = true; } catch (InputMismatchException e) { System.out.println("Por favor, insira apenas números inteiros para o número da agência."); sc.nextLine(); } } while (!isBranchNumberInputCorrect); //... } }
Aqui criamos uma variável de controle chamada IsBranchNumberInputCorrect (porque, novamente, sou muito criativo quando se trata de nomes), inicializada em false. Em seguida, começamos o bloco do, uma vez que queremos que o código faça uma ação antes de verificar se o dado inserido é valido ou não e jogamos nosso input lá pra dentro.
Caso dê tudo certo, o dado inserido será armazenado no campo branch, qualquer caractere sobrando será consumido pelo Scanner.nextLine() e a nossa variável de controle será atualizada para true. Aí a condição do while vai checar se isBranchNumberInputCorrect é false. Se for, reinicia o loop no caso de sucesso, o laço é encerrado.
Agora, caso o usuário insira algo não esperado (como uma String), o método Scanner.nextInt() vai emitir um evento de erro InputMismatchException, que será capturado pelo nosso bloco catch. Uma vez lá dentro, o código vai exibir uma mensagem de erro alertando que o tipo de dado está errado e consumido qualquer caractere que tenha ficado pra trás.
A gente pode fazer a mesma coisa com o input de saldo, para garantir que o valor inserido sempre será numérico e não permitir que a aplicação quebre caso seja inserido algo como 12,56f:
public class TerminalAccount { private int branch; private String account; private String clientName; private double balance; public void createAccount() { Scanner sc = new Scanner(System.in); //... boolean isBalanceInputCorrect = false; do { try { System.out.print("Por favor, insira o saldo inicial: "); this.balance = sc.nextDouble(); sc.nextLine(); isBalanceInputCorrect = true; } catch (InputMismatchException e) { System.out.println("Por favor, insira apenas valores decimais."); sc.nextLine(); } } while (!isBalanceInputCorrect); //... } }
Poderíamos parar por aqui e dar esse exercício como encerrado, mas ainda tem um bug que requer um pouco de atenção. O que aconteceria se, em vez de delimitarmos nosso saldo com uma vírgula (,) usássemos um ponto (por exemplo, 10.56)?
Isso acontece devido ao locale, a adaptação do input à cultura do local. Aqui no Brasil, o decimal é delimitado pela vírgula, então o método não entende que essa separação com ponto é válida.
A documentação da classe Scanner nos mostra que é possível alterar a cultura para uma que atenda ou um ou outro padrão, mas não os dois ao mesmo tempo. Também é possível alterar especificamente o delimitador, para um símbolo ou para outro, mas não os dois ao mesmo tempo.
Um dos métodos para solucionar esse problema não é muito elegante, mas resolve: em vez de capturar o dado diretamente como double, vamos usar o método Scanner.nextLine() para pegar o input como uma String, trocar os pontos por vírgula e tentar trocar o tipo para double.
public class TerminalAccount { private int branch; private String account; private String clientName; private double balance; public void createAccount() { Scanner sc = new Scanner(System.in); //... boolean isBalanceInputCorrect = false; do { try { System.out.print("Por favor, insira o saldo inicial: "); String balanceString = sc.nextLine().replace(",", "."); this.balance = Double.parseDouble(balanceString); isBalanceInputCorrect = true; } catch (NumberFormatException e) { System.out.println("Por favor, insira apenas valores decimais."); } } while (!isBalanceInputCorrect); //... } }
Além da alteração do método de captura do dado, tivemos mais algumas modificações: retiramos as chamadas para o método Scanner.nextLine() que serviam apenas para consumir os caracteres remanescentes, porque nosso input já faz isso pra gente. Além disso, o tipo do erro mudou: agora não se trata de um erro de incompatibilidade de tipo (InputMismatchException), mas sim um de erro no formato do número (NumberFormatException).
Com essas alterações feitas, bora ver se tudo deu certo:
Deu tudo certo! Com isso, conseguimos dizer que o exercício está concluído (finalmente)!
O repositório desse exercício está disponível aqui caso tenha interesse de ver.
E é isso. Até o próximo módulo!
Disclaimer: All resources provided are partly from the Internet. If there is any infringement of your copyright or other rights and interests, please explain the detailed reasons and provide proof of copyright or rights and interests and then send it to the email: [email protected] We will handle it for you as soon as possible.
Copyright© 2022 湘ICP备2022001581号-3