Alura > Cursos de Programação > Cursos de Kotlin > Conteúdos de Kotlin > Primeiras aulas do curso Kotlin: recursos da linguagem com pacotes e composição

Kotlin: recursos da linguagem com pacotes e composição

Utilizando pacotes no código - Introdução

Opa, pessoal! Beleza? Eu sou o Alex Felipe, instrutor aqui da Alura. Vou apresentar para vocês o curso de Kotlin, sobre pacotes, composição e recursos da linguagem.

Para esse curso, eu vou assumir que você já tenha um pré-requisito, que foi visto no curso anterior, que seria sobre o assunto de herança, polimorfismo e interfaces. Porque, dado que você já tem esse conhecimento, nós vamos avançar aqui no nosso projeto para aprendermos as novas técnicas e os novos recursos disponíveis aqui na linguagem.

Dado que agora eu passei o feedback sobre os pré-requisitos, nós vamos saber o que vamos aprender durante o curso. Então, vamos começar! Então, uma das primeiras coisas que nós vamos ver aqui no nosso projeto é que existe a necessidade de organizarmos o nosso código.

Porque no momento em que estamos aprendendo a escrever os nossos primeiros códigos, nós não nos preocupamos tanto nessa parte de organização, que aqui dentro do Kotlin também é chamado de organização por pacotes.

Então estamos vendo aqui esse pacotinho, que é um diretório também, ele tem uma determinada regra. Então vamos aprender o que significam essas regras, como podemos criar esses diretórios e também a mandarmos aqui os nossos códigos. Isso, de tal maneira que consigamos fazer a compilação sem nenhum tipo de problema.

Então vai ser nesse momento que nós vamos focar nesse assunto e vamos lá falar a respeito de como que podemos usar aqui toda essa técnica, toda essa organização e fazer com que tudo funcione sem nenhum problema. Então esse vai ser o primeiro ponto. Logo a seguir, vamos trabalhar em mais um recurso da orientação aos objetos, que é bastante comum. Além da herança, do polimorfismo e das interfaces, que também são chamados de composição.

O que seria, basicamente, essa composição? Só para que você também tenha um pouquinho do spoiler, a composição é uma técnica na qual nós conseguimos fazer com que uma classe mantenha aqui a referência de uma outra. Ou melhor, ela consiga ter uma “property” que vai conseguir apontar para um objeto.

Então, além de trabalhar com aqueles tipos primitivos - que é o caso do “int”, é o caso do “double” e até mesmo a “string”. Vamos chamar assim... Vamos perceber que temos a capacidade de trabalhar com os nossos objetos. Então como podemos ver, a conta agora tem ali uma variável, que é de um tipo, que é o nosso “Cliente” - que é justamente aqui a nossa classe, que vai manter as informações do cliente.

O “Cliente”, por sua vez, também vai ter um endereço, como podemos ver aqui. Nós já estamos vendo um spoiler de quais serão os exemplos, só que vamos entender as situações nas quais esses exemplos que eu estou mostrando para vocês fazem sentido. Quando podemos considerar a composição e quando, às vezes, talvez não faça sentido utilizarmos. Então vamos aprender isso aí também.

Legal! Depois da composição, o que vamos ver? Vamos ver também como é possível armazenarmos valores aqui, dentro das nossas classes, de tal forma que os objetos não interfiram.

Por exemplo: vamos pegar aqui a nossa conta e vamos perceber que existe uma possibilidade na qual conseguimos armazenar aqui os nossos valores, de tal forma que independentemente da quantidade de objetos que criarmos, vamos conseguir manter o mesmo valor.

Porque, como nós vimos, dado que um objeto é novo, ele mantém os novos valores para ele. Mas vamos ver que vai existir uma técnica que vai compartilhar o mesmo valor para todos os objetos de maneira independente. Nós vamos aprender isso.

Também vamos ver como podemos fazer execuções durante a construção do nosso objeto sem utilizarmos o construtor. Vamos ver ali alguns recursos que são bastante comuns aqui no Kotlin e que podemos utilizar em diferentes contextos.

Depois que vermos sobre essas partes, vamos aprender também algumas coisas básicas aqui da linguagem, que é justamente entendermos como que a linguagem funciona em relação à sua estrutura, que vamos aprender que existe ali uma classe que seria a básica de todas. Também vamos conhecer os seus determinados comportamentos, que são os comportamentos disponíveis para qualquer classe.

Isso, considerando ali as suas importâncias, o porquê que existem esses métodos e como podemos usar ao nosso favor. Então, veja que é realmente um curso que vai avançar um pouquinho mais do que nós vimos anteriormente e focar um pouquinho mais também aqui na linguagem do Kotlin.

Eu espero que você esteja animado. Vamos começar! Vamos lá?

Utilizando pacotes no código - Organizando o projeto em pacotes

Antes de criarmos novos códigos, como também resolvermos novos problemas, é muito importante também analisarmos o nosso projeto da maneira como ele está hoje - isso relacionado à organização de arquivos.

Por que eu falo isso? Porque perceba que hoje temos o nosso sistema da Bytebank que faz diversas funcionalidades, só que cada vez mais, ele vai crescendo em número de arquivos, correto?

Então hoje temos várias classes, temos interface, temos aqui arquivos de funções. Só que cada vez mais vai ser comum criarmos novos arquivos. E qual é o grande problema que temos, só pensando nessa ideia que vamos crescer em arquivos? É justamente a questão da organização, cada vez vai ficar mais difícil de lidarmos aqui com o nosso projeto.

Pensando nisso, agora vamos focar em uma técnica na qual vai resolver esse problema, ou melhor, ela vai melhorar a nossa experiência. Justamente para organizar aqui os nossos arquivos. Vai ser exatamente isso que vamos ver. Isso, considerando as regras que temos em um projeto em Kotlin. Então, vamos começar! Como podemos fazer então, para começarmos essa organização?

Perceba que atualmente estamos deixando todos os nossos códigos dentro deste diretório, que é o “src”, que é justamente de “source”. Só que nós também temos a capacidade de criarmos novos diretórios, que vão ficar dentro aqui do “source”.

E nesses novos diretórios, temos a capacidade de mover aqui os nossos arquivos, para que dessa maneira, nós representemos com mais amplitude, de uma maneira mais genérica o que cada um desses arquivos nos representa.

Como, por exemplo: perceba que temos diversas classes e interfaces aqui, que vão representar a nossa regra de negócio, certo? Elas seriam ali o que chamamos de “modelo dentro de projetos assim, no Kotlin. Portanto, pessoal, dado que elas representam aqui o nosso modelo, uma das técnicas que nós podemos estar fazendo aqui inicialmente é criarmos um diretório que vai ter esse nome.

E dentro desse diretório, colocamos todos esses arquivos que escrevemos nosso código de regras de negócio, porque eles representam o nosso modelo. Então, vamos começar!

Como podemos fazer isso aqui, no IntelliJ? Basicamente, pessoal, vamos usar as teclas “Alt + Insert” e aqui vamos ter uma opção chamada de “Package”. Essa opção significa “pacote”, porque é um recurso bastante comum em projetos em Kotlin.

Então quando nós vamos criar aqui um diretório para colocarmos dentro do nosso “source”, vamos estar criando um pacote. Então, agora vamos escolher aqui a opção do “Package”. Aqui, pessoal, vamos dar o nome do nosso modelo. Então podemos escrever aqui: “modelo” ou então “modelos”, você pode escolher da maneira que você preferir, não é restrito.

Se você preferir o singular, mantenha os demais arquivos também que você criar no singular. Se for no plural, tente ir pelo plural. Nesse caso aqui, eu estou indo pelo singular. Então, agora que temos o nosso modelo, o que podemos fazer para organizar? Basicamente, podemos tentar mover aqui um desses arquivos para o nosso modelo. Vamos ver o que acontece ao tentarmos fazer isso. Então, vamos lá!

Ao jogar aqui o “Analista” para “modelo”, olhe só o que acontece. O IntelliJ já abre aqui uma janelinha, falando que vai fazer a ação de mover, que é esse “Move” que estamos vendo aqui. Então ele indica quem está sendo modificado, ou melhor, está sendo movido. Modificado é muito forte nesse caso. No caso, “movido”, que é justamente a nossa classe “Funcionario”.

E aqui, o que acontece? Ele vai indicar que ele vai mover para um pacote, justamente porque é comum essa nomenclatura de pacote, ao invés de diretório, que é justamente o nosso “modelo”. Aqui poderíamos selecionar outros pacotes, caso existissem, mas nesse caso só temos um modelo. Aqui embaixo vai falando qual vai ser o nome do arquivo. Aqui já temos o nome do arquivo. Então, tudo tranquilo!

Ele vai falando, ele vai indicando também se vai fazer o update ali do diretório, porque têm algumas atualizações que vamos ver aos poucos. Aqui ele vai indicando outras opções, que não precisamos dar tanta atenção.

Porque faz parte de algumas otimizações aqui do IntelliJ, para acharmos referências e para podermos fazer todos os ajustes, para que o nosso código compile sem nenhum problema durante essa etapa de mover arquivos.

E por fim pessoal, vamos ter aqui esse botão de ““Refactor””, que seria meio que o “OK”. O que ele significa? O ““Refactor””, na nossa tradução, significa “refatoração”, ou “refatorar”, e é justamente uma técnica na qual conseguimos modificar o nosso código, considerando boas práticas de programação e mantendo o mesmo funcionamento de anteriormente.

Então nós modificamos um código mantendo a mesma funcionalidade que estava implementada desde o começo da nossa primeira implementação, só que com melhor qualidade, com boas práticas.

Então é por isso que temos esse tal do “Refactor”. Então vamos clicar aqui nesse “Refactor” e vamos ver o que acontece. Olhe só, clicamos no “Refactor”, o IntelliJ fez ali um “load”, vocês viram?

E agora, olhe só o que aconteceu. O “Analista” não aparece mais no nosso “src”, mas aqui, nessa flechinha do modelo. Ele já está aqui dentro. Agora vamos clicar nele e vamos ver o que acontece. Clicando aqui no “Analista”, perceba que ele já não tem mais o código aqui da nossa classe “Analista”.

O que aconteceu aqui de diferente, pessoal? Perceba que agora temos essa nomenclatura, essa palavra chave aqui, que é o “package”, que está com o nome “modelo”; e temos esse “import” aqui, que está com o nome “Funcionario”, que é da nossa classe “Funcionario”. O que aconteceu nesse momento?

Dado que agora estamos trabalhando com essa subdivisão de diretórios, que seria o nosso “source” e agora temos aqui um modelo, nós também precisamos declarar qual é o pacote aqui da nossa classe. Então perceba que no momento que você criar um pacotinho, que é justamente qualquer diretório que está dentro aqui do nosso “source”, ele terá essa nomenclatura de pacote.

Então, no caso do nosso modelo, nós colocamos o pacote modelo, “package modelo”. Se fosse qualquer outro nome, você também colocaria aqui o nome que você teria dado, junto do local onde está o arquivo. Então aqui, no caso “Analista” está dentro do diretório “modelo”, aqui o pacote vai ser “modelo”. E agora, o que é esse tal do “import”?

O “import” vai ser uma técnica na qual vamos conseguir buscar um arquivo que não está dentro do mesmo pacote, como nós estamos vendo aqui. Então perceba que o “Funcionario” é necessário para o “Analista”, só que ele não está no pacote modelo, ele está no nosso pacote padrão. Nós vamos chamar assim, que é do nosso “source”, que é o “src”.

E dado que é o padrão, que não tem ali uma nomenclatura, ele vem com esse nominho apenas de “Funcionario”. Se ele estivesse dentro aqui do “modelo” nós não teríamos esse problema, ele não precisaria fazer esse “import”. Vamos tentar ver como que fica? Vamos lá! Então, agora que tivemos esse feedback mínimo, vamos tentar mover o “Funcionario”.

Então eu vou tentar mover o “Funcionario” para cá e nós vamos ver o que acontece. Aqui, as opções serão as mesmas, não precisamos mexer em alguma opção, já vimos como funciona aqui no pacote “modelo”. Vamos dar o “Refactor”. Olhe só, ele já não precisa mais ali do “import”, assim como vimos anteriormente.

Então, perceba que quando estamos dentro do mesmo pacote, como sempre estivemos, não precisamos fazer esses “imports”, porque realmente conseguimos acessar diretamente. Só que agora vai ter aqui o nosso “Funcionario”, que também está dentro do pacote “modelo”.

E agora vão vir algumas diferenças, que são as seguintes: veja que aqui temos um “Funcionario” que está dentro do modelo e, da mesma maneira como o “Analista” precisou do “Funcionario” quando ele não estava no pacote “modelo”; se pegarmos, por exemplo, o “Auxiliar”, vamos ver que agora precisamos fazer esse “import” também.

Então veja, pessoal, que agora o “import”, olhe só como é que ele funciona: ele coloca aqui o pacote que estamos colocando lá para o nosso “Funcionario”. Em seguida, ele coloca o ponto e o nome da nossa classe. O que isso significa para nós? Isso daqui, além de ser o caminho onde está o nosso arquivo, agora também representa o nome completo aqui da nossa classe.

Inclusive, tem até um termo técnico que o pessoal chama, que é o tal do “fully qualified name”, que seria o nome completo aqui da nossa classe. “Como assim, Alex!? O nome completo?” Veja que fazemos o “import” aqui porque, quando fizemos o “Refactor”, ele tentou deixar as boas práticas de programação. Mas não necessariamente precisamos fazer esse “import” para chamarmos aqui o nosso “Funcionario”.

Poderíamos chamar da seguinte maneira: podemos apertar as teclas “Ctrl + C” aqui no nome completo, que é o “fully qualified name” e aqui dentro, no momento que precisamos chamar essa classe, podemos colar essa referência inteira. Perceba que agora o “import” fica até cinza, falando que é desnecessário fazermos esse “import”.

Então se apagarmos o “import” aqui, ele funciona tranquilamente, porque agora, dado que estamos usando essa estrutura de pacotes - que é comum nos projetos em Kotlin - podemos chamar dessa maneira. Ou então, podemos fazer os “imports”, assim como o IntelliJ fez para nós. Isso considerando as boas práticas aqui dentro do Kotlin.

Então, agora que tivemos esse mínimo contato, vamos aproveitar, vamos migrar todos os nossos arquivos que representam o modelo para o nosso pacote “modelo”. Depois faremos para os arquivos que representam os testes.

E ainda, logo em seguida, vamos ter mais feedbacks do que precisamos saber em relação à essa parte de organização. Então vamos focar primeiro nisso e logo a seguir veremos mais detalhes.

Então, vamos lá! Voltando aqui, vou deixar como “import” mesmo. Teclas “Ctrl + Z” de novo. Se você quiser deixar esse termo técnico, fique à vontade. Eu vou apagar aqui porque não é tão necessário.

Agora vamos começar a mover todos esses arquivos. Então agora, no “Autenticavel” eu vou mover aqui, eu vou dar um “Refactor”. Você pode estar se perguntando: “poxa, Alex! Por que não tentamos mover tudo de uma vez?”

Vamos tentar e vamos ver o que acontece. Eu vou selecionar, por exemplo, o “Auxiliar” e a “CalculadoraBonificacao”. Se eu tentar fazer isso daqui, o IntelliJ não consegue fazer essa migração. Muito provavelmente, isso acontece porque eles não têm pacote atualmente, então talvez tenha alguns probleminhas.

Mais precisamente, eu não consigo passar essa informação porque ele não nos mostra muitas informações aqui. Mas é muito provável porque não tenha algum pacote e por isso ele acaba se perdendo.

Em outros casos, quando vamos migrar de um pacote para outro, às vezes funciona tranquilamente, então pode ser que não funcione esse exemplo, mas em algum outro momento você consiga fazer.

Vamos ver que nos arquivos de funções, isso vai ser possível, mas aqui nas nossas classes, nós não conseguimos. Então é por isso que vamos de um em um, infelizmente. É só esse primeiro momento, então não é algo tão doloroso assim...

Então eu estou movendo aqui, sem passar exatamente o feedback, porque não tem algo muito além. Assim que chegarmos nos arquivos de funções, vamos ver o que vamos fazer de diferente. Então eu estou agora na “Conta”, agora estou na “ContaCorrente”. Vamos migrar aqui - talvez eu soltei antes, então não podia. Agora sim! Sempre assim, está bem, pessoal?

Sempre solte exatamente aqui, no pacotinho, senão ele também não vai. Se você soltar aqui um pouquinho antes, pode ser que ele também não vá. Então aqui temos o “Diretor”.

Aqui ele já indica o seguinte: “olhe, se você mandar o ‘Diretor’ para o pacote, pode ser que você tenha problemas”. Não se assuste com essa parte! Você pode mandar aqui um “Continue” e se caso realmente tiver um problema, aí sim você vê uma análise, você vai até a classe na qual foi modificada e vê se apresenta alguma coisa.

Ele falou que poderia ter problema, não que necessariamente teria. Isso porque têm algumas referências que fazem parte aqui do “FuncionarioAdmin”, que ainda não está no pacote. Então, às vezes pode acontecer essas mensagens. Só dar o “Continue” e verificar se aconteceu alguma coisa. Se aconteceu, você verifique o erro e tente fazer o ajuste.

Agora temos o “FuncionarioAdmin” também. Já estamos quase acabando, eu prometo. Temos o “Gerente” e também temos aqui o nosso “SistemaInterno”. Também, o “Gerente “ viu ali que poderia ter algum problema.

A princípio, aqui podemos ver que não vai ter, ele só deu o alarme mesmo. Ele está falando aqui que o “import” já não é mais necessário, porque tinha sido feito antes. Nós vamos ver como que lidamos com esses casos com mais detalhes, depois.

E agora temos o “SistemaInterno” aqui também. Tranquilo! Então para as nossas classes de “modelo” - ou melhor, os arquivos, porque temos também interfaces - nós já conseguimos fazer a migração, o nosso código já está organizado.

Olhe só! Se olharmos o projeto, temos o “source”, temos o “modelo” e aqui temos todos os arquivos que nos representam o “modelo”, que são as classes, para ter ali a nossa regra de negócio que representa coisas da vida real. Assim como o analista, o funcionário, as contas e assim por diante.

Agora, pessoal, nós também precisamos migrar esses arquivos aqui de teste, porque eles também estão focados apenas em testar o nosso código. Para isso, podemos criar também um pacotinho.

Então, agora que sabemos que é um “package”, podemos até usar o “pa” aqui, que ele filtra para nós, “Package”. Então, vamos lá! Escrevemos um arquivo chamado de “teste”, que vai ser só arquivo de teste.

Aqui no “teste” nós podemos selecionar tudo e então podemos migrar. Tudo bem, pessoal? Nós damos um “Ok” e olhe só, ele consegue fazer tranquilamente! Então foi como eu comentei, já que ele não dava tanto feedback. Eu não consigo passar tanta precisão do motivo, mas muito provavelmente é porque as classes não tinham pacotes.

Então, agora que conseguimos fazer aqui essa migração, veja que agora sim, o nosso projeto já tem uma organização muito melhor, como tínhamos anteriormente. Se vermos um pouquinho aqui dos arquivos de “teste”, vamos ver agora que eles têm diversos “imports”. Por quê? Porque agora eles precisam de mais de uma classe. Essas mais de uma classe estão em diretórios diferentes, em pacotes diferentes.

Então, além de ter o “package teste”, vamos também ter os “imports”, justamente para pegarmos os códigos que existem ali, nos outros pacotes. Legal! Então agora que aprendemos a fazer essa migração, essa organização; nós vamos só executar aqui o nosso projeto com uma função que temos e vamos ver se ainda funciona.

Inclusive aqui, no nosso “main”, podemos deixar aqui no “source”. Não tem nenhum problema em deixar aqui ou em outro ponto do nosso projeto. Vemos que também estamos importando aqui a função. Então também conseguimos fazer “import” de funções aqui no Kotlin. Então vamos executar aqui e vamos ver o que acontece.

Então aqui temos o “testaAutenticacao()” e agora que mudamos aqui os pacotes, veja que ele até demora um pouquinho mais, porque ele está tentando indexar aqui os arquivos. Então veja que funciona tranquilamente. Se quisermos pegar algum outro “testa” alguma coisa... Vamos tentar! Ele vai ver que existem esses “testa” e vai falar: “olhe, existe esse daqui, mas para você usar, você precisa fazer o ‘import’!”

Então veja que ele até deixou esse “import” aqui, é até um pouquinho estranho. Vamos vai ver como que podemos resolver isso meio que “automaticamente” e vamos ver aqui o que acontece, fazendo agora esses novos testes. Nós vemos que o código ainda funciona tranquilamente.

A diferença é que utilizamos aqui essa organização por meio de pacotes ou diretórios e agora o nosso projeto está mais organizado. Também, aqui já atende um mínimo do que é esperado em projeto em Kotlin - que a seguir eu vou passar mais detalhes para que nós entendamos as motivações principais para considerarmos essa técnica.

Então, até já!

Utilizando pacotes no código - Pacotes e imports padrões

Agora que organizamos os nossos arquivos em pacotes, nós podemos partir para o próximo passo, que é realmente entendermos a verdadeira importância de utilizarmos pacotes aqui no nosso projeto, além dessa parte de organização.

É claro, antes mesmo de falarmos sobre esse assunto, é muito importante eu passar um feedback que eu fiquei de falar no vídeo anterior, que está relacionado justamente a esse “import” que está em cinza.

O que temos que ter de feedback sobre esses “imports” em cinza? Significa que não estamos utilizando esse “import”, ou seja, não precisamos manter o nosso código. Nós simplesmente podemos apagar sem nenhum problema. Então se você viu algum “import” que está ali em cinza, você pode apagar.

O outro ponto que também podemos observar é o seguinte: veja que hoje, nesse código que fizemos, nós só tínhamos apenas um único “import” que não estava sendo utilizado. Só que, conforme vamos desenvolvendo nosso código, vamos usando novas referências, novas classes e funções que vêm ali de outros destinos e de outros pacotes. Ou seja, naturalmente esse recurso de “import” vai crescendo.

Como, por exemplo: agora eu quero fazer uso aqui do “testa”, vamos pegar “testaFuncionarios()”. Olhe só, ele já vai adicionando aqui dois pacotes que não estão sendo utilizados. Em outras palavras, é muito complicado nós ficarmos olhando e removendo manualmente. Ou seja, para isso, vamos usar uma técnica na qual ele já vai fazer a limpeza para nós, que é chamada também de otimização de pacotes.

Aqui no IntelliJ já tem um atalho para isso, que é com as teclas “Ctrl + Alt + O”. Com as teclas “Ctrl + Alt + O”, ele vai tentar analisar todos os “imports” que estão dentro de uma classe, então, se acaso não estiver sendo utilizado, ele vai simplesmente remover. Assim como ele mostra aqui no balãozinho. Olhe, dois “imports” foram removidos.

Então no momento que você estava trabalhando com código, você mexeu com diversas referências, você olhou aqui em cima... “nossa! Eu tenho muitos “imports!” Teclas “Ctrl + Alt + O” e você tira todas as referências. Também, é claro, se você deixar, não é algo problemático assim, é mais questão de boa prática mesmo.

Agora que eu passei o feedback, nós vamos para o próximo passo, que é justamente a verdadeira motivação dos pacotes, ou então a grande importância por detrás. Para isso, eu vou considerar o uso da documentação, no qual eu tenho a página que mostra os principais pontos que nós precisamos saber em relação aos pacotes.

Então, sobre esse primeiro ponto aqui que fala sobre a ideia de que arquivos podem usar pacote, nós já aprendemos anteriormente, que é justamente a técnica de migrar para um subdiretório, que nele você pode ter classes, pode ter funções. Aqui vai estar indicando que o pacote vai ser declarado.

Como também o nome completo, depois que você me migra para um pacote, é justamente o nome do pacote seguindo ali do recurso que você está utilizando, seja função, seja “property”. Também pode ser ali uma classe. No caso, no momento que não for especificado, como fizemos desde o começo do curso anterior, que seria via “src”; temos aqui o pacote padrão, como eu havia comentado.

Então, desse feedback aqui não temos realmente algo novo, realmente foi o que aprendemos. O ponto que agora temos que observar é justamente sobre esse outro aqui, que é chamado de “Default Imports”, ou “imports padrões”. O que isso significa?

Significa o seguinte, pessoal: no momento que estamos trabalhando aqui com o Kotlin, muito provavelmente você deve ter notado que usamos aqui, por exemplo, referências que não temos no nosso código e em nenhum momento tivemos “import” para usarmos essas referências.

E isso daqui está relacionado justamente a esse “Default Imports”, que ele diz o seguinte: alguns pacotes que vêm do Kotlin, que vêm da biblioteca do Kotlin, eles já são importados, por padrão. Ou seja, já temos todos os “imports” já selecionados para usarmos as classes de todos esses arquivos aqui. Por que temos esses pacotes? Por que não outros? No que isso nos importa?

É pelo fato de que as classes que estão disponíveis aqui dentro desses pacotes são bem comuns, elas são bem comuns em diversos projetos. Então se você vai usar em outro projeto, muito provavelmente você vai usar uma “string”, você vai usar o “int”, o “double” e outras classes que nós vamos ver no decorrer dos cursos.

Então nesse curso, muito provavelmente, não vamos conseguir ver a gama de classes disponíveis. Mas percebemos, por exemplo, que quando clicamos nessa “kotlin.*” (o asterisco representa todas as classes que estão dentro desse pacote), nós notamos que temos diversas classes. Dentre elas, temos por exemplo o “Boolean”, que utilizamos aqui durante o curso para podermos fazer ali as expressões booleanas.

Como também vamos ter diversas outras classes aqui, que são comuns em diversos projetos. Dado que é comum em diversos projetos, esses são os pacotes considerados como padrões. Como podemos ver, esses pacotinhos aqui têm aqui como prefixo, que seria justamente a primeira palavra dentre eles, o “kotlin”. O que também precisamos notar quando temos esse prefixo “Kotlin”?

Que esses pacotes sempre serão do nosso SDK, da biblioteca ali do Kotlin. Por que isso também é importante? É importante sabermos porque aqui no Kotlin existe uma regra para pacotes, que é a seguinte: não podemos declarar um pacote que tenha o nome em Kotlin - isso em código Kotlin. Podemos até mesmo ver isso acontecendo, o problema disso, fazendo o seguinte teste: podemos criar aqui um pacote novo, chamado de “kotlin”.

E vamos perceber que o Kotlin não vai deixar que isso seja possível, caso criemos uma classe aqui dentro. Então, por exemplo: eu quero criar uma classe nova, só para poder testar mesmo, chamada de “Teste”. Então eu vou chamar aqui o “Teste”. Eu estou usando aqui o GitHub, por isso que ele está mandando aqui. Agora eu vou tentar usar aqui essa nossa “Teste”.

Então aqui no “main”, com as teclas “Ctrl + Shift + N” pressionadas no “main”, eu vou tentar usar o nosso “Teste”. Então aqui vai ter o “Teste”, olhe só que legal! Nós vamos tentar usar. No momento que eu tento executar, olhe só o que vai acontecer: ele vai tentar executar!

A princípio parece que não tem nenhum problema e nós começamos a ter diversos problemas, falando que o nome de Kotlin só vai vir aqui do que chamamos de “Kotlin Standard Library”, que seria a biblioteca padrão do Kotlin.

Então não conseguimos usar realmente pacotes que têm o nome “kotlin”. Então tome muito cuidado com isso! Às vezes você pode ter um problema no seu projeto porque você resolveu usar o pacote que tem ali o nome base em Kotlin. É claro, se você usasse como um subpacote de um outro, como por exemplo: vou criar um pacotinho chamado de - ou então vou até migrar esse “Teste”.

Olhe só, eu vou pegar esse pacote que temos aqui. Deixe-me minimizar. Vou migrar para o teste que nós criamos, “Teste”. Ele vai perguntar se queremos mover, nós queremos. Olhe só, nós movemos uma classe, então agora ele já teve ali um movimento de um pacote para o outro, não foi só a classe. Aqui temos o nome “teste.kotlin”.

Agora, se voltarmos aqui no nosso “main”, olhe só o que acontece: ele já vai modificar aqui o “import”, é claro. Agora, se tentarmos executar, ele já vai executar sem nenhum problema, porque o padrão não é o nome do Kotlin, assim como vimos aqui nos pacotes padrões.

Então é muito importante vocês notarem: pacotes padrões são as linhas classes, os recursos que já temos disponíveis da linguagem, porque são comuns em diversos projetos. Ao mesmo tempo, não podemos colocar o nome de um pacote nosso com prefixo “kotlin”, porque o Kotlin não permite. Então esse é o ponto importante.

Um outro fato aqui que podemos considerar é o seguinte: que além do Kotlin, também vão existir de outras plataformas, como é o caso aqui do nosso Java. Veja que temos aqui da JVM, que vem com o “java.lang.*”. Caso você já conheça o Java, muito provavelmente você sabe do que eu estou falando.

E aqui temos esse outro, que é o “kotlin.jvm.*”, que são também ali algumas referências do próprio Kotlin relacionados ao Java. Mais pela questão da interoperabilidade, que é um assunto um pouquinho mais avançado e que vamos falar em um outro curso.

Então agora que sabemos essa parte da JVM, também temos aqui do JavaScript. Então. se de repente você usar o Kotlin para o JavaScript, esse vai ser o “import” padrão, que vai ter ali os recursos padrões para você já utilizar. Aí você não precisa fazer nenhum tipo de “import”. Bacana?

Sobre o curso Kotlin: recursos da linguagem com pacotes e composição

O curso Kotlin: recursos da linguagem com pacotes e composição possui 181 minutos de vídeos, em um total de 46 atividades. Gostou? Conheça nossos outros cursos de Kotlin em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Kotlin acessando integralmente esse e outros cursos, comece hoje!

Plus

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$85
à vista R$1.020
Matricule-se

Pro

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$120
à vista R$1.440
Matricule-se
Conheça os Planos para Empresas

Acesso completo
durante 1 ano

Estude 24h/dia
onde e quando quiser

Novos cursos
todas as semanas