• classes e interfaces
• propriedades e construtores não triviais
• classes de dados
• delegação de classe
• uso da palavar resevada object

• Interfaces se definem igual java (bloco1.exemplo1)
• Os dois pontos (:) servem para substituir o extends e implements (bloco1.exemplo1)
• Quando uma classe implementa uma interface, ou extendem de uma classe abstrada, todos os seus métodos devem obrigatóriamente conter a palavra reserda override, sendo uma implementação obrigatória ou sobreescrita (bloco1.exemplo2)
• Implementação concreta de métodos na interface não precisa da palavra default na frente
• Multiplas interfaces com assinaturas iguais para uma classe, requerem que seja definido qual ou quais os métodos super serão chamados. É obrigatório sobreescrever com uma das opções abaixo:
  • Sobreescrever o método e chamar um dos metodos super
  • Sobreescrever o método e chamar os 2 metodos super
  • Sobreescrever o método e não chamar nenhum dos super (bloco1.exemplo3)

É possível fazer lógica dentro de expressões String (bloco1.bonus1)

Todas as classes são fechadas por padrão. O motivador de tudo isso vem do livro Effective Java de Joshua Bloch (Addison-Wesley, 2008) Onde ele diz: “faça um design e o documente visando à herança, ou a proíba”. Em outras palavras, classes não preparadas para herança podem tornar o sistema frágil (bloco2.exemplo1)

• Tanto classes como funções podem conter open para definir se podem ou não serem sobreescritos (bloco2.exemplo2)
• Sobreescrita de métodos de classes abstratas também é obrigatorio colocar o override (bloco2.exemplo2)
• É possível bloquear sobreescrita em cascata em algum ponto (bloco2.exemplo3)
• Classes abstratas e interfaces são open por padrão, não podem ser final (bloco2.exemplo3)

• Os modificadores de acesso seguem quase o mesmo padrão que java, a diferença se da no protected. Em java protected é para nível de pacote, no Kotlin protected é somente para herança. Nisso surgiu um novo modicador, internal que da acesso a nível de pacote. Uma forma interessante de isolar classes que não devem ser acessadas de fora dos módulos. (bloco3.exemplo1) OBS: Infelizmente, o modificador internal no kotlin se torna public quando acessado via java
• No caso de Herança de internal, todas as classes que extendem devem manter internal (bloco3.exemplo1)
• Classes internas não tem acesso a instância interna, para tal é necessário colocar a palavra inner (bloco3.exemplo2)

• Classes seladas é uma forma de fazer uma hierárquia de classes restrita. Classes seladas e suas implementações devem ficar no mesmo arquivo. Útil para operações matemáticas, máquinas de estados, programação funcional (bloco4.exemplo1)
• No caso de utilizar o comando when, todas as subclasses sealed deverão ser tratadas

• Construtores primários podem ser escritos de diversas formas (bloco5.exemplo1)
• Construtores podem ter valores default, e quando todos os atritubos tiverem valor default, um constutor vazio é adicionado como opção (bloco5.exemplo2)
• Classes superiores devem ser invocadas no construtor da classe herdada, mesmo que não haja parâmetros (bloco5.exemplo3)
• Podem existir Construtores secundários, e no caso de herança eles devem chamar o construtor correspondente da super classe (bloco5.exemplo4)

• Interfaces podem definir propriedades que as classes que concretas devem oferecer, ela não especifíca como vai ser implementada, seja uma propriedade backing field, uma propriedade calculada (bloco6.exemplo1)
• É possível colocar private em metodo set de uma propriedade var (bloco6.exemplo2)

• É possível verificar a igualdade entre objetos com dois iguais == Ele gera uma chamada interna dos métodos equals, para verificar a instância usa-se os três iguais === (bloco7.exemplo1)
• Data Class gera automaticamente os metodos: hashCode, equals, toString e copy
• Copy é utilizado pra clonar objetos e poder alterar apenas as propriedades desejadas. A ideia é que os objetos sejam imutáveis e seja criada uma cópia pra alterar apenas os dados necessários (bloco7.exemplo2)

• A palavra reservada object define uma classe e cria uma instância ao mesmo tempo. São 3 os tipos:
  • Singletons
  • Companion objects, em java o equivalente são os métodos, variáveis e blocos static das classes, podem ser usadas para fábrica de objetos
  • Expressões ou classes anônimas
• Object:
  • Não permite instância. Não permite nenhum tipo de construtor. (bloco8.exemplo1)
  • Podem extender de classes e interfaces (bloco8.exemplo2)
• Companion Object
  • Kotlin não existe static, para tal existem as funções de pacote e os objetos companion que vem pra substituir. Eles tem acesso aos membros private da classe, diferente das funções de nível superior. (bloco8.exemplo3)
  • Companion objects podem ser usados para fábricas de objetos, onde se define um construtor privado e um método que instancia da melhor forma (bloco8.exemplo4)
  • Companion objects podem implementar interfaces (bloco8.exemplo5)
  • Companion objects também podem ser extendidos (bloco8.exemplo6)
  • Objects também servem Classes anônimas ou expressões (lambdas)

• Alguns design de projetos para resolver herança são resolvidos pelo uso de delegates, o que na prática pode ficar muito verboso (bloco9.exemplo1)
• A solução é delegar para o objeto específico, internamente uma chamada igual é chamada, isso apenas deixa o código menos verboso

• Kotlin traz vários padrões de projeto de forma nativa e organizada
• Herança só é permitida se você quiser e terá que pensar como isso pode ser feito
• A parte de visibilidade traz uma certa correção no caso do protected e internal
• Objetos imutáveis garantem um pouco mais de segurança para não causar efeitos colaterais
• Companion objects separam muito bem metodos de classes de metodos de objeto
• Selead classes traz mais restrição para trabalhar com classes mais avançadas do que enums