Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Porque não executar o cálculo dos totais todos em um só método deixando o código mais simples?

Da forma como foi feito no curso, está sendo executado um for por toda a lista duas vezes. Porque não utilizar uma lógica como a de baixo? (desculpa o código estar em Inglês. Estou tentando praticar Inglês em todo lugar que consigo hehehe)

Poderia até ser usado para ensinar o when que já é a segunda vez que vocês perdem a oportunidade de ensinar.

class ViewAbstract(private val view: View) {
    fun calculateTotals(transactions: List<Transaction>){
        var total = BigDecimal.ZERO
        var revenue = BigDecimal.ZERO
        var expense = BigDecimal.ZERO

        for(transaction in transactions){
            when(transaction.type){
                Type.REVENUE -> {
                    total += transaction.value
                    revenue +=transaction.value
                }
                Type.EXPENSE -> {
                    total -= transaction.value
                    expense += transaction.value
                }
            }
        }
        view.card_total_abstract.text = total.efFormatCurrency()
        view.card_revenue_abstract.text = revenue.efFormatCurrency()
        view.card_expense_abstract.text = expense.efFormatCurrency()
    }
}

A propósito, vocês também poderiam ter aproveitado esse momento para ensinar que no Kotlin dá pra trabalhar com o BigDecimal da forma como fiz. Vocês já ensinaram que lista[index] é o mesmo que lista.get(index) no Kotlin. É o mesmo tipo de coisa. Vocês poderiam ter ensinado. Isso ajudaria a abrir a mente do aluno a tentar outras coisas que fazem muito sentido, mas que o Java não permite.

4 respostas

Fala ai Guilherme, tudo bem ?

Obrigado pelo feedback cara, vou ver com o Alex os motivos disso e te damos um feedback, pode ser?

solução!

Oi Guilherme tudo bem? É bem comum o pessoal escrever o código em Inglês hehe

Sobre o uso do for excessivo é proposital mesmo. Aqui na Alura utilizamos muito a abordagem de deixar do jeito que 'funciona' para depois apresentar técnicas mais concisas e sofisticadas para resolver o mesmo problema. Inclusive nos próximos capítulos já começo a realizar a refatoração desse calculo.

Sobre o uso do When Expression: A princípio, parece uma abordagem bacana, porém, ele tende a deixar o código crescer assim como vemos em um Switch Case, a diferença é que ele é mais sucinto. A propósito na documentação deixa bem claro que o when() é uma forma mais sucinta de escrever um Switch Case...

Apenas para contextualizar: No geral evitamos ao máximo essa abordagem, pois a possibilidade de adicionar cada vez mais responsabilidade em um único lugar cresce mais ainda. Porém, eu acho muito válido a sua sugestão de apresentar a possibilidade do uso do When Expression, vou anotar aqui para deixar um exercício para saber mais.

Sobre o motivo de não focar nos operadores aritméticos em objetos: No nosso planejamento para esses cursos iniciais, adicionar conteúdo para Operator overloading seria algo mais avançado, isto é, num curso avançado, com toda certeza esse assunto seria abordado com muito mais atenção, ensinando, por exemplo, sobre o que são esses operadores e como é possível criar um.

Inclusive, fiz uso do modo indexável justamente pelo AS apresentar a sugestão de mudança, apenas por isso mesmo, pois a ideia não era focar nesse assunto.

Eu fico muito contente que você já tenha aprendido outras features do Kotlin além das que foram apresentadas até o momento, porém procurei focar em conteúdos essenciais para qualquer projeto em Kotlin.

Claro! Tiveram features que não foram apresentadas, justamente porque não era o momento ou por não ter a necessidade durante a implementação, se fosse apresentado seria algo como:

"Olha, essa feature existe".

Evitamos ao máximo esse tipo de abordagem que simplesmente joga diversas features para o aluno sendo que as que ele já conhece resolve o problema, ou seja, se for algo bem mais sofisticado e eficiente (como é o caso das expressões lambdas), como toda a certeza iremos apresentar, caso contrário (como é o exemplo do when Expression), tentamos ir pela linha que havia comentado do exercício de "para saber mais".

Se tiver mais sugestões ou dúvidas fique a vontade em entrar em contato com a gente, o seu feedback é bem importante para a melhoria dos nossos cursos :)

Apenas uma spoiler: no final do terceiro curso eu deixo uns links de artigos pós curso para todos os devs que pretendem aprofundar mais na linguagem ;)

Obrigado, Alex! Muito esclarecedor.

Acho que entrei neste curso com as expectativas erradas hehehe

Antes de começar, esperava um curso mais voltado ao Android, mas como vi que vocês começaram a focar mais nas diferenças entre Java e Kotlin e que o curso de Android em Java era pré-requisito para este, comecei a sentir falta de algumas coisas.

Uma sugestão para o futuro (que até em parte já abordei em outro post no fórum e adicionei como sugestão no Trello de vocês) seria a criação de um curso de Kotlin (ou mais) como substituto do Java fora do Android e transformar o curso existente em um curso de Android simplesmente, assumindo que o desenvolvedor já conhece Kotlin, porque passou pelo outro curso (e não necessariamente conhece Java).

Seria como que uma trilha "Desenvolvedor Kotlin".

Que bom que tenha tenha sanado a sua dúvida :)

Normal sobre as expectativas, pois existe muito conteúdo sobre o assunto que queremos aprender cada vez mais, eu entendo perfeitamente.

Entendo perfeitamente o seu ponto de vista e é por isso que nesses momentos o fórum faz bastante diferença para trocar ideia sobre o curso ou até mesmo sobre conteúdos para agregar mais ainda o que foi visto no curso ;)

Eu vou anotar a sua sugestão e ver com a equipe responsável sobre o planejamento dos cursos

Novamente, obrigado pelo feedback.

[]s

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software