04 de out. de 2025·8 min
Como o Scala combinou programação funcional e OO no JVM
Entenda por que o Scala foi criado para unir ideias funcionais e orientadas a objetos no JVM, o que acertou e quais são os trade-offs que equipes devem conhecer.
Entenda por que o Scala foi criado para unir ideias funcionais e orientadas a objetos no JVM, o que acertou e quais são os trade-offs que equipes devem conhecer.
Java tornou o JVM bem-sucedido, mas também criou expectativas com as quais muitas equipes acabaram topando: muito boilerplate, forte ênfase em estado mutável e padrões que frequentemente exigiam frameworks ou geração de código para se manterem gerenciáveis. Desenvolvedores gostavam da velocidade, das ferramentas e da história de deploy do JVM — mas queriam uma linguagem que lhes permitisse expressar ideias de forma mais direta.
No início dos anos 2000, o trabalho cotidiano no JVM envolvia hierarquias de classes verbosas, cerimônia de getters/setters e bugs relacionados a null que escapavam para produção. Escrever programas concorrentes era possível, mas o estado mutável compartilhado tornava fácil criar condições de corrida sutis. Mesmo quando as equipes seguiam bom design orientado a objetos, o código do dia a dia ainda carregava muita complexidade acidental.
A aposta do Scala foi que uma linguagem melhor poderia reduzir esse atrito sem abandonar o JVM: manter o desempenho “bom o suficiente” compilando para bytecode, mas dar aos desenvolvedores recursos que os ajudassem a modelar domínios de forma limpa e construir sistemas mais fáceis de mudar.
A maioria das equipes JVM não estava escolhendo entre estilos “puramente funcionais” e “puramente orientados a objetos” — elas estavam tentando entregar software dentro de prazos. O objetivo do Scala era permitir usar OO onde faz sentido (encapsulamento, APIs modulares, limites de serviço) enquanto se apoia em ideias funcionais (imutabilidade, código orientado a expressões, transformações compostas) para tornar os programas mais seguros e fáceis de raciocinar.
Essa mistura reflete como sistemas reais costumam ser construídos: limites orientados a objetos ao redor de módulos e serviços, com técnicas funcionais dentro desses módulos para reduzir bugs e simplificar testes.
Scala buscou fornecer tipagem estática mais forte, melhor composição e reuso, e ferramentas na linguagem que reduzissem boilerplate — tudo mantendo compatibilidade com bibliotecas e operações do JVM.
Martin Odersky projetou o Scala após trabalhar com generics do Java e observar forças em linguagens como ML, Haskell e Smalltalk. A comunidade que se formou ao redor do Scala — academia, equipes corporativas JVM e, mais tarde, engenharia de dados — ajudou a moldá-lo numa linguagem que tenta equilibrar teoria e necessidades de produção.
Scala leva a frase “tudo é um objeto” a sério. Valores que você poderia pensar como “primitivos” em outras linguagens JVM — como 1, true ou 'a' — se comportam como objetos normais com métodos. Isso significa que você pode escrever código como 1.toString ou 'a'.isLetter sem alternar o modo mental entre “operações primitivas” e “operações de objeto”.
Se você está acostumado com modelagem no estilo Java, a superfície orientada a objetos do Scala é imediatamente reconhecível: você define classes, cria instâncias, chama métodos e agrupa comportamento com tipos parecidos com interfaces.
Você pode modelar um domínio de forma direta:
class User(val name: String) {
def greet(): String = s"Hi, $name"
}
val u = new User("Sam")
println(u.greet())
Essa familiaridade importa no JVM: equipes podem adotar Scala sem abrir mão da forma básica de pensar “objetos com métodos”.
O modelo de objetos do Scala é mais uniforme e flexível que o do Java:
object Config { ... }), frequentemente substituindo padrões static do Java.val/var, reduzindo boilerplate.Herança ainda existe e é usada com frequência, mas muitas vezes de forma mais leve:
class Admin(name: String) extends User(name) {
override def greet(): String = s"Welcome, $name"
}
No trabalho do dia a dia, isso significa que o Scala oferece os mesmos blocos de construção OO em que as pessoas confiam — classes, encapsulamento, overriding — enquanto elimina algumas das estranhezas da era JVM (como uso pesado de static e getters/setters verbosos).
O lado funcional do Scala não é um “modo” separado — ele aparece como padrões e defaults que a linguagem incentiva. Duas ideias impulsionam a maior parte disso: preferir dados imutáveis e tratar seu código como expressões que produzem valores.
Em Scala, você declara valores com val e variáveis com var. Ambos existem, mas o default cultural é val.
Quando você usa val, está dizendo: “essa referência não será reatribuída.” Essa pequena escolha reduz a quantidade de estado oculto no programa. Menos estado significa menos surpresas à medida que o código cresce, especialmente em fluxos de negócio com múltiplas etapas onde valores são transformados repetidamente.
var ainda tem seu lugar — glue de UI, contadores ou trechos críticos de desempenho — mas usá-lo deve parecer intencional, não automático.
Scala incentiva escrever código como expressões que avaliam para um resultado, em vez de sequências de instruções que essencialmente mutam estado.
Isso costuma parecer construir um resultado a partir de resultados menores:
val discounted =
if (isVip) price * 0.9
else price
Aqui, if é uma expressão, então retorna um valor. Esse estilo facilita entender “qual é esse valor?” sem rastrear uma trilha de atribuições.
Em vez de loops que modificam coleções, o código Scala normalmente transforma dados:
val emails = users
.filter(_.isActive)
.map(_.email)
filter e map são funções de ordem superior: recebem outras funções como entradas. O benefício não é apenas acadêmico — é clareza. Você lê o pipeline como uma pequena história: mantenha usuários ativos e então extraia emails.
Uma função pura depende apenas de suas entradas e não tem efeitos colaterais (nenhuma escrita oculta, nenhum I/O). Quando mais do código é puro, testar fica direto: você passa entradas e verifica saídas. Raciocinar também fica mais simples, porque não é preciso adivinhar o que mais mudou em outro lugar do sistema.
A resposta do Scala para “como compartilhar comportamento sem criar uma família gigante de classes?” é o trait. Um trait parece uma interface, mas pode conter implementação real — métodos, campos e pequenas lógicas auxiliares.
Traits permitem descrever uma capacidade (“pode logar”, “pode validar”, “pode cachear”) e então anexar essa capacidade a várias classes. Isso incentiva blocos pequenos e focados em vez de algumas classes-base inchadas que todos precisam herdar.
Ao contrário da herança de única raiz, traits foram desenhados para herança múltipla de comportamento de forma controlada. Você pode adicionar mais de um trait a uma classe, e o Scala define uma ordem de linearização clara para resolver métodos.
Quando você “mix in” traits, você está compondo comportamento na fronteira da classe em vez de aprofundar a herança. Isso costuma ser mais fácil de manter:
Um exemplo simples:
trait Timestamped { def now(): Long = System.currentTimeMillis() }
trait ConsoleLogging { def log(msg: String): Unit = println(msg) }
class Service extends Timestamped with ConsoleLogging {
def handle(): Unit = log(s"Handled at ${now()}")
}
Use traits quando:
Use uma abstract class quando:
A vantagem real é que o Scala faz o reuso parecer mais montagem de peças do que herdar um destino.
O pattern matching do Scala é uma das características que fazem a linguagem soar fortemente “funcional”, mesmo mantendo suporte ao design clássico orientado a objetos. Em vez de empurrar lógica para uma teia de métodos virtuais, você pode inspecionar um valor e escolher comportamento com base em sua forma.
No nível mais simples, pattern matching é um switch mais poderoso: pode casar constantes, tipos, estruturas aninhadas e até vincular partes de um valor a nomes. Porque é uma expressão, ele naturalmente produz um resultado — frequentemente levando a código compacto e legível.
sealed trait Payment
case class Card(last4: String) extends Payment
case object Cash extends Payment
def describe(p: Payment): String = p match {
case Card(last4) => s"Card ending $last4"
case Cash => "Cash"
}
Esse exemplo também mostra um Tipo Algébrico (ADT) no estilo Scala:
sealed trait define um conjunto fechado de possibilidades.case class e case object definem as variantes concretas.“Sealed” é a chave: o compilador conhece todos os subtipos válidos (no mesmo arquivo), o que habilita pattern matching mais seguro.
ADTs encorajam você a modelar os estados reais do domínio. Em vez de usar null, strings mágicas ou booleans que podem ser combinados de maneiras impossíveis, você define explicitamente os casos permitidos. Isso torna muitos erros impossíveis de expressar no código — então eles não chegam à produção.
Pattern matching brilha quando você está:
Pode ser exagerado quando todo comportamento é expresso em grandes blocos match espalhados pelo código. Se matches crescerem muito ou aparecerem em toda parte, é um sinal de que você precisa melhor fatoração (funções auxiliares) ou mover parte do comportamento mais próximo do próprio tipo de dado.
O sistema de tipos do Scala é uma das maiores razões para as equipes escolhê-lo — e uma das maiores razões pelas quais algumas equipes desistem. No seu melhor, ele permite escrever código conciso que ainda tem fortes checagens em tempo de compilação. No seu pior, pode parecer que você está depurando o compilador.
A inferência de tipos significa que você geralmente não precisa escrever tipos em todo lugar. O compilador consegue, muitas vezes, inferir a partir do contexto.
Isso se traduz em menos boilerplate: você foca no que um valor representa em vez de anotar seu tipo constantemente. Quando você faz adicionar anotações, normalmente é para clarificar intenção em fronteiras (APIs públicas, generics complicados) e não para cada variável local.
Generics permitem escrever containers e utilitários que funcionam para muitos tipos (como List[Int] e List[String]). Variância trata se um tipo genérico pode ser substituído quando seu parâmetro de tipo muda.
+A) significa, grosso modo, “uma lista de gatos pode ser usada onde se espera uma lista de animais”.-A) significa, grosso modo, “um manipulador de animais pode ser usado onde se espera um manipulador de gatos”.Isso é poderoso para design de bibliotecas, mas pode confundir quando você encontra pela primeira vez.
Scala popularizou um padrão onde você pode “adicionar comportamento” a tipos sem modificá-los, passando capacidades implicitamente. Por exemplo, você pode definir como comparar ou imprimir um tipo e ter essa lógica selecionada automaticamente.
No Scala 2 isso usa implicit; no Scala 3 é expresso mais diretamente com given/using. A ideia é a mesma: estender comportamento de maneira componível.
O trade-off é complexidade. Truques em nível de tipo podem produzir mensagens de erro longas, e código super-abstrato pode ser difícil de ler para quem chega agora. Muitas equipes adotam a regra prática: use o sistema de tipos para simplificar APIs e evitar erros, mas evite designs que exijam que todo mundo “pense como um compilador” para fazer uma mudança.
Scala tem múltiplas “pistas” para escrever código concorrente. Isso é útil — porque nem todo problema precisa do mesmo nível de machinery — mas também significa que equipes devem ser intencionais sobre o que adotar.
Para muitos aplicativos JVM, Future é a maneira mais simples de rodar trabalho concorrentemente e compor resultados. Você dispara trabalho e usa map/flatMap para construir um fluxo assíncrono sem bloquear uma thread.
Um bom modelo mental: Futures são ótimos para tarefas independentes (chamadas de API, consultas a DB, cálculos em background) onde você quer combinar resultados e tratar falhas em um só lugar.
Scala permite expressar cadeias de Future de forma mais linear (via for-comprehensions). Isso não adiciona novos primitivos de concorrência, mas deixa a intenção mais clara e reduz o “callback hell”.
O trade-off: ainda é fácil bloquear acidentalmente (por exemplo, aguardando um Future) ou sobrecarregar um execution context se você não separar trabalho CPU-bound de trabalho IO-bound.
Para pipelines de longa duração — eventos, logs, processamento de dados — bibliotecas de streaming (como Akka/Pekko Streams, FS2 ou similares) se concentram em controle de fluxo. A feature chave é o backpressure: produtores desaceleram quando consumidores não conseguem acompanhar.
Esse modelo frequentemente supera “simplesmente criar mais Futures” porque trata vazão e memória como preocupações de primeira classe.
Bibliotecas de atores (Akka/Pekko) modelam concorrência como componentes independentes que se comunicam por mensagens. Isso pode simplificar o raciocínio sobre estado, porque cada ator trata uma mensagem por vez.
Atores brilham quando você precisa de processos stateful e de longa duração (dispositivos, sessões, coordenadores). Podem ser overkill para apps simples request/response.
Estruturas de dados imutáveis reduzem estado mutável compartilhado — a fonte de muitas condições de corrida. Mesmo usando threads, Futures ou atores, passar valores imutáveis torna bugs de concorrência mais raros e a depuração menos dolorosa.
Comece com Futures para trabalho paralelo direto. Migre para streaming quando precisar de vazão controlada e considere atores quando estado e coordenação dominarem o design.
A maior vantagem prática do Scala é que ele vive no JVM e pode usar o ecossistema Java diretamente. Você pode instanciar classes Java, implementar interfaces Java e chamar métodos Java com pouca cerimônia — muitas vezes parece que você está apenas usando outra biblioteca Scala.
A maior parte da interoperabilidade “caminho feliz” é direta:
Por baixo dos panos, Scala compila para bytecode JVM. Operacionalmente, roda como outras linguagens JVM: é gerenciado pelo mesmo runtime, usa o mesmo GC e é perfilado/monitorado com ferramentas familiares.
O atrito aparece onde os defaults do Scala não batem com os do Java:
Nulls. Muitas APIs Java retornam null; o código Scala prefere Option. Você frequentemente envolverá resultados Java defensivamente para evitar surpresas com NullPointerException.
Checked exceptions. Scala não força declarar ou capturar checked exceptions, mas bibliotecas Java podem jogá-las. Isso pode tornar o tratamento de erros inconsistente, a menos que você padronize como exceções são traduzidas.
Mutabilidade. Coleções Java e APIs “cheias de setters” incentivam mutação. Em Scala, misturar estilos mutáveis e imutáveis pode levar a código confuso, especialmente nas fronteiras de API.
Trate a fronteira como uma camada de tradução:
Option imediatamente, e converta Option de volta para null só na borda.Feito corretamente, interop permite que equipes Scala avancem mais rápido reutilizando bibliotecas JVM comprovadas enquanto mantêm o código Scala expressivo e mais seguro dentro do serviço.
O discurso do Scala é atraente: você pode escrever código funcional elegante, manter estrutura OO onde ajuda e continuar no JVM. Na prática, equipes não “simplesmente aprendem Scala” — elas sentem um conjunto de trade-offs diários que aparecem no onboarding, nas builds e nas code reviews.
Scala dá muito poder expressivo: múltiplas formas de modelar dados, diversas maneiras de abstrair comportamento, várias formas de estruturar APIs. Essa flexibilidade é produtiva quando existe um modelo mental compartilhado — mas no início pode desacelerar as equipes.
Novatos podem ter menos problema com sintaxe e mais com escolha: “isso deve ser case class, classe regular ou um ADT?” “Usamos herança, traits, type classes ou apenas funções?” O difícil não é que Scala é impossível — é concordar sobre o que é “Scala normal” para o time.
A compilação em Scala tende a ser mais pesada do que muitas equipes esperam, especialmente conforme projetos crescem ou dependem de bibliotecas que usam macros (mais comuns no Scala 2). Builds incrementais ajudam, mas tempo de compilação continua sendo uma preocupação prática recorrente: CI mais lento, loops de feedback mais longos e mais pressão para manter módulos pequenos e dependências organizadas.
Ferramentas de build adicionam outra camada. Seja usando sbt ou outro sistema, você vai querer prestar atenção em caching, paralelismo e como o projeto é dividido em submódulos. Não são questões acadêmicas — afetam felicidade do desenvolvedor e rapidez para corrigir bugs.
O tooling do Scala melhorou bastante, mas ainda vale testar com sua stack exata. Antes de padronizar, equipes devem avaliar:
Se o IDE tiver dificuldades, a expressividade da linguagem pode se voltar contra você: código que é “correto” mas difícil de explorar torna-se caro de manter.
Como Scala suporta programação funcional e orientada a objetos (além de muitos híbridos), equipes podem acabar com um codebase que parece várias linguagens ao mesmo tempo. Normalmente é aí que a frustração começa: não por causa do Scala em si, mas por convenções inconsistentes.
Convenções e linters importam porque reduzem debate. Decidam desde o começo o que significa “bom Scala” para o time — como tratar imutabilidade, handling de erros, naming e quando usar padrões avançados em nível de tipo. Consistência facilita onboarding e mantém reviews focados em comportamento em vez de estética.
Scala 3 (muitas vezes chamado de “Dotty” durante o desenvolvimento) não é uma releitura da identidade do Scala — é uma tentativa de manter o mesmo blend FP/OO enquanto suaviza arestas que equipes encontravam no Scala 2.
Scala 3 mantém os básicos familiares, mas empurra o código para uma estrutura mais clara.
Você notará chaves opcionais com indentação significativa, o que faz código cotidiano ler mais como linguagens modernas e menos como DSL densa. Também padroniza alguns padrões que eram “possíveis mas bagunçados” no Scala 2 — como adicionar métodos via extension em vez do mix de truques com implicits.
Filosoficamente, Scala 3 tenta fazer recursos poderosos parecerem mais explícitos, para que leitores consigam entender o que está acontecendo sem decorar uma dúzia de convenções.
Os implicits do Scala 2 eram extremamente flexíveis: ótimos para typeclasses e injeção de dependência, mas também fonte de erros de compilação confusos e “ação à distância”.
Scala 3 substitui grande parte do uso de implicits por given/using. A capacidade é similar, mas a intenção fica mais clara: “aqui está uma instância provida” (given) e “este método precisa de uma” (using). Isso melhora legibilidade e faz padrões FP de tipo-classe mais fáceis de seguir.
Enums também são um ganho importante. Muitas equipes Scala 2 usavam sealed traits + case objects/classes para modelar ADTs. O enum do Scala 3 dá esse padrão com sintaxe dedicada e mais limpa — menos boilerplate, mesma capacidade de modelagem.
Projetos reais geralmente migram fazendo cross-building (publicando artefatos para Scala 2 e Scala 3) e movendo módulo a módulo.
Ferramentas ajudam, mas ainda é trabalho: incompatibilidades de origem (especialmente em implicits), bibliotecas que usam macros e tooling de build podem desacelerar. A boa notícia é que código de negócio típico porta mais limpo do que código que depende fortemente de mágica do compilador.
No código do dia a dia, Scala 3 tende a tornar padrões FP mais “primeira-classe”: encadeamento de typeclasses mais claro, ADTs com enums mais limpos e ferramentas de tipagem mais fortes (como tipos união/interseção) sem tanta cerimônia.
Ao mesmo tempo, não abandona OO — traits, classes e composição por mixin continuam centrais. A diferença é que o Scala 3 torna a fronteira entre “estrutura OO” e “abstração FP” mais visível, o que costuma ajudar equipes a manter consistência ao longo do tempo.
Scala pode ser uma excelente linguagem “ferramenta potente” no JVM — mas não é sempre a escolha padrão. Os maiores ganhos aparecem quando o problema se beneficia de modelagem mais forte e composição mais segura, e quando a equipe está pronta para usar a linguagem de forma deliberada.
Sistemas e pipelines orientados a dados. Se você transforma, valida e enriquece muitos dados (streams, jobs ETL, processamento de eventos), o estilo funcional do Scala e sua tipagem forte ajudam a manter transformações explícitas e menos propensas a erros.
Modelagem de domínio complexa. Quando regras de negócio são nuanceadas — precificação, risco, elegibilidade, permissões — a capacidade do Scala de expressar restrições em tipos e construir peças pequenas e compostas pode reduzir o espalhamento de if-else e tornar estados inválidos difíceis de representar.
Organizações já investidas no JVM. Se seu mundo já depende de bibliotecas Java, tooling JVM e práticas operacionais, Scala pode entregar ergonomia de FP sem sair desse ecossistema.
Scala recompensa consistência. Equipes geralmente têm sucesso quando:
Sem isso, codebases tendem a derivar para uma mistura de estilos difícil para novatos seguirem.
Times pequenos que precisam de onboarding rápido. Se você espera muitas trocas de pessoas, muitos contribuidores juniores ou mudanças rápidas de staff, a curva de aprendizado e a variedade de idiomáticas podem te atrasar.
Apps CRUD simples. Para serviços simples “requisição entra / grava no registro” com pouca complexidade de domínio, os benefícios do Scala podem não compensar o custo de tooling, tempo de compilação e decisões de estilo.
Pergunte-se:
Se você respondeu “sim” para a maioria, Scala frequentemente é uma boa escolha. Se não, uma linguagem JVM mais simples pode entregar resultados mais rápido.
Uma dica prática ao avaliar linguagens: mantenha um loop de protótipo curto. Por exemplo, equipes às vezes usam uma plataforma de prototipagem como Koder.ai para gerar um app de referência pequeno (API + banco + UI) a partir de uma especificação via chat, iterar em modo de planejamento e usar snapshots/rollback para explorar alternativas rapidamente. Mesmo que o alvo de produção seja Scala, ter um protótipo rápido que você pode exportar como código-fonte e comparar com implementações JVM pode tornar a conversa “devemos escolher Scala?” mais concreta — baseada em fluxos de trabalho, deploy e manutenibilidade, não só em recursos da linguagem.
Scala foi projetada para reduzir pontos de dor comuns no JVM — boilerplate, bugs relacionados a null e designs frágeis baseados em herança — mantendo desempenho, ferramentas e acesso a bibliotecas do ecossistema Java. O objetivo era expressar a lógica de domínio de forma mais direta sem sair do ecossistema Java.
Use OO para definir limites claros de módulo (APIs, encapsulamento, interfaces de serviço) e aplique técnicas FP dentro desses limites (imutabilidade, código orientado a expressões, funções relativamente puras) para reduzir estado oculto e tornar o comportamento mais fácil de testar e modificar.
Prefira val por padrão para evitar reassignment acidental e reduzir estado oculto. Use var de forma intencional em pontos pequenos e localizados (por exemplo, loops de desempenho crítico ou code-behind de UI) e mantenha mutação fora da lógica central de negócio sempre que possível.
Traits são capacidades reutilizáveis que você pode mixar em várias classes, evitando hierarquias profundas e frágeis.
Modele um conjunto fechado de estados com um sealed trait e case class/case object, depois use match para tratar cada caso.
Isso torna estados inválidos mais difíceis de representar e possibilita refatorações mais seguras porque o compilador pode avisar quando um novo caso não está sendo tratado.
A inferência de tipos elimina anotações repetitivas para que o código permaneça conciso, mas continue verificado em tempo de compilação.
Prática comum: adicione tipos explícitos em fronteiras (métodos públicos, APIs de módulo, generics complexos) para melhorar legibilidade e estabilizar mensagens de erro, sem anotar cada valor local.
Variância descreve como subtipagem funciona para tipos genéricos.
+A): um container pode ser “alargado” (por exemplo, pode ser usado onde é esperado).Elas são o mecanismo por trás do estilo tipo-classe: você fornece comportamento “de fora” sem modificar o tipo original.
implicitgiven / usingScala 3 deixa a intenção mais clara (o que é provido vs o que é exigido), o que normalmente melhora legibilidade e reduz “ação à distância”.
Comece simples e evolua quando necessário:
Em todos os casos, passar dados imutáveis ajuda a evitar condições de corrida.
Trate os limites Java/Scala como camadas de tradução:
null de Java para Option imediatamente (e só converta de volta na borda).Isso mantém a interoperabilidade previsível e evita que padrões Java (nulls, mutação) vazem por todo o código.
List[Cat]List[Animal]-A): um consumidor/manipulador pode ser alargado (por exemplo, Handler[Animal] usado onde Handler[Cat] é esperado).Você sente isso mais quando projeta bibliotecas ou APIs que aceitam/retornam tipos genéricos.