Twitch4k

Apenas algumas separações de código em métodos, isolando algumas responsabilidades como a criação do socket e das threads dos handlers

Também utilizado o método .also do kotlin, funciona igual o .apply porém sem a troca do contexto this, ou seja, o código dentro do bloco { }, tem referencia ao próprio objeto porém com "it", exemplo dos 2 usos no método da criação do socket...

// com o `apply`, dentro do bloco { }, o "this" é a referencia do próprio objeto (socket)
Socket().apply {  
   receiveBufferSize = 4096
}

// com o `also`, dentro do bloco { }, o "this" é a referência da classe que está executando o código (no caso o Twitch4k)
socket.also { 
   it.connect( ... )
}

TwitchHandler

Mesma alteração com relação ao uso do .also (e um toque pessoal usando when ao invés do if else) Um ponto diferenciado do .also com relação ao .apply é a possibilidade de "nomear" a referencia

// Sem nomear a referencia
MessageHandlerDiscovery().also {  it.onReceivedChatMessageListener = onReceivedChatMessageListener } 

// Nomeando a referencia
MessageHandlerDiscovery().also { discovery -> 
    discovery.onReceivedChatMessageListener = onReceivedChatMessageListener 
} 

MessageHandlerDiscovery

Apenas remoção do in ArrayOf(...) para os casos em que se testa apenas 1 string

Chat

Neste caso, como já temos de qual channel que veio a mensagem, já estou passando direto para o Chat, assim quem for implementar o bot não precisará passar o channel para o send(message: String)

Ficando a chamada ao chat desta maneira

chat.send("Hello World")

Sem a necessidade de fazer isto

chat.send(message.channel, "Hello World")

A não ser que você queira deixar aberto ao criador do BOT definir pra qual dos canais cadastrados ele queira mandar a mensagem, mesmo "divergindo" da origem

PrivateMessageHandler

Neste foi implementado a solução para o Chat descrito acima

OnReceivedChatMessageListener

Transformando a interface em uma Functional Interface Assim como no java tem a anotação @FunctionalInterface para as interfaces, no Kotlin tem a fun interface, o que isto quer dizer?

Garante que a interface terá apenas um método a ser implementado (abstrato) e isto permite a implementação da interface com lambda (sem a necessidade de criar uma classe para implementar o método, mas também não tira essa possibilidade)

Exemplo de mudança: Antes

    class BotMessageListener : OnReceivedChatMessageListener { 
    
        fun onReceived(message: ChatMessage, chat: Chat) { 
            if (message.text.startsWith("test")) {
                chat.send("Hello World")
            }
        }
        
    }
   
    fun main() {
        val t4k = Twitch4K(...)
        t4k.setOnReceivedChatMessageListener(BotMessageListener())
        t4k.start()
    }

Depois

    fun main() {
        val t4k = Twitch4K(...)
    
        t4k.setOnReceivedChatMessageListener { message, chat ->
            if (message.text.startsWith("test")) {
                chat.send("Hello World")
            }
        }

        t4k.start()
    }

A ideia neste PR é apenas dar sugestões de implementações:

TwitchHandler

Como são muitos os códigos que determinam o tipo de mensagem a ser tratada, deixar esta lógica dentro do TwitchHandler pode deixar esta classe muito extensa a longo prazo, visto que as comunicações ainda estão em desenvolvimento.

Uma ideia é criar algo similar a um "service discovery" ou "strategy pattern", é ondeo MessageHandler entra:

MessageHandler

Criei a interface MessageHandler que contém o "identificador" de cada handler (neste caso pode ser vários, caso um identificador pode ter muito a ver com outro, usei desta forma devido aos comandos numéricos

 "002", "003", "004", "353", "366", "372", "375", "376"

e também pelos comandos "USERSTATE" e "ROOMSTATE" que já estavam agrupados

AbstractMessageHandler

Criei este abstract pois notei que todos os handlers utilizam o mesmo logger com o mesmo ID, porém, pode-se remover este cara e criar um logger pra cada handler (seria mais facil pra identificar onde está o erro/info talvez)

MessageHandlerDiscovery

Cada Handler precisa implementar o "code" para o discovery conseguir identificar o handler E o método handle que será usado para executar o comando com o RawMessage

Dentro do discovery foi criada a instancia de TODOS os handlers e adicionado a uma lista, é essa lista que o discovery percorrerá buscando pelo "code" enviado pela Twitch e identificará como executar a mensagem RawMessage

RawMessage - Builder

Neste caso apenas usei a validação de NullPointer direto na criação do objeto, isto fará o mesmo que validar se o raw e command é nulo com if como estava anteriormente

RawMessage(
 raw = this.raw ?: throw NullPointerException("A propriedade raw não pode ser nula"),
 command = this.command ?: throw NullPointerException("A propriedade command não pode ser nula"),
 ...
)

RoomState

Foi criado uma extension function do Boolean pra transformar o bool em texto lido por humanos Boolean.toHumanReadable: reduzindo duplicação de código (mesmo if pra vários lugares)

E no isFollowersOnlyMode, fiz a conversão pra IntOrNull, uma forma talvez mais segura de validar se é followersOnly devido a flexibilidade do valor ser -1, 0, etc... "vai que vem um -2 aí, e nào ta tratado, ficaria como ativado"

Ainda sobre este cara, a lista de roomState está sendo criado direto no Handler de USERSTATE e ROOMSTATE, mas, se posteriormente esta lista for utilizada em outros comandos, talvez seja necessário voltar ele pro TwitchHandler e repassá-lo para os handlers necessários seja por construtor (navegando pelo discovery) ou por setter