DEV Community: Lucas Nabesima

Desafio de Projeto 02 - Criando uma aplicação contadora

Lucas Nabesima — Mon, 02 Sep 2024 23:44:12 +0000

Chegamos ao segundo desafio de projeto desse módulo inicial, a última tarefa antes de passarmos para o módulo de Programação Orientada a Objetos.
Confesso que achei esse desafio meio besta e podia ser um desafio de código sem problemas, mas tudo bem.

Desafio Proposto:

O sistema deverá receber dois parâmetros via terminal que representarão dois números inteiros, com estes dois números você deverá obter a quantidade de interações (for) e realizar a impressão no console (System.out.print) dos números incrementados, exemplo:

Se você passar os números 12 e 30, logo teremos uma interação (for) com 18 ocorrências para imprimir os números, exemplo: "Imprimindo o número 1", "Imprimindo o número 2" e assim por diante.

Se o primeiro parâmetro for MAIOR que o segundo parâmetro, você deverá lançar a exceção customizada chamada de ParametrosInvalidosException com a segunda mensagem: "O segundo parâmetro deve ser maior que o primeiro"

Sugestão de passos:

Crie o projeto DesafioControleFluxo

Dentro do projeto, crie a classe Contador.java para realizar toda a codificação do nosso programa.

Dentro do projeto, crie a classe ParametrosInvalidosException que representará a exceção de negócio no sistema.

Não é, como podem ver, a coisa mais complexa do mundo mas abre algumas possibilidades interessantes.
Podemos começar pelo final e criando a exceção customizada (quero dizer, depois de criar o projeto né):

//InvalidParametersException.java
public class InvalidParametersException extends Exception {  
    public InvalidParametersException() {  
        super();  
    }
}

Esse é o jeito mais simples de definir uma exceção customizada. Criamos uma classe (e, seguindo um padrão de nomenclatura, colocamos o sufixo Exception) que estende de Exception quando ela for uma exceção verificada (checked exception) ou de RuntimeException, se ela não for verificada (unchecked exception). Aí definimos o construtor da classe de acordo com o comportamento que queremos que nossa exceção tenha. Nesse caso ela não vai fazer muita coisa, então vamos dar uma melhorada nela.

Ai Lucas mas o que é um construtor de classe?? Você nunca disse nada sobre isso!!1!

Realmente, não foi mencionado ainda o que é um construtor. O próximo módulo, de Orientação a Objetos, deve corrigir essa lacuna de conhecimento. Segura a emoção, bicho.

No caso da nossa exceção, eu decidi que ela deve ser uma exceção verificada (ou seja, ela deve ser tratada quando o método que a lança é utilizado) para garantir que a regra de negócio Se o primeiro parâmetro for MAIOR que o segundo parâmetro, você deverá lançar a exceção customizada chamada de ParametrosInvalidosException com a segunda mensagem: "O segundo parâmetro deve ser maior que o primeiro" seja respeitada e haja um tratamento de erro a fim de não quebrar a aplicação.

Para termos mais flexibilidade na hora do tratamento, podemos definir construtores adicionais na Exception, cada um fazendo uma coisa diferente:

// InvalidParametersException.java
public class InvalidParametersException extends Exception {  
    private static final String DEFAULT_MESSAGE = "Um ou mais argumentos são inválidos.";  

    public InvalidParametersException() {  
        super(DEFAULT_MESSAGE);  
    }  
    public InvalidParametersException(String message) {  
        super(message);  
    }  
    public InvalidParametersException(String message, Throwable cause) {  
        super(message, cause);  
    }  
    public InvalidParametersException(Throwable cause) {  
        super(DEFAULT_MESSAGE, cause);  
    }}

Vamos olhar com calma esse troço.
Declaramos a classe InvalidParametersException estendendo a classe Exception. Isso quer dizer, como já mencionei acima, que qualquer classe que chame o método que lance essa exceção precisa implementar um tratamento para ela.

Em seguida, declaramos a constante DEFAULT_MESSAGE, atribuindo "Um ou mais argumentos são inválidos." a ela. Como sabemos que é uma constante? Por causa da palavra reservada final e do uso do SCREAMING_SNAKE_CASE, um padrão comum para designar constantes. Esse valor vai ser exibido caso a exceção seja lançada sem argumentos, como definido no primeiro construtor: Ele chama o construtor da superclasse (no caso, a Exception) passando DEFAULT_MESSAGE. Então no caso de termos um parâmetro inválido, se uma mensagem customizada não for definida, o erro mostrado será "Um ou mais argumentos são inválidos.".

O segundo construtor permite que a exceção seja lançada com uma mensagem personalizada. Ou seja, podemos substituir as mensagens de erro padrão com alguma mensagem customizada. Por exemplo, em vez de mostrar algo como Exception in thread "main" java.lang.NullPointerException, podemos exibir Você me instruiu a acessar algo que estava nulo. Tá tudo bem, amigo?.

Os dois últimos tem um argumento diferenciado, o cause. Ele é um Throwable (um lançável) e é utilizado para relançar uma exceção. Por exemplo, vamos supor que em alguma aplicação sua exista um ponto que precise fazer uma divisão entre dois dados informados pelo usuário e o denominador (lembra dele das aulas de fração?) acaba sendo 0.

Lembra quando esse formato de meme era popular? Bons tempos aqueles...

Isso vai lançar uma ArithmeticException, mas o que você quer na verdade é usar sua exceção customizada novinha, que deu tanto duro para criar. Aí você pode fazer algo assim:

try {
    Scanner sc = new Scanner(System.in);
    int num1 = sc.nextInt(); //10
    int num2 = sc.nextInt(); //0
    int result = num1 / num2; //OH SHI-
} catch (ArithmeticException ex) {
    throw new InvalidParametersException("Não pode dividir por 0, bicho", ex);
}

Ou seja, o bloco try-catch captura a ArithmeticException, pega o motivo de ter sido lançada e passa para a exceção customizada, que vai disponibilizar uma mensagem mais amigável para o usuário E mostrar a causa dessa pataquada toda. A pilha de execução (stack trace) para essa situação poderia ser mais ou menos assim:

Exception in thread "main" InvalidParametersException: Não pode dividir por 0, bicho
    at Main.main(Main.java:10)  
    Caused by: java.lang.ArithmeticException: / by zero
        at Main.main(Main.java:9)

Temos nossa mensagem amigável na primeira linha da pilha mas também temos o ponto exato onde as coisas deram errado, para termos uma depuração mais rápida.

Nossa, quanta coisa. E ainda nem entramos no método propriamente dito.
Aqui eu tenho que fazer uma mea-culpa: Eu reclamei a um tempo atrás de como na documentação da classe Scanner mostra que existe um método específico para capturar cada tipo primitivo e fui induzido a achar que esse era o único jeito de fazer isso. Mas conversando no Discord da Orange Juice, meu chegado Claudio me disse que tem um jeito muito mais simples:

Ou seja, eu fiquei reclamando reclamando reclamando mas aparentemente dá pra fazer exatamente como no C#, como eu falei que era melhor. Claro, não dá pra aceitar tudo cegamente, então eu fui fazer um teste:

public static void main(String[] args) {  
    Scanner scanner = new Scanner(System.in);  
    System.out.print("Insira o primeiro número: ");  
    int num1 = Integer.parseInt(scanner.nextLine());  
    System.out.print("Insira o segundo número: ");  
    int num2 = Integer.parseInt(scanner.nextLine()); 

    System.out.println("O primeiro número foi: " + num1 + " e o segundo foi: " + num2);  
}

Não é que deu certo, gente?
Eu to me sentindo bem mal agora, não fiz a coisa mais simples antes de começar a reclamar... Que burro, dá zero pra mim.

Muito bem. Me desculpe, menino Java.
Isto posto, podemos começar a desenvolver nosso método de contagem. A classe Counter vai ter dois métodos: o counter, que vai conter a lógica da contagem e o main, que vai chamar o contador e tratar as exceções que surgirem. Vamos começar com o counter:

public class Counter {  
    public static void main(String[] args) {}  //por enquanto esse método segue vazio

    public static void count(int num1, int num2) throws InvalidParametersException {  
        if (num1 < 0 || num2 < 0) throw new InvalidParametersException();  
        if (num1 > num2) throw new InvalidParametersException("O primeiro argumento deve ser maior que o segundo");  

        int counter = num2 - num1;  
        System.out.printf("Vou imprimir todos os números de 1 até %d.%n", counter);  

        for (int i = 1; i <= counter; i++) {  
            System.out.printf("Imprimindo o número %d%n", i);  
        }    
    }
}

Declaramos o método counter, que é público e não tem retorno (podemos ter certeza por conta do void ali). Além disso, esse método é estático, então não precisamos instanciar a classe para podermos usá-lo. Ele recebe dois argumentos do tipo int, num1 e num2 -- criatividade é a alma do negócio. Por fim, podemos ver que esse método lança a nossa maravilhosa exceção InvalidParametersException, o que vai obrigar o método main a realizar algum tipo de tratamento em cima dela.

Para garantir que as regras de negócio vão ser respeitadas, o método faz duas verificações:

Checa se qualquer um dos números é negativo e, em caso positivo lança uma exceção informando ao usuário que um ou mais argumentos são inválidos;
- Essa checagem, apesar de não ter sido pedida, é para garantir que não haveria resultados esquisitos na subtração feita. Eu não queria, por exemplo, ter que lidar com resultados negativos.
Checa se o primeiro número é maior do que o segundo. Se sim, lança uma exceção orientando o usuário que o segundo número (o numerador da divisão) deve ser maior.

Depois disso, é realizada a subtração que vai montar o loop. Feita essa conta, é impressa no console uma mensagem informando que a aplicação irá mostrar todos os números de 1 até o resultado.

E aqui vem mais uma particularidade do Java: a falta de interpolação de strings. Eu me acostumei a escrever

const variable = variable;
let sentence = `I'm a sentence that uses a ${variable}!`;

string name = "John Doe";
string sentence = $"My name is {name}.";

que é até esquisito imaginar uma linguagem moderna que não utiliza isso.

Para ficar melhor (e evitar usar a concatenação com aquela sintaxe horrorosa), descobri que poderia formatar a mensagem com o método String.format(), da mesma forma que a formatação de string do C. E assim como no C, existe a possibilidade de já formatar a string usando o método print. Em vez de usar o .println() para imprimir uma string e já pular uma linha (o ln significa que caractere para newline será adicionado no final), o método .printf() formata a mensagem de acordo com o placeholder informado.
Existem muitos placeholders que podem ser utilizados, mas os mais comuns são %s para string, %d para int, %f para números de ponto flutuante (como double e float) e %f para data/hora. Porém esse método não cria uma quebra de linha então caso seja necessário, é preciso adicionar o caractere %n para uma nova linha.

Aí, por último, fazemos nosso laço for, sem grandes mistérios. Inicializamos o contador do loop em 1 e o instruímos a repetir a tarefa até o chegar no resultado final, incrementando o valor do contador de um em um. A cada volta imprimimos o valor do contador atual, cumprindo, desse modo, o requisito do desafio.

Beleza, criamos o método que vai realizar a ação que precisamos. Agora, o que falta é chamar a função e executá-la em algum lugar, né? Vamos fazer isso no método main da nossa classe Counter:

public class Counter {  
    public static void main(String[] args) {  
        try {  
            Scanner scanner = new Scanner(System.in);  
            System.out.println("Insira dois números e a aplicação imprimirá a diferença entre eles, linha a linha.");  
            System.out.print("Insira o primeiro número: ");  
            int num1 = Integer.parseInt(scanner.nextLine());  
            System.out.print("Insira o segundo número: ");  
            int num2 = Integer.parseInt(scanner.nextLine());  

            count(num1, num2);  

        } catch (InvalidParametersException e) {  
            System.out.println(e.getMessage());  
        }    
    }  
    public static void count(int num1, int num2) throws InvalidParametersException { /* lógica descrita acima */ }

Aqui não tem nada muito excepcional: Instanciamos um novo scanner e, seguindo a dica valiosa do Cláudio, pedimos ao usuário que insira dois números. Esses números são capturados como string e imediatamente convertidos em int. Com esses dados, chamamos a função count passando os dois números como parâmetros e, caso alguma exceção seja lançada, uma mensagem de erro será exibida no console.

Show, mas será que funciona?

Aparentemente sim. ✌️
Mas o que acontece se, por exemplo, algum usuário ~~espírito de porco~~ curioso inserisse um número muito grande em um dos campos? Será que a aplicação daria conta do recado?

Bom, não né. O int, destino da conversão da string nos inputs, aloca 32 bits de memória para cada variável. Isso quer dizer, na prática, que o valor máximo que ele pode armazenar é 2147483647 (e o menor, -2147483648). Quando o número alvo extrapola esse limite, essa exceção NumberFormatException é lançada.
Para solucionar isso, poderíamos mudar o tipo de destino de int para long, mas o problema da limitação ainda se mantém. Claro que é bem mais difícil que alguém indique um número grande como o long (cujo valor máximo é 9223372036854775807), mas é sempre bom não dar chance pro azar. Por isso, a melhor coisa é adicionar algum tipo de limitação e informar ao usuário que ~~ele tá maluco~~ precisa informar um número dentro do intervalo esperado.

Além disso, a aplicação encerrar quando encontra um erro é meio chato. O ideal seria que ela voltasse a iniciar caso encontrasse um erro, até que os inputs fossem inseridos de maneira correta.

Podemos resolver adicionando um novo catch no nosso try e envolvendo a aplicação toda em um laço while:

public class Counter {  
    public static void main(String[] args) {  
        while (true) {  
            try {  
                Scanner scanner = new Scanner(System.in);  
                System.out.println("Insira dois números e a aplicação imprimirá a diferença entre eles, linha a linha.");  
                System.out.print("Insira o primeiro número: ");  
                int num1 = Integer.parseInt(scanner.nextLine());  
                System.out.print("Insira o segundo número: ");  
                int num2 = Integer.parseInt(scanner.nextLine());  

                count(num1, num2);  
                break;  
            } catch (InvalidParametersException e) {  
                System.out.println(e.getMessage());  
            } catch (NumberFormatException e) {  
                System.out.println("Um dos números informados estão acima da capacidade de processamento desta aplicação. Por favor, tente novamente com um número menor.");  
            }        
        }    
    }  
    public static void count(int num1, int num2) throws InvalidParametersException { /* lógica descrita acima */ }

A primeira coisa que fizemos foi, então, envolver todo o try-catch em um laço while, e definimos a condição como true. Ou seja, enquanto true for... verdadeiro, o laço se repetirá.
Fizemos um famigerado loop infinito, a perdição de todo processador.

Em vez de colocarmos a condição para parada do while na sua definição, apenas colocamos um break ao final da chamada ao método count(); desse modo, se não houver alguma exceção lançada, o loop será interrompido.

Ao final da chamada, definimos mais um bloco catch, capturando a exceção NumberFormatException e passando uma mensagem de erro mais fácil de ser compreendida. Bora testar pra ver se está tudo certo?

Bom demais.

Agora, a única coisa que falta é chamar o método Counter.main() na classe Main. Pode ser redundante, mas eu prefiro deixar bem separadinhas e explicadas as coisas.

public class Main {  
    public static void main(String[] args) {  
        Counter.main(args);  
    }
}

É isso aí, pessoal. Obrigado pela paciência e por ter lido esse post gigantesco.
O repositório desse projetinho pode ser encontrado aqui. Até a próxima!

Desafio de Código 01 - Explorando Serviços de Telefonia

Lucas Nabesima — Mon, 26 Aug 2024 13:00:00 +0000

Uma das coisas que eu acho bem bacana nos bootcamps da DIO é que durante a trilha tem alguns exercícios de código para serem realizados, com um editor ali do lado e algumas condições; uma pegada meio HackerRank assim. É bem bacana que ajuda a sedimentar os conhecimentos adquiridos durante as partes teóricas e não é uma pegada mais complexa como o desafio de projeto: é algo mais simplificado, para testar seu raciocínio lógico e seu conhecimento na linguagem. Assim como no HackerRank, eles te dão alguns trechos já prontos e você desenvolve sua lógica em cima disso.

Essa semana foi uma doideira, então a única coisa que eu consegui fazer foi a resolução dos dois desafios propostos no módulo "Explorando Serviços de Telefonia". Como o patrocinador desse bootcamp é a Claro, muitos dos temas vão ter esse pique de telecom.

Verificação de Serviço Contratado

Enunciado:

Uma concessionária de telecomunicações oferece quatro tipos de serviços: telefonia móvel, telefonia fixa, banda larga e TV por assinatura. Para facilitar o atendimento ao cliente, é necessário implementar um programa que verifique se um cliente específico contratou um determinado serviço. Por exemplo, quando um cliente liga para a central de atendimento e menciona um serviço, o atendente deve ser capaz de rapidamente verificar se esse serviço está contratado pelo cliente.

Entrada:

Duas strings: Uma com o serviço que a aplicação vai verificar (por exemplo, movel, fixa, banda larga, tv). A segunda deve conter o nome do cliente e quais produtos ele tem, separados por vírgula (Alice,movel,fixa)

Saída esperada:

Se o cliente contratou o serviço descrito na primeira entrada, a aplicação deve exibir Sim. Caso contrário, deve exibir Nao.

Exemplos:

Entrada	Saída
movel Alice,movel,fixa	Sim
fixa Bob,movel,tv	Nao
tv Carol,movel,fixa,tv	Sim

Código inicial:



import java.util.Scanner;

public class VerificacaoServico {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);

        // Entrada do serviço a ser verificado
        String servico = scanner.nextLine().trim();

        // Entrada do nome do cliente e os serviços contratados
        String entradaCliente = scanner.nextLine().trim();

        // Separando o nome do cliente e os serviços contratados
        String[] partes = entradaCliente.split(",");
        String nomeCliente = partes[0];
        boolean contratado = false;

        // TODO: Verifique se o serviço está na lista de serviços contratados

        scanner.close();
    }
}

Resolução:

Esse é um desafio relativamente simples. A aplicação recebe uma string delimitada por vírgulas que é transformada em array e precisamos descobrir se dentro dela existe uma string que coincide com outra entrada do usuário, que é o serviço que queremos checar se o cliente possui. Fácil, né?

Pra mim, que tem um histórico de JavaScript e C#, é só usar um método verificador (como o Array.includes() ou o List.Contains()). Certo? Errado.

Não existe, em Java, um método como esse na classe Array. Isso pode ser devido à implementação ser muito mais próxima da que acontece em linguagens de baixo nível (como C), que estabelece que elas devem ser estruturas de dados simples e eficientes. Aparentemente esse tipo de consulta não faz parte das funções essenciais dessa estrutura.

Descobrir essa informação foi um choque. O que o Java espera que eu faça? Que eu escreva um loop for e cheque manualmente se cada elemento bate com o item que eu estou procurando? Irmão, eu trabalho em tempo integral, tenho uma filha de menos de dois anos e ainda estou estudando Java. Tenho tempo pra isso não, bicho.

Mas eu descobri que desde o Java 8 é possível converter a array em uma list e, esta sim, tem o método .contains(). Então, para a resolução desse problema, é só converter a array partes em uma lista, e então verificar se dentro dessa lista existe a string passada em servico.
Se existir imprimimos Sim e em caso contrário, imprimimos Não.



import java.util.Arrays;
import java.util.Scanner;

public class VerificacaoServico {
    public static void main(String[] args) {
        //...
        // TODO: Verifique se o serviço está na lista de serviços contratados
        contratado = Arrays.asList(partes).contains(servico);

        System.out.println(contratado ? "Sim" : "Nao");

        scanner.close();
    }
}

Com isso o exercício está concluído, mas durante a pesquisa que fiz descobri que desde o Java 8 existe uma abstração que ajuda a trabalhar com coleções de dados de uma maneira mais simples e de uma abordagem mais funcional, parecida com o que existe em JavaScript: as streams.

Assim como com listas, podemos converter o vetor em uma stream e checar se algum dos elementos presentes nela corresponde ao que foi passado em servico:



import java.util.Arrays;
import java.util.Scanner;

public class VerificacaoServico {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);

        // Entrada do serviço a ser verificado
        String servico = scanner.nextLine().trim();

        // Entrada do nome do cliente e os serviços contratados
        String entradaCliente = scanner.nextLine().trim();

        // Separando o nome do cliente e os serviços contratados
        String[] partes = entradaCliente.split(",");
        String nomeCliente = partes[0];
        boolean contratado = false;

        contratado = Arrays.stream(partes).anyMatch(servico::equals);

        System.out.println(contratado ? "Sim" : "Nao");

        scanner.close();
    }
}

Podíamos ter feito a verificação passando um callback para o método .anyMatch(p -> p == servico), mas isso checa se p e servico não apenas tem o mesmo valor mas também se apontam para o mesmo endereço de memória (ou seja, se são de fato o mesmo objeto). Normalmente, quando lidamos com strings, essa comparação vai retornar false mesmo se o valor for igual -- ou seja, um falso negativo. Por isso, a comparação usando servico::equals é mais adequada, porque compara apenas o valores entre os dois elementos, mais ou menos como o comparador de igualdade do JavaScript (==).

Com essa alteração, podemos julgar que o exercício está concluído. O que falta é rodar os testes e ver se eles passam:

Bom demais.
Esse exercício me deu outro motivo para reclamar de Java, que é a sintaxe da lambda. O uso da seta simples (->) ao invés da dupla (=>) me incomoda muito.

Verificação de Contratação de Combo Completo

Enunciado:

Implemente um sistema que verifique se um cliente de uma empresa de telecomunicações contratou um combo completo de serviços. Um combo completo inclui os três serviços principais oferecidos pela empresa: telefonia móvel, banda larga e TV por assinatura. O sistema deve ler uma lista de serviços contratados pelo cliente e determinar se todos os serviços necessários estão incluídos. Caso todos os três serviços estejam presentes, o sistema deve retornar "Combo Completo". Se faltar qualquer um dos serviços, o sistema deve retornar "Combo Incompleto".

Entrada:

Uma string contendo os serviços contratados pelo cliente, separados por vírgula. Os valores possíveis são movel, banda larga e tv.

Saída esperada:

Uma string contendo Combo Completo se o cliente tiver todos os serviços contratados, Combo Incompleto do contrário.

Exemplos:

Entrada	Saída
movel,banda larga,tv	Combo Completo
movel,tv	Combo Incompleto
banda larga,tv,movel	Combo Completo

Código inicial:



import java.util.Scanner;

public class VerificacaoComboCompleto {

    // Função para verificar se o cliente contratou um combo completo
    public static String verificarComboCompleto(String[] servicosContratados) {
        // Variáveis booleanas para verificar a contratação de cada serviço
        boolean movelContratado = false;
        boolean bandaLargaContratada = false;
        boolean tvContratada = false;

        // TODO: Itere sobre os serviços contratados
        for (String servico : servicosContratados) {
        }

        // TODO: Verifique se todos os serviços foram contratados
        if () {
            return "Combo Completo";
        } else {
            return "Combo Incompleto";
        }
    }

    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);

        // Solicitando ao usuário a lista de serviços contratados
        String input = scanner.nextLine();

        // Convertendo a entrada em uma lista de strings
        String[] servicosContratados = input.split(",");

        // Verificando se o cliente contratou um combo completo
        String resultado = verificarComboCompleto(servicosContratados);

        // Exibindo o resultado
        System.out.println(resultado);

        // Fechando o scanner
        scanner.close();
    }
}

Resolução:

De novo, esse é um desafio simples. Para chegar no resultado, apenas alguns passos precisam ser seguidos:

Iterar sobre a array gerada pelo método main a partir da string inserida pelo usuário;
Checar se os serviços disponibilizados (descritos nas variáveis booleanas logo acima) foram contratados;
- Em caso positivo, a variável correspondente deve ter seu valor alterado para true.
Verificar se todos os serviços estão com o valor true. Apesar de ter mais passos, é bem mais direto que o anterior. Podemos começar a resolver esse trem de um jeito bem tosco, com uma série de ifs encadeados: ```java

for (String servico : servicosContratados) {
if(servico.equals("movel")) movelContratado = true;
if(servico.equals("bandaLarga")) bandaLargaContratada = true;
if(servico.equals("tv")) tvContratada = true;
}

E preenchemos a condição do nosso `if`:
```java


if (movelContratado && bandaLargaContratada && tvContratada) {
    return "Combo Completo";
} else {
    return "Combo Incompleto";

Assim como no primeiro, com essas adições o desafio pode ser considerado como completo, mas esses ifs, um seguido do outro me incomoda um pouco. Podemos alterar isso pra um switch pra ficar menos feio:



for (String servico : servicosContratados) {
    switch (servico) {
        case "movel":
            movelContratado = true;
            break;
        case "banda larga":
            bandaLargaContratada = true;
            break;
        case "tv":
            tvContratada = true;
            break;
        default:
            System.out.println("Serviço inválido.");
            break;
    }
}

Há quem diga que os ifs são de mais fácil leitura e que o ganho que a otimização traria para um switch tão pequeno como esse é desprezível. Outros diriam que eu tenho pouca consistência interna, reclamando de checar manualmente strings em um exercício e fazendo sem um pio em outro.
Pra essas pessoas eu digo:

O código final ficaria então:



import java.util.Scanner;
public class VerificacaoComboCompleto {
    // Função para verificar se o cliente contratou um combo completo
    public static String verificarComboCompleto(String[] servicosContratados) {
        // Variáveis booleanas para verificar a contratação de cada serviço
        boolean movelContratado = false;
        boolean bandaLargaContratada = false;
        boolean tvContratada = false;

        for (String servico : servicosContratados) {
            switch (servico) {
                case "movel":
                    movelContratado = true;
                    break;
                case "banda larga":
                    bandaLargaContratada = true;
                    break;
                case "tv":
                    tvContratada = true;
                    break;
                default:
                    System.out.println("Serviço inválido.");
                    break;
            }
        }

        if (movelContratado && bandaLargaContratada && tvContratada) {
            return "Combo Completo";
        } else {  
            return "Combo Incompleto";
        }
    }
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        // Solicitando ao usuário a lista de serviços contratados
        String input = scanner.nextLine();
        // Convertendo a entrada em uma lista de strings
        String[] servicosContratados = input.split(",");
        // Verificando se o cliente contratou um combo completo
        String resultado = verificarComboCompleto(servicosContratados);
        // Exibindo o resultado
        System.out.println(resultado);
        // Fechando o scanner
        scanner.close();
    }
}

Que, ao rodar a suite de testes, nos mostra que deu tudo certo:

O código desses (e dos demais) desafios está aqui.
Então é isso, pessoal. Até a próxima!

Mais sintaxe básica - Loops e Exceções

Lucas Nabesima — Mon, 19 Aug 2024 23:51:56 +0000

Essa semana foi uma daquelas pouco produtivas. Não consegui progredir muito no conteúdo do bootcamp, mas consegui cobrir as últimas unidades teóricas desse módulo:

Java, assim como a maior parte das linguagens de alto nível derivadas do C, tem três tipos básicos de laços de repetição (os famosos loops): o for, o while e o do-while.

O for é usado quando sabemos previamente qual o tamanho do elemento que vai ser usado como iterável (como uma array). Esse elemento pode sofrer alterações dinamicamente (como, por exemplo, receber dados de uma API), então pode ser que você, como desenvolvedor, não saiba exatamente quantos elementos o iterável terá, mas o código vai saber. Sua estrutura básica é:


int[] numbers = {1, 2, 3, 4, 5};
for (int counter = 0; counter < numbers.length; counter++) {
    System.out.println(numbers[counter]);
}

A primeira parte, o int counter = 0 é o que chamamos de variável de contagem.
Devem existir nomes mais bonitos, mas esse é um que é bem explicativo sobre o que ela faz. Ela basicamente... faz uma contagem.

Inicializamos ela em 0 e, na segunda parte, comparamos ela ao tamanho da array numbers. Isso é o que chamamos de condição. Enquanto essa condição for verdadeira (ou seja, retornar true), o loop irá continuar.
Não precisa ser necessariamente uma comparação com algum iterável, mas normalmente é usado dessa forma, E, por fim, temos a alteração do contador, que pode ser uma incrementação ou uma decrementação. Também não é estritamente necessário que seja de um em um essa alteração, mas é o mais comum a ser visto.

O laço de repetição while por outro lado, não prevê essas quantidades finitas de iterações. Ele checa se uma condição é verdadeira e, em caso positivo, realiza alguma ação. Sua estrutura é essa:

boolean podeJavascriptNoBack = false;
while (!podeJavascriptNoBack) {
    System.out.println("Tá proibido JavaScript no back-end.");
};

O que está entre os parênteses na declaração do laço é a condição que será testada para verificar se ele continua ou não. Enquanto o resultado dessa condição for verdadeiro (true), a ação entre as chaves será realizada. Essa informação é importante porque dela podemos tirar algumas conclusões:

A ação do loop só vai acontecer caso a condição seja positiva. Se em alguma determinada iteração o valor da condição mudar (de true para false), o loop é interrompido e a ação daquele ciclo não é executada;
Pode existir algum loop que não execute ação alguma porque a condição foi avaliada como false desde a primeira iteração;
Se não houver alguma ação para mudar o resultado da condição, nos veremos diante de um loop infinito.

O do-while é bem parecido com o while, com a diferença de que a ação acontece antes da verificação da condição. Isso quer dizer que o laço vai executar pelo menos uma ação antes de ser interrompido. A sintaxe é muito parecida com a do while:

boolean condition = true;
do {
    System.out.println("I'm inside a loop tee-hee!");
} while (condition);

Da mesma maneira que o while, se não houver alguma ação para alterar o resultado da condição, estaremos lidando com um loop infinito.

Para ter ainda mais controle sobre o fluxo dos laços, ainda existem as palavras chaves break e continue. O break interrompe o laço inteiro, enquanto que o continue interrompe apenas a iteração atual. Por exemplo:

for (int i = 0; i <= 5; i++) {
    if (i == 4) break;
    System.out.println(i); //0 1 2 3
}

Nesse exemplo, o for vai rodar até que o contador i seja maior ou igual ao número 5, e a cada iteração o contador atual será impresso no console. Contudo, quando o contador for igual a 4, o laço vai ser interrompido e os últimos dois números não serão impressos.

Agora, vamos supor que você precise imprimir os números ímpares de 1 a 10 no console. Podemos usar o continue com a seguinte estrutura:

for (int i = 0; i <= 10; i++) {
    if (i % 2 == 0) continue;
    System.out.println(i); //1 3 5 7 9
}

Ou seja, de 0 a 10, o loop vai verificar se o contador é divisível por 2 utilizando o módulo. Em caso positivo, o laço vai pular para a próxima iteração, mas em caso negativo o valor de i vai ser impresso no terminal.

Até aqui tranquilo, né? Vamos seguir para o tratamento de exceções.

Durante o curso do desenvolvimento de uma aplicação, problemas irão ocorrer. Em Java existe uma distinção entre problemas graves, que afetam o sistema ou ambiente onde a aplicação está (os errors) e normalmente são condições irrecuperáveis, e problemas mais simples, em que a aplicação consegue contornar de alguma forma (as exceptions).

No caso dos errors, pode se tratar de algum problema físico (como um OutOfMemoryError), exaustão dos recursos disponíveis (como um StackOverflowError) ou até mesmo um erro da própria JVM (Internal Error). O importante notar é que, nesse caso, não tem como tratar isso. É uma situação que quebra a aplicação e normalmente a joga em um estado irrecuperável.

Mas existe uma categoria de problemas em que é possível se recuperar: as Exceptions. As exceções são problemas que podem ser capturados e devidamente tratados, para que nosso programa não quebre na cara do cliente. As exceções podem ter as mais variadas causas, que podem ser desde problemas com a infraestrutura (como leitura/escrita de dados, conexão com um banco de dados SQL etc) ou de lógica (como um erro de argumento inválido).

Para realizar o tratamento de erros, normalmente um bloco try-catch é utilizado. Essa estrutura tenta executar uma ação (descrita no bloco try) e, caso encontre alguma exceção, captura esse problema e realiza uma tratativa em cima dela (que está descrita no bloco catch). Ela segue essa sintaxe:

try {
    double result = 10 / 0; //isso vai lançar um ArithmeticException
    System.out.println(result);
} catch (Exception e) {
    System.out.println("Não é possível dividir por 0, mané.");
}

Podemos declarar vários blocos catch encadeados, para tentar granularizar as tratativas de acordo com os erros encontrados:

try {  
    int result = 10 / 0; 
    System.out.println(result);  
} catch (ArithmeticException e) {  
    System.out.println("Não é possível dividir por 0, mané.");
} catch (NullPointerException e) {
    System.out.println("Alguma coisa que você informou veio nula, bicho.");
} catch (Exception e) {  
    System.out.println("Deu ruim, irmão. Um erro genérico ocorreu: " + e.getMessage());  
}

Além disso, ao final de toda a estrutura podemos declarar um bloco de código que sempre será executado, independente do caminho que o fluxo tomou: o finally:

try {  
    int result = 10 / 0; 
    System.out.println(result);  
} catch (ArithmeticException e) {  
    System.out.println("Não é possível dividir por 0, mané.");
} catch (NullPointerException e) {
    System.out.println("Alguma coisa que você informou veio nula, bicho.");
} catch (Exception e) {  
    System.out.println("Deu ruim, irmão. Um erro genérico ocorreu: " + e.getMessage());  
} finally {
    System.out.println("Cabô.");
}

Nesse exemplo, o código vai tentar dividir 10 por 0. Em seguida, vai entrar no primeiro bloco catch e imprimir "Não é possível dividir por 0, mané." e, por fim, entrar no bloco finally e imprimir "Cabô". Independente do caminho seguido, se houve sucesso ou não no try, o finally vai ser sempre executado.

Isso é tudo? Não! Nada é simples no Java.
As exceções podem ser divididas em dois tipos: as exceções verificadas (checked exceptions) e as não verificadas (unchecked exceptions). No caso das exceções verificadas, o compilador pede para que elas sejam tratadas para evitar que condições que estão além do escopo de código possam impactar no fluxo da aplicação. Por exemplo, o banco de dados que o programa está usando pode ter tido um problema, e a conexão pode falhar. Ao invés de simplesmente mostrar o erro, o Java pede que seja feita uma tratativa, como a abaixo:

public class DatabaseExample {
    public static void main(String[] args){
        try {
            Connection conn = getConnection();
            //executa alguma ação aqui...
        } catch (SQLException e) {
            System.out.println("Não foi possível conectar ao banco de dados. Erro: " + e.getMessage());
        }
    }

    public static Connection getConnection() throws SQLExeption {
        String url = "jdbc:mysql://localhost:3306/mydatabase";
        String user = "user";
        String password = "mySuperSecretPassword"; //por favor não armazenem senhas no código

        //isso pode lançar um erro de SQL
        return DriverManager.getConnection(url, user, password);
    }
}

O método getConnection() tenta realizar a conexão com o banco de dados usando as credenciais informadas, mas se em algum momento der problema (o banco está offline, as credenciais estão erradas, a máquina está desconectada da rede etc), a exceção será lançada. O método main, que chama o getConnection(), captura essa exceção e informa ao usuário que houve um erro ao realizar a conexão, ao invés se só mostrar a stack trace.

O compilador pede que esse tratamento seja implementado para proteger a aplicação de erros além do controle do desenvolvedor, tornando o programa mais resiliente e resistente à falhas.

Já as unchecked exceptions são exceções que não precisam ser obrigatoriamente tratadas. São casos de classes cujos métodos estão sob o controle do desenvolvedor e são, de modo geral, algum tipo de erro no código (seja de lógica ou uso incorreto de alguma API). Alguns exemplos desses são os famosos IllegalArgumentException, ArrayIndexOutOfBoundsException e NullPointerException.
Isso quer dizer que, se o compilador não reclamar, eu não preciso implementar um tratamento?
Não né. Muito melhor ter uma mensagem de erro amigável para o usuário saber o que tá acontecendo do que mandar isso aqui:

Bota tudo num try-catch que é sucesso.

E, por fim, teve um módulo sobre debugging usando Intellij e Eclipse, que foi mais prático do que teórico. Contudo, não consegui apresentar as informações passadas pela instrutura para o meio textual. Um post sobre debug em Java fica pro futuro.

Os dois módulos que restam nessa unidade são práticos (finalmente!). O próximo post vai ter bastante código. Até lá!

Exercício - Simulando Uma Conta Bancária Através Do Terminal

Lucas Nabesima — Mon, 12 Aug 2024 13:00:00 +0000

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:

Criar uma classe para "abrigar" os dados recebidos no terminal e o método criador de conta;
Pedir ao usuário os dados, ler as informações inseridas no terminal e armazená-las em variáveis;
Exibir ao usuário a mensagem de confirmação, organizando as variáveis em uma string legível.

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!

Mas o que diabos é Java?

Lucas Nabesima — Mon, 05 Aug 2024 11:11:41 +0000

Ok, decidi que vou aprender Java. Me dediquei mais uma semana no bootcamp que selecionei e fiz anotações. Show. Ótimo.

Mas o que é Java, na real?
Confesso que escrever sobre isso faz com que eu me sinta um pouco bobo, porque a maior parte das pessoas que tem contato com programação tem uma ideia sobre o que é Java, mas vem comigo: O começo dessa viagem pode ser lento, mas prometo que vai ficar melhor mais pra frente.

Java é uma linguagem de alto nível, orientada a objetos, com tipagem forte e estática, que é compilada e interpretada.

Também é conhecida por ter o mascote mais horroroso do mundo.

Mas o que esse monte de palavras quer dizer na prática?
Ela ser orientada a objetos quer dizer que, além de seguir os pilares do paradigma, para qualquer coisa que queira fazer, é necessário definir uma classe.
Ou seja, para escrever o famoso Hello world, em vez de fazer algo assim:

console.log("Hello world")

É necessário fazer assim:

public class HelloWorld(){
    public static void main(String[] args){
        System.out.println("Hello world")
    }
}

Parece um contrassenso com o que eu disse no primeiro post, de economizar palavras sempre que possível -- e é mesmo: uma das coisas que mais me incomodam no Java é essa verbosidade excessiva. Mas vamos ignorar isso por enquanto e focar nas coisas boas da linguagem: a definição de tipos e regras claras e estruturadas para o desenvolvimento.

Enquanto que as variáveis em linguagens com tipagem fraca e dinâmica podem ser alteradas ao bel prazer do desenvolvedor, no caso de linguagens com tipagem forte e estática as variáveis devem ter seus tipos definidos no ato da declaração, e não podem ter esse valor alterado durante o ciclo de vida do algoritmo. Por exemplo, enquanto que no JavaScript isso é perfeitamente válido:

let myString = "Hello";

myString = 10;

Para declarar uma variável em Java, a sintaxe é essa:

String myString = "Henlo fren";

myString = 10 //Required type: String, Provided: int

Esse tipo de alteração de tipos não é permitido e quando algo assim é feito, o compilador do Java reclama e aponta um erro. Esse tipo de verificação estática (o mesmo tipo de verificação que o TypeScript faz, por exemplo) é ótima porque salva o desenvolvedor de cometer erros que só seriam descobertos quando a aplicação estivesse rodando.

Mas o negócio de ser compilado e interpretado deu um nó na minha cabeça. Durante muito tempo eu tinha uma visão mais simples das coisas, que as linguagens se dividiam em "interpretadas" (como JavaScript e Python) e "compiladas" (como Java e C). Mas o lance do Java é que o código-fonte (ou seja, o que o dev escreve) é compilado para um código intermediário, que será lido por uma máquina virtual e interpretado, "traduzindo" para linguagem de máquina.

Mais ou menos isso aí.

Esse ciclo foi o que possibilitou o famoso slogan do Java Write Once, Run Everywhere (Escreva uma vez, rode em todos os lugares). A JVM (Java Virtual Machine) pode ser colocada em qualquer lugar para rodar programas em Java, como caixas eletrônicos, computadores de bordo e até em leitores de Blu-ray.

Mas claro que para poder estar presente em tantos dispositivos assim, o que o desenvolvedor escreve precisa estar bem padronizado para que o processo de compilação ocorra sem problemas -- e essa é uma das características do Java: existem muitas regras e convenções que estão lá para tornar o código mais simples e limpo. Por exemplo, as classes precisam ser definidas dentro do diretório src do projeto. O nome da classe precisa ser o mesmo nome do arquivo .java. As variáveis e métodos devem seguir camelCase, mas os nomes de classe devem seguir PascalCase.
Muitas regrinhas que parecem bestas, mas quando somadas fazem com que tudo seja mais organizado.

Para fechar o módulo introdutório e sair só da teoria, foi passado um exercício: Criar uma classe para representar uma smart TV, com as seguintes características:

Ela teve ter as propriedades ligada (boolean), canal (int) e volume (int);
A TV deve poder ligar e desligar, alterando a propriedade ligada;
A TV poderá aumentar e diminuir o volume, em incrementos de 1;
A TV poderá aumentar e diminuir o canal atual, em incrementos de 1 ou definir um número específico para o canal.

Essa classe (muito criativamente chamada de SmartTv) deve ser definida em um arquivo SmartTv.java. Não tenho muito o que falar sobre ela, é uma classe relativamente simples de entender.

/**  
 * The SmartTv class represents a smart TV device. 
 * It allows the user to control the power state, channel number, and volume of the TV. 
 * 
 * @author Lucas Nabesima  
 * @version 1.0  
 * @since 31/07/2024  
 */
public class SmartTv {  
    private boolean isOn;  
    private int channelNumber;  
    private int volume;  

    public SmartTv() {  
        this.isOn = false;  
        this.channelNumber = 1;  
        this.volume = 1;  
    }  

    public void turnOn() {  
        System.out.println("TV is turning on...");  
        this.isOn = true;  
        System.out.println("TV is on.");  
    }  

    public void turnOff() {  
        System.out.println("TV is turning off...");  
        this.isOn = false;  
        System.out.println("TV is off.");  
    }  

    public void channelUp() {  
        this.channelNumber++;  
        System.out.println("Channel changed to: " + this.channelNumber);  
    }  

    public void channelDown() {  
        if (this.channelNumber <= 1) {  
            System.out.println("Can't lower channel number.");  
            return;  
        }  
        this.channelNumber--;  
        System.out.println("Channel changed to: " + this.channelNumber);  
    }  

    public void setChannelNumber(int channelNo) {  
        this.channelNumber = channelNo;  
        System.out.println("Channel changed to: " + this.channelNumber);  
    }  

    public void volumeUp() {  
        this.volume++;  
        System.out.println("Volume changed to: " + this.volume);  
    }  

    public void volumeDown() {  
        if (this.volume <= 0) {  
            System.out.println("Can't lower volume.");  
            return;  
        }  
        this.volume--;  
        System.out.println("Volume changed to: " + this.volume);  
    }  
}

"Ain Lucas o que são esses public e void?
public é um modificador de acesso. Isso quer dizer que o que quer que esteja acompanhado por ele é público, então ~~qualquer um pode passar a mão~~ está acessível para outras classes e métodos. Outros modificadores incluem private, que indica que somente aquela classe tem acesso e protected. Nesse último caso, somente a classe e seus descendentes têm acesso.

Já o void nesses métodos indicam que essas funções não tem retorno. Todos os métodos precisam ter uma anotação que informa qual o tipo de seu retorno. Pode ser um dos tipos primitivos da linguagem (int, byte, short, long, float, double, boolean ou char), pode ser void indicando que aquele método não tem retorno, um objeto padrão (como String) ou outra coisa completamente diferente -- como um objeto definido pelo dev.

Para utilizar essa classe, basta instanciar no nosso método main:

public class Main {  
    public static void main(String[] args) {  
        SmartTv tv = new SmartTv();  

        tv.turnOn();  

        tv.channelUp();  
        tv.channelDown();  
        tv.channelDown();  

        tv.volumeUp();  
        tv.volumeDown();  
        tv.volumeDown();  
        tv.volumeDown();  

        tv.setChannelNumber(13);  

        tv.turnOff();  
    }  
}

E o resultado será esse:

Até a semana que vem, com mais um módulo!

O início da jornada em Java

Lucas Nabesima — Sun, 28 Jul 2024 12:58:02 +0000

Eu sou um homem de gostos simples.
Gosto de café sem açúcar, de carne mal passada, de chocolate; o trivial.
E assim como a maior parte das pessoas, não gosto de fazer grandes esforços para atingir resultados que podem ser atingidos com menos.

Por isso, sempre que via os exemplos de Java para um simples Hello World, como isso:

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

Quando simplesmente poderia fazer a mesma coisa com apenas uma linha de JavaScript:

console.log("Hello World!")

Meu nariz torcia tanto que chegava até à orelha. Apesar de gostar bastante de escrever, eu acredito que Kevin Malone foi certeiro no seu pensamento.

Por que gastar muito tempo falar muita palavra quando pouca palavra dá jeito?

Esse, inclusive, foi um dos motivos pelos quais o C# me chamou bastante atenção nos últimos tempos. Ele soma a robustez, tipos estáticos e fortes do Java, mas me permite escrever um código mais conciso.


Console.WriteLine("Hello World!")

Não tem nem comparação.

Contudo, esses dias eu recebi um email com o anúncio da abertura de um bootcamp de Java, da DIO em parceria com a Claro.

Inicialmente a minha reação foi de escárnio, mas aí os pensamentos intrusivos ganharam e fui ver a grade do programa. Honestamente, pareceu bem interessante e me fez pensar "Por que não fazer esse curso?"

Bom, as respostas podem ser as mais variadas:

Por que não?;
Acredito que ter uma noção básica da linguagem (o que é o máximo que um bootcamp vai proporcionar, não sejamos emocionados) é importante -- recentemente entrei em um projeto em Node e demorou um tempo pra conseguir entender como as coisas estavam funcionando;
Sigo fielmente o conselho que o ET Bilu deu quando agraciou nosso planeta com sua visita:

Mas para garantir que eu vou chegar até o final desse percurso, resolvi documentar cada passo do processo. A ideia não é explicar passo a passo o que é dado no curso (nem fazer um review dele), mas sim relacionar as coisas vistas com o conhecimento que já tenho e fazer desse amontoado de informações um conhecimento útil.

Então agora, já com o Intellij instalado, bora ver no que dá.