Como preparar o ambiente e escrever seu primeiro código com Kotlin

Recentemente tivemos diversas novidades em um dos maiores eventos de tecnologia do mundo, o Google I/O 2017.

Dentre as diversas novidades, uma das que muitos programadores ficaram atentos foi justamente no anúncio da Google informando que agora o Kotlin terá suporte total no Android Studio a partir da versão 3.0.

Tal informação gerou um grande impacto na comunidade que começou a dar bastante atenção na linguagem e conhecer os diferenciais que a linguagem tem em relação ao famoso Java.

Por mais que eu goste da linguagem Kotlin, não significa que ela é melhor ou pior que a linguagem Java ou outras linguagens existentes. Portanto, fique à vontade em avaliar e decidir o que faz mais sentido para o seu dia a dia.

Afinal, o que é Kotlin?

Para quem nunca ouviu falar, Kotlin é uma linguagem de programação desenvolvida pela JetBrains com as seguintes características:

  • Multiparadigma: além de suportar a orientação a objetos, existem features comuns do paradigma funcional.
  • Multiplataforma: mesmo rodando em seu modo nativo ela também pode ser compilada e executada em um ambiente Java, isto é, na própria JVM. Também, é possível escrever em Kotlin e gerar código JavaScript.
  • Consistente: permite criar estruturas mais enxutas, se comparado com a quantidade de código que outras linguagens apresentam, como é o caso de um POJO no Java.

Existem muitas outras características motivadoras para considerarmos a utilização da linguagem, entretanto, o foco deste post será apresentar um primeiro contato com a linguagem para desenvolvedores Java.

Em outras palavras, não vou entrar em muitos detalhes sobre os motivos pelos quais você deve considerar o Kotlin, mas não se preocupe, deixo aqui a referência da excelente documentação que especifica com muitos detalhes tudo que veremos aqui. Bora começar?

Preparando o ambiente

Como exemplo para o post, farei uso de um projeto para um sistema bancário da empresa Bytebank. Algo similar ao que vemos na apostila de Java Orientação a Objetos.

Caso queira testar o Kotlin, recomendo fortemente o uso do IntelliJ IDEA que é a IDE oficial da JetBrains para desenvolvimento Java, como também, para desenvolver em Kotlin. Claro, você pode estar pensando:

“Puts, eu vou ter que pagar o IntelliJ pra testar o Kotlin?”

Não necessariamente, pois a própria versão Community já permite criar um projeto Kotlin sem nenhuma restrição, ou seja, tanto projeto Kotlin “puro” ou com uma Build Tool como é o caso do Maven ou Gradle.

Para os amantes do Eclipse, não fiquem chateados a JetBrains também dá suporte para ele.

Dica: Caso seja o seu primeiro contato com o IntelliJ IDEA, aproveite para dar uma olhada em algumas das dicas para quem está começando com a ferramenta 🙂

Criando o primeiro código no Kotlin

Após realizar o setup do projeto, percebemos que temos praticamente o mesmo resultado quando criamos um projeto Java, isto é, temos o nosso famoso src para escrevermos o nosso código fonte.

Sendo assim, vamos criar o arquivo Principal.kt, em seguida, adicionaremos o método main que é responsável em executar a nossa aplicação, neste momento você deve estar pensando:

“Bom, então bora para o public static void main…

Pois é, a princípio pensamos isso mesmo, entretanto, como eu havia mencionado, o Kotlin tende ser mais consistente durante a escrita de código e por isso temos o seguinte resultado para o nosso famoso main:


fun main (args: Array){
    println("Bem vindo ao Bytebank")
}

Com o main implementado, precisamos apenas executar para verificar o que acontece! Nesse instante, provavelmente, você deve estar pensando:

“Calma aí! E como fica a estrutura da classe para deixar esse código do main?”

Um dos grandes detalhes do Kotlin é que não precisamos de uma estrutura de classe para criar uma função, nem para executar o main! Portanto, ao executar o código do jeito que tá, temos o seguinte resultado:


Bem vindo ao Bytebank

Algo já esperado né? Mas, além de não precisar de uma classe, note que temos algumas mudanças na assinatura do nosso main:

  • A primeira delas é justamente a keyword fun, isso significa que no Kotlin, ao invés de declarar métodos, declaramos funções. Na prática acabam sendo a mesma coisa, a diferença é que identificamos as funções por meio de uma palavra reservada da linguagem.
  • Note que agora não precisamos mais indicar o modificador de acesso public, ou seja, por padrão o Kotlin já considera que todos os membros sejam públicos, isto é, todas as variáveis, funções ou classes serão marcadas como public caso não tenha indicado um modificador de acesso em específico.
  • Também em nenhum momento falamos qual é o retorno da função, isso significa que por padrão, quando não indicamos o retorno, o Kotlin já devolve uma classe chamada Unit, essa classe representa o nosso famoso void.

Claro, observe que o nosso famoso sysout (System.out.Println()) ficou bastante resumido também! Apenas chamando o println(), como também, não está com os famosos ponto e vírgula (;)…

Observações: Por mais que não tenha o ” ; ” para indicar o final da instrução de uma linha de código, não significa que teremos sérios problemas, por exemplo, ao tentar fazer o seguinte código: println("Bem vindo ao Bytebank") println(“novo print”).

O Kotlin tenta interpretar o segundo println() e, por isso, apresenta um erro.

Em outras palavras, o ” ; “ é opcional, portanto, para fazer com que o código de exemplo funcionasse, bastaria deixar da seguinte maneira: println("Bem vindo ao Bytebank"); println(“novo print").

O mesmo código em Java, teria o seguinte aspecto:


public class Principal {
    public static void main(String[] args) {
        System.out.println("Bem vindo ao Bytebank");
    }
}

Veja que nesse primeiro passo o Kotlin foge bastante dos famosos boilerplates que vemos no Java.

Utilizando as primeiras variáveis

Bacana, fizemos o nosso primeiro contato, portanto vamos avançar. O nosso próximo passo é representar uma conta por meio dos seguintes valores:

  • Número da conta
  • Titular
  • Saldo

No Java teríamos o seguinte código:


public class Principal {
    public static void main(String[] args) {
        System.out.println("Bem vindo ao Bytebank");
        int numeroDaConta = 1;
        String titular = "Alex";
        double saldo = 100.0;
    }
}

E no Kotlin? Vejamos:


fun main(args: Array) {
    println("Bem vindo ao Bytebank")
    val numeroDaConta = 1
    val titular = "Alex"
    val saldo = 100.0
}

Novamente, temos algumas diferenças um tanto quanto notáveis:

  • As variáveis não apresentam seus tipos;
  • Para declarar variáveis estamos usando a keyword val.

Nesse momento você pode estar pensando:

“O que está acontecendo no código? As variáveis não possuem tipos?”

A princípio pode parecer que as variáveis não possuem tipos, mas se tentarmos, por exemplo, verificar qual é a classe do Java que é utilizada em runtime:


println(numeroDaConta.javaClass)
println(titular.javaClass)
println(saldo.javaClass)

Temos o seguinte resultado:


int
class java.lang.String
double

Veja que o Kotlin já consegue assinar pra gente o tipo da variável em tempo de compilação! Mas agora vem aquela questão bem comum:

“Mas se no caso, eu quiser restringir o tipo da variável?”

Lidando com a tipagem das variáveis

Pensando justamente nesse detalhe, temos a capacidade de atribuir o tipo que esperamos para a variável usando o seguinte padrão: nomeDaVariavel: Tipo. Considerando o nosso exemplo inicial, poderíamos escrever o nosso código da seguinte maneira:


val numeroDaConta: Int = 1
val titular: String = "Alex"
val saldo: Double = 100.0

Repare que essa abordagem deixa o código mais flexível, isto é, uma vez que é bem claro qual o tipo da variável, podemos deixar o tipo implícito para evitar um código ambíguo durante a leitura do mesmo.

Entretanto, nos casos que assinamos uma variável e não é tão claro o tipo que ela está recebendo, podemos deixar o tipo de forma explícita para facilitar a leitura e compreensão.

Um dos comportamentos comuns quando usamos variáveis em qualquer linguagem de programação, é justamente o fato de alterarmos os seus valores, por exemplo, ao invés de deixar o titular com apenas o primeiro nome, é muito comum colocarmos o nome completo, no meu caso Alex Felipe, portanto, vamos atribuir novamente o valor da variável titular:


val numeroDaConta: Int = 1
val titular: String = "Alex"
val saldo: Double = 100.0
titular = "Alex Felipe"

Nesse instante o Kotlin apresenta um erro: Val cannot be reassigned. Em outras palavras, ele está nos dizendo que não podemos reatribuir um valor para a variável titular. E agora?

Maneiras de declarar variáveis

Como vimos até agora, tivemos que utilizar a keyword val para declarar uma variável no Kotlin, mas o que isso realmente significa?

Para a galera de Java, a única preocupação durante a criação da variável é justamente em indicar o seu tipo junto do seu nome sucessivamente, certo?

Mas no Kotlin o conceito é um pouco diferente, quando usamos o val estamos indicando que queremos uma variável read-only, ou seja, apenas para leitura, ou melhor, uma constante!

É justamente por este motivo que o Kotlin apresentou aquele erro… Com toda certeza você está pensando:

“E como eu declaro, de fato, uma variável que permite alterar o seu valor”

Para isso o Kotlin reserva a keyword var. Continuando com o nosso código anterior, poderíamos alterar o nome do titular com o seguinte ajuste:


val numeroDaConta: Int = 1
var titular: String = "Alex"
val saldo: Double = 100.0
titular = "Alex Felipe"

De forma resumida, caso suas variáveis precisarem mudar de valor, utilize o var, caso contrário, utilize o val.

É válido mencionar que, se sua variável não foi criada para ser modificada no código, sempre considere o uso do val para garantir a integridade do seu código 🙂

Criando classes

Veja que já conseguimos representar uma conta do banco por meio das variáveis que criamos, mas sabemos que, ao invés de usarmos variáveis soltas, utilizamos classes para representar uma entidade do mundo real, como é o caso da nossa conta!

Sendo assim, vamos criar a classe que conterá as variáveis que acabamos de criar. No Java temos a seguinte estrutura:


public class Conta {

    private int numeroDaConta;
    private String titular;
    private double saldo;

    public int getNumeroDaConta() {
        return numeroDaConta;
    }

    public void setNumeroDaConta(int numeroDaConta) {
        this.numeroDaConta = numeroDaConta;
    }

    public String getTitular() {
        return titular;
    }

    public void setTitular(String titular) {
        this.titular = titular;
    }

    public double getSaldo() {
        return saldo;
    }

    public void setSaldo(double saldo) {
        this.saldo = saldo;
    }

}

Como podemos ver, temos atributos privados junto dos seus métodos de acesso (getters e setters). E como fica no Kotlin?


class Conta {
    var numeroDaConta: Int = 0
    var titular: String = ""
    var saldo: Double = 0.0
}

Bem menor, concorda? Mas perceba que temos um detalhe bem peculiar:

“Por que tivemos que inicializar os membros da classe?”

Seguindo as boas práticas de programação

Um dos detalhes bem bacana dentro do Kotlin, é justamente a ideia de seguir diversas das boas práticas de programação, ou seja, a linguagem, por padrão, não permite que uma variável não seja inicializada e, como podemos ver, isso conta para membros de classes também.

Portanto, se não inicializamos via construtor, por exemplo, precisamos apresentar um valor para a variável por padrão.

Claro, existem casos que inicializar uma variável não é um comportamento esperado, como é o caso do conceito de injeção de dependência. No Kotlin, temos algumas alternativas para lidar com esse tipo de situação, no caso da injeção de dependência, poderíamos usar o recurso lateinit.

Muito legal, mas… Como faço pra instanciar uma classe e atribuir os valores em seus atributos no Kotlin?

Criando objetos e atribuindo valores aos seus membros

Sendo mais prático, faríamos o seguinte código para criar uma conta no Java:


Conta conta = new Conta();
conta.setNumeroDaConta(1);
conta.setTitular("Alex Felipe");
conta.setSaldo(100.0);

No Kotlin ficaria da seguinte maneira:


val conta = Conta()
conta.numeroDaConta = 1
conta.titular = "Alex Felipe"
conta.saldo = 100.0

Note que não é necessário usar a keyword new para criar uma instância, também, perceba que usamos o operador “=” para atribuir um valor para cada membro da classe Conta. E tenho quase certeza que você está se perguntando:

“Considerando as boas práticas de OO, acessar um atributo diretamente é perigoso, justamente por permitir que qualquer um manipule o valor como bem entender… Então por que deixamos assim no Kotlin?”

Utilização de properties

A princípio, parece que estamos acessando diretamente os atributos da classe olhando a estrutura do código escrito em Kotlin, mas, na verdade, estamos acessando uma property, ou seja, ao invés de acessar o campo em si, acessamos de fato os seus “getters” e “setters”.

“Mas Alex, como você me garante que é uma property mesmo? Pois no meu ponto de vista parece um acesso direto…”

Essa é uma pergunta recorrente e é fácil testarmos o código para garantir se realmente estamos lidando com uma property ou um campo de fato. Para isso, podemos implementar um setter qualquer de uma property, por exemplo, vamos alterar o setter da property numeroDaConta:


class Conta {
    var numeroDaConta: Int = 0
    set(value) {
        println("Recebendo valor na property numeroDaConta")
        numeroDaConta = value
    }
    var titular: String = ""
    var saldo: Double = 0.0
}

Veja que foi adicionada a keyword set logo abaixo da property numeroDaConta. Dentro do set estamos fazendo um print indicando recebemos um valor na property. Vamos testar?

Isso mesmo, tomamos um StackOverFlowError por realizar uma operação sem fim! Em outras palavras, fizemos um setter que fica chamando ele mesmo, ou melhor, um setter recursivo!

Mudando o valor de uma property diretamente

Para evitar esse tipo de situação, isto é, caso seja necessário modificar o próprio campo de uma property dentro do seu setter, o Kotlin oferece um recurso conhecido como Backing Fields. Basicamente, usamos a keyword field e temos acesso direto ao atributo:


class Conta {
    var numeroDaConta: Int = 0
    set(value) {
        println("Recebendo valor na property numeroDaConta")
        field = value
    }
    var titular: String = ""
    var saldo: Double = 0.0
}

Testando novamente percebemos que a mensagem “Recebendo valor na property numeroDaConta” é apresentada apenas uma única vez, e se imprimirmos a property:


println(conta.numeroDaConta)

Apenas o valor dela é apresentado!

Para saber mais

Por mais que tenhamos visto bastante das peculiaridades do Kotlin, ainda é só o começo, isto é, existem diversas outras features interessantes da linguagem para colocarmos na balança se é algo que vale a pena investir o tempo de estudo ou não, veja alguma delas:

Claro, além delas também existe o caso da interoperabilidade que existe entre o código Kotlin e Java que de fato é um dos grandes destaques de usar o Kotlin no ambiente Java, ou seja, chamar classes do Java dentro do código Kotlin como chamar classes do Kotlin no Java.

Kotlin no Android

Um outro detalhe importante é que cada vez mais o Kotlin está sendo adotado pela comunidade Android em novos projetos. Pensando justamente em ajudá-lo a começar seus projetos Android com Kotlin, deixo aqui esse artigo que mostra como podemos criar Apps Android com Kotlin.

Conclusão

Como vimos, o Kotlin vem com a proposta de tentar simplificar o máximo possível o nosso código, isto é, evitando os famosos boilerplates no código. Também, a ideia da linguagem é tentar aplicar muitas das boas práticas de programação existentes em outras linguagens, como é caso do Swift, C# entre outras. De modo geral aprendemos os seguintes tópicos:

  • Criação da função main
  • Declaração de variáveis e seus tipos
  • Criação de classes e objetos
  • Utilização e acesso direto de properties

Agora que teve esse primeiro contato com o Kotlin, aproveite e deixe o seu comentário sobre o que achou da linguagem 🙂

20 Comentários

  1. Alvaro 23/08/2017 at 09:36 #

    Muito bom!

    Estou no fritando o F5 na alura para o treinamento de Kotlin 😉

  2. Felipe Melo 23/08/2017 at 13:49 #

    Excelente o post!
    Para quem não possui nenhuma experiência com a linguagem, de fato é uma ótima leitura e uma ótima oportunidade de ter o primeiro contato. Este é o meu caso. Ainda consegui tempo para fazer um “Hello world!” da vida, apesar de estar nos planos. Com certeza o conteúdo acima ajudou a compreender melhor a respeito.
    E minha primeira impressão é o que todos falam: “Escreve-se pouco para obter-se muito!”.
    Sou programador Java e sei o que é trabalhar com uma linguagem verbosa.

    Obrigado por colaborar com a comunidade, Alex.

  3. Joao Paulo Sossoloti 23/08/2017 at 15:24 #

    Muito maneiro as comparativas, ficou bem claro o entendimento. Parabens!

  4. Alex Felipe 23/08/2017 at 19:47 #

    Opa Alvaro, o curso de Kotlin está nos nossos planos! Fique de olho que logo mais teremos mais novidades 🙂

    Muito obrigado pelo feedback. Abraço!

  5. Alex Felipe 23/08/2017 at 19:49 #

    Que bom que gostou Felipe! Fico muito contente que o conteúdo foi de grande ajuda nesse primeiro contato com a linguagem 🙂

    Com certeza, da mesma forma que aprendemos é sempre importante colaborarmos também hehe

    []s

  6. Alex Felipe 23/08/2017 at 19:50 #

    Obrigado pelo feedback João! Fico contente que tenha gostado.

    []s

  7. Levi Saturnino 27/08/2017 at 23:57 #

    Legal, quanto mais kotlin melhor. Leitura claro e objetiva. Valeu!

  8. Alex Felipe 28/08/2017 at 10:07 #

    Opa Levi, vlw pelo feedback 🙂

  9. Rodrigo Ribeiro 29/08/2017 at 18:19 #

    Até o momento tive pouco contato com Kotlin, mas pelos seus exemplos, me parece que a simplicidade do código vem acompanhada de alguns pontos negativos:
    1) Functions serem públicas por padrão: Isso acarreta em maior acoplamento entre as classes já que você permite que todas as funções sejam acessadas por qualquer cliente. Provavelmente existam mecanismos para se restringir o acesso, porém para o programador pouco experiente, este comportamento padrão é prejudicial.
    2) Setters/Getters implícitos: O problema aqui é o baixo encapsulamento oferecido, já que por padrão, pode-se se acessar componentes internos das classes. Para criar classes imutáveis eu preciso então aumentar a verbosidade do meu código?

    Preciso me aprofundar mais para ver as vantagens de se utilizar Kotlin ao invés de Java quando executando na JVM. Talvez o transpiling para Javascript seja uma feature interessante, porém ainda vou esperar pra ver se isso não é mais um hype que vai falhar pra emplacar.

  10. Alex Felipe 29/08/2017 at 19:09 #

    Oi Rodrigo, tudo bem?

    Você acabou levantando pontos importantes, sobre a modificação de acesso, temos todos os outros que vemos no Java (com exceção do default), com a inclusão do internal que deixa visível apenas para o módulo.

    Considerando o que vemos no default do Java, ainda sim é possível acessar em outras classes do mesmo pacote, ou seja, algo que é arriscado também. Em outras palavras, é muito comum o programador já aprender logo cedo que se ele quer restringir algo, ele precisa deixar como private ou indicar um modificador de acesso em específico e, é muito comum criarmos métodos (no caso do Kotlin funções) que o acesso vai ser para outras entidades do sistema, portanto, não vejo como um problema tudo ser public por padrão.

    Sobre a parte de Setters/Getters implícitos: é bem comum criarmos POJOs dentro do Java, no qual exige uma quantia de código que parece repetitivo, ou seja, apenas altera ou devolve o valor, logo, fazer com que isso seja implícito acaba sendo vantajoso, justamente para que o programador, não tenha que ficar com boilerplates que algumas vezes mais polui o código do que acrescenta em alguma parte do projeto em si. E é importante se atentar que não acessamos nenhum componente interno por padrão, acessamos properties, que na verdade são os seus métodos de acesso apenas. Caso isso não seja desejado, basta apenas indicar que a sua property é privada que ninguém, a não ser a sua classe, vai saber da existência dela, ou até mesmo, você pode deixar um set ou get privado sem nenhum problema 🙂

    Sobre classes imutáveis: No Kotlin todas são imutáveis por padrão, ou seja, para você fazer herança, você precisa ‘abrir a classe’.

    Lembre-se o post é bem introdutório, logo, para quem nunca nem ouviu falar do que é o Kotlin, em outras palavras, existem muitas features mais robustas que vale a pena dar uma estudada

  11. Felipe Melo 31/08/2017 at 14:42 #

    Excelente, Alex. Resposta bem esclarecedora!

  12. Rodrigo Ribeiro 31/08/2017 at 17:53 #

    Quando falei classes imutáveis, na verdade estava me referindo a objetos imutáveis, objetos que uma vez instanciados não podem ter suas propriedades alteradas. O código que você postou por exemplo:

    class Conta {
    var numeroDaConta: Int = 0
    var titular: String = “”
    var saldo: Double = 0.0
    }

    Por padrão, sem declarar nada, tenho métodos para alterar os atributos e deixar meu objeto em um estado inconsistente. O exemplo acima em Java seria:

    class Conta {
    public Integer numeroDaConta;
    public String titular;
    public Double saldo;
    }

    A mesma classe implementada de maneira imutável seria:

    class Conta {
    private final Integer numeroDaConta;
    private final String titular;
    private final Double saldo;
    public Conta(Integer numeroDaConta, String titular, Double saldo) {
    this.numeroDaConta = numeroDaConta;
    this.titular = titular;
    this.saldo = saldo;
    }

    // public Integer getNumeroConta()
    // public String getTitular()
    // public Double getSaldo()
    }

  13. Alex Felipe 31/08/2017 at 18:08 #

    Oi Rodrigo, no caso o que você está indicando são constantes, ou seja, o mesmo resultado que temos quando indicamos variáveis ou proprerties com a keyword val. Para atender exatamente o seu exemplo, aí podemos usar os construtores do Kotlin (um assunto que não abordei no post, mas deixo a referência), no caso com o construtor primário:

    
    class Conta(numeroDaConta: Int,
                titular: String,
                saldo: Double){
        val numeroDaconta = numeroDaConta
        val titular = titular
        val saldo = saldo
    }
    

    Podemos reduzir mais:

    
    class Conta(val numeroDaConta: Int,
                val titular: String,
                val saldo: Double)
    

    Neste último caso, ao mesmo tempo que exigimos os valores via construtor, também, declaramos nossas properties, nesse caso, properties read-only por causa do val

    []s

  14. Rodrigo Ribeiro 31/08/2017 at 19:29 #

    Pelo que andei lendo val não significa realmente imutável. Observe o exemplo abaixo, a val number muda a cada leitura:

    import java.util.Random

    class Mutable() {
    val number: Int
    get() = Random().nextInt()

    fun print() {
    println(“number: ${number}”);
    val changedNumber = this.number;
    println(“changedNumber: ${changedNumber}”);
    }
    }

    fun main(args: Array) {
    Mutable().print()
    }

  15. Ciço 01/09/2017 at 07:09 #

    Não existe imutabilidade forçada diretamente na linguagem, o que você pode utilizar são as ‘Data Classes’ para facilitar a criação de classes imutáveis (https://kotlinlang.org/docs/reference/data-classes.html).

    Utilizando o ‘val’ para as declarações e através do método ‘copy’ você garante a imutabilidade (claro, sempre considerando que não referencie uma classe mutável).

  16. Alex Felipe 01/09/2017 at 13:35 #

    Oi Rodrigo,

    Nesse ponto que você levantou entra em uma característica própria de properties, ou seja, você está modificando o retorno dela e, justamente por esse motivo você já não consegue usá-la mais como um ‘atributo’ da classe… Por exemplo:

    
    class Mutable() {
        val number: Int = 1
            get() = Random().nextInt()
    } 
    

    Essa inicialização da um problema de compilação, pois a property não possui mais o backing field para atribuir valor a ela, em outras palavras, ela acaba tendo o mesmo comportamento de uma função que apenas retorna esse valor declarado.

    Sendo mais específico, para o caso do val em properties, quando você modificou o retorno do val number: Int ele já não possui mais o backing field que é justamente o valor da property em si.

    Inclusive, a própria linguagem utiliza esse mecanismo em suas collections, ou seja, o famoso método size() na verdade é uma property val que precisa implementar o seu retorno, justamente por causa da implementação do get() que por sua vez, vai ser devolver o valor do tamanho da lista, mas, não permite que alguém de fora altere o valor, portanto, é imutável.

    Considerando o problema de compilação apresentado acima, uma maneira de fazer compilar, seria voltando ao estado no qual o backing field ainda é acessível, por exemplo:

    
    class Mutable {
        val number: Int = 1
            get() = field
    }
    

    Veja que dessa maneira o código compila, pois retornamos o próprio valor da property, ou seja, ele volta a ser acessível. Internamente, isso é o esperado quando usamos uma property pela qual inicializamos ela…

    Resumindo

    O val ainda continua sendo imutável sim, se alguém tentar mudar o valor dele, não vai rolar. O que acontece no caso é que apenas você deixou de usar uma property no estilo de atributo, e passou a usar como uma função. Inclusive a própria IDE apresenta uma sugestão de modificação deste trecho:

    
    class Mutable {
        fun number() = Random().nextInt()
    }
    

    Para property que apenas retorne o valor:

    
    class Mutable {
        val number get() = Random().nextInt()
    }
    

    Ambos os códigos são ‘equivalentes’ a diferença é que um você chama como uma property e o outro você chama como uma função.

    Observações

    Claro, isso pode ser problemático pois um programador inexperiente pode causar problemas caso modifique o retorno de uma property de maneira inapropriada.

    Opa Ciço, blz?

    Faz todo sentido utilizar uma data class para evitar esse detalhe da implementação de um get() numa property, entretanto, quando utilizamos uma data class ganhamos algumas coisas a mais que é importante saber, como é o caso do método toString(), equals(), hashcode() e o copy() já implementados.

    E também, perde algumas coisas, como não ser abstrata, sempre vai ser uma classe final (não pode ser herdada) entre outros pontos apontados na documentação.

    Mas é bem válido utilizá-la pra isso 🙂

    []s

  17. Diogo 05/09/2017 at 10:24 #

    Muito bom o conteúdo do site

  18. Diego 07/09/2017 at 02:17 #

    Estamos começado a conhecer o Kotlin e a linguagem já aparente ser bem mais evoluida que a linguagem Java (claro Java tem seus motivos para não evoluir mais rápido).
    Pensando em ambiente mobile, Kotlin veio para substituir o Java, mesmo que não seja do dia pra noite, algo como ocorreu com Swift e Objective-C?

  19. Alex Felipe 08/09/2017 at 09:04 #

    Oi Diego, essa é uma ótima pergunta!

    Muitas pessoas acabam entrando nessa discussão e alguns acreditam que sim, como também, outros acreditam que não…

    No meu ponto de vista, acredito que o Kotlin não substitua o Java, justamente porque a maioria dos projetos atualmente foram desenvolvidos em Java, ou seja, dificilmente as empresas irão migrar um projeto que já funciona e que o time já esteja à vontade… Por mais que a mudança seja fácil por conta da interoperabilidade, trata-se de um custo alto de modo geral.

    Inclusive, o Pinterest foi uma das empresas que adotaram o Kotlin e compartilharam os problemas que eles tiveram nessa transição, aproveito para deixar o artigo

    Mas é importante saber que daqui pra frente surgirão cada vez mais projetos Android usando Kotlin, pois com esse suporte da Google junto da facilidade e evolução da linguagem, muitos programadores e times com certeza irão apostar nessa linguagem.

    Se pensarmos em novos projetos, pode ser que o Kotlin comece a dominar mais em projetos Java, mas a total substituição é improvável…

    Resumindo: Essa é uma pergunta que não tem uma resposta correta, é tudo uma questão de analise ou crença baseando-se em fatos.

    []s

Deixe uma resposta