Quais são os métodos e por que quase ninguém os explica direito
Quando você entra num projeto e vê aquele monte de código ou documentação técnica, a primeira coisa que todo mundo pergunta é quais sao os metodos que foram adotados. A resposta costuma ser um monte de siglas bonitas que não querem dizer nada pra quem tá do lado de fora. Vou direto ao ponto. Existem basicamente três abordagens que eu vejo sendo usadas no dia a dia: métodos estáticos, métodos de instância e métodos de classe. Parece simples demais, mas a forma como você escolhe entre eles define se seu código vai ser uma merda de manter ou algo que você até consegue ler depois de seis meses.
quais sao os metodos
Métodos estáticos são os mais fáceis de cair na malha fina. Eles não dependem do estado do objeto. Você chama `MetodoEstatico.fazer_algo()`, passa os parâmetros que quiser, e pronto. Não tem side effect escondido. O problema é que muita gente usa método estático pra tudo porque é rápido de escrever. Eu já vi código onde 80% dos métodos eram estáticos em classes que, no fundo, precisavam de estado. Resultado: você precisa passar o mesmo objeto de configuração por cinco níveis de chamada. Só pra ter uma ideia prática, tive um caso recente onde estava debugando um serviço de processamento de pedidos e levei quase dois dias descobrindo que um método estático estava modificando um campo global de conexão com banco de dados que tinha sido sobrescrito por outro thread. A solução foi refatorar tudo pra usar injeção de dependência com um singleton gerenciado. Achei que ia levar horas, mas na verdade demorou mais pra testar do que pra mudar o código em si. Métodos de instância são o padrão. Cada objeto tem seu próprio estado, os métodos acessam `this` ou o equivalente na linguagem, e tudo funciona como se espera. A desvantagem prática é que você precisa manter o ciclo de vida do objeto. Se você criar uma instância e esquecer de fechar recursos, vaza memória. Não é algo que aparece na cara, aparece três semanas depois quando o servidor começa a dar out of memory em horários aleatórios. Já passei por isso várias vezes.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Métodos de classe são um meio-termo que poucas pessoas dominam. Eles têm acesso ao estado compartilhado da classe, mas não precisam de uma instância específica. São úteis pra factory methods e pra coisas do tipo `Usuario.todosAtivos()`. O risco é que eles começam a acumular lógica que deveria estar em outro lugar. Eu costumo limitar métodos de classe a apenas dois casos: construtores alternativos e operações que realmente não precisam de instância alguma.
Como decidir na prática
A regra mais útil que eu peguei com o tempo é simples: se o método precisa de dados que vêm de fora, use parâmetro. Se ele precisa de dados que já existem no objeto, use instância. Se ele precisa de dados que são da classe inteira, use classe. Se você não conseguir encaixar em nenhum desses três, provavelmente precisa reconsiderar a arquitetura antes de escrever mais nada. Também tem o problema da testabilidade. Método estático é impossível de mockar em muitas linguagens sem usar frameworks pesados. Eu prefiro sempre pensar: "como eu vou testar isso sozinho?" Se a resposta é "não dá", aí já é sinal de que o método tá acoplado demais.
Outro ponto que ninguém menciona: métodos privados versus públicos. Tem gente que deixa tudo público porque "é mais fácil de acessar". Isso cria uma interface enorme que ninguém lê. Métodos privados podem ser refatorados livremente sem quebrar quem chama. Isso economiza refatorações caras depois. Se você tá começando e quer um caminho prático, a melhor coisa é olhar pra código existente, identificar onde cada método pertence, e perguntar: esse método precisa de estado, de classe, ou pode viver sozinho como função pura. Funções puras resolvem metade dos problemas de manutenção que eu vejo todo dia.
