4

Criei dois repositórios para registrar meu estudo de Java e algoritmos

Pessoal, resolvi organizar meus estudos em dois repositórios públicos no GitHub e queria compartilhar com vocês. Meu objetivo é me tornar desenvolvedor Java Backend e, para não me perder no caminho, decidi documentar tudo.

A ideia veio acompanhando o canal do Lowwrizen. Ele tem uma abordagem legal de registrar os exercícios e projetos que faz para aprender, então me inspirei nisso para criar os meus:

  1. BaseJava: É meu "diário" de código. Coloco aqui tudo o que aprendo, desde o zero absoluto até o que estou estudando agora. Serve tanto para consulta própria quanto para quem está começando. (https://github.com/luc4sfernandes/BaseJava)
  2. Beecrowd-Algoritmos-em-Java: Foquei em lógica de programação pura. Estou usando a plataforma Beecrowd para treinar e subindo a implementação dos algoritmos aqui. (https://github.com/luc4sfernandes/Beecrowd-Algoritmos-em-Java)

Se puderem dar uma olhada e, quem sabe, deixar uma estrela para dar uma força, agradeço muito. Se tiverem sugestões de melhoria no código, fiquem à vontade para comentar.

Carregando publicação patrocinada...
3

Bom, como é código para fins de aprendizado, não vou falar todas as possíveis melhorias pra não ficar informação demais. Até porque esse tipo de código é assim mesmo e tende a melhorar com o tempo. Mas seguem algumas dicas rápidas:


Reparei que vc sempre está fechando o Scanner explicitamente (entrada.close()). Para exercícios não faz diferença, mas só pra constar, desde o Java 7 existe o try-with-resources, que fecha o recurso automaticamente:

try (Scanner entrada = new Scanner(System.in)) {
    System.out.println(entrada.nextLine());
} catch etc...

Ao final do bloco try, o recurso é fechado. Claro que para exercícios e programas mais simples, não faria tanta diferença assim estar em um bloco try/catch, mas em código de produção é recomendado tratar corretamente as exceções.

Outro detalhe é que, no caso específico do System.in, não precisa fechá-lo. Isso porque o System.in é um recurso especial gerenciado pela JVM, e uma vez fechado, não pode ser reaberto (mais detalhes aqui). Então ele é uma exceção para a boa prática de "feche tudo que vc abriu". Sem contar que ele será fechado pela JVM ao término do programa, então no caso do System.in, não precisa fechá-lo mesmo.


Na classe Produto tem um campo estático que é inicializado no construtor:

public class Produto {
    // Criar 3 atributos
    String nome;
    double preco;
    static double desconto; // Estara entre 0 e 1

    // Metodo contrutor
    Produto(String nome, double preco) {
        this.nome = nome;
        this.preco = preco;
        desconto = 0.25; // campo estático, não precisa inicializar no construtor
    }

Mas não faz muito sentido isso. Um campo estático é "compartilhado" entre todas as instâncias da classe. Ou seja, cada instância de Produto possui seu próprio nome e preco, mas todas elas compartilham a mesma variável desconto. Em outras palavras, existe apenas um desconto que é o mesmo para todos os produtos.

Por isso não faz sentido inicializar no construtor, pois cada vez que vc cria um novo Produto, está setando de novo o mesmo valor na mesma variável. Faz mais sentido inicializar logo na declaração:

public class Produto {
    private String nome;
    private double preco;
    private static double desconto = 0.25;

    // Metodo contrutor
    public Produto(String nome, double preco) {
        this.nome = nome;
        this.preco = preco;
    }

    public double precoComDesconto() {
        return precoComDesconto(0);
    }
    public double precoComDesconto(double descontoDoGerente) {
        return preco * (1 - desconto - descontoDoGerente);
    }

    public String getNome() {
        return nome;
    }

    public double getPreco() {
        return preco;
    }
}

Repare também que deixei os campos privados, e estes podem ser acessados somente através dos getters (para mais detalhes, veja aqui).

E também fiz um overload no método precoComDesconto: quando chamado sem parâmetros, é o mesmo que chamar com descontoDoGerente igual a zero. Assim vc mantém o cálculo em um único método mais genérico, facilitando a manutenção (da forma que estava, se a conta precisa mudar, teria que alterar em dois lugares).


Por fim, não sei qual versão vc está usando, mas a partir do Java 14 daria para fazer o desafio do dia da semana assim:

String diaSemana = entrada.nextLine();
var result = switch (diaSemana) {
    case "domingo" -> 1;
    case "segunda" -> 2;
    case "terça" -> 3;
    case "quarta" -> 4;
    case "quinta" -> 5;
    case "sexta" -> 6;
    case "sabado" -> 7;
    default -> "Dia invalido!!!";
};
System.out.println(result);
2

Caramba, nem sei por onde começar kkk! Primeiramente, muito obrigado pelo comentário e pelas dicas.

Estou bem no início com Java, então tem coisa aí que eu já tinha noção e outra que nem imaginava. Como estou seguindo um curso, imagino que o intuito deles agora seja mostrar as coisas de forma bem rudimentar mesmo para apresentar as possibilidades.

De novo, muito obrigado e espero contar com a ajuda de vocês nos próximos projetos!