Princípios de arquitetura no desenvolvimento móvel: o que são, tipos e como aplicar

Princípios SOLID

Princípios de arquitetura — são a base do código de qualidade. SOLID é um acrônimo introduzido por Robert Martin ("Tio Bob") que descreve cinco princípios de design orientado a objetos. Seguir SOLID torna o código mais flexível, testável e resistente a mudanças. A violação dos princípios de arquitetura é uma das principais causas de dívida técnica.

Vamos examinar cada princípio. Single Responsibility Principle (SRP) — cada classe deve ter apenas um motivo para mudar. Open/Closed Principle (OCP) — classes abertas para extensão, mas fechadas para modificação. Liskov Substitution Principle (LSP) — objetos de subtipos devem substituir objetos de tipo base sem quebrar a lógica. Interface Segregation Principle (ISP) — muitas interfaces especializadas são melhores que uma interface geral. Dependency Inversion Principle (DIP) — dependa de abstrações, não de implementações concretas.

De acordo com a análise do SonarQube (2025), a violação dos princípios SOLID ocorre em 68% dos projetos comerciais. Os problemas mais comuns são violação de SRP (35%) e ISP (22%). Na IT Sectr, implementamos SOLID na fase de revisão de arquitetura — isso ajuda a identificar problemas antes que se transformem em dívida técnica.

Single Responsibility Principle (SRP)

SRP (Princípio da Responsabilidade Única) — o mais importante e simultaneamente o princípio SOLID mais frequentemente violado. Ele afirma: uma classe deve ter apenas um motivo para mudar. Se uma classe faz demais, é difícil testar, modificar e entender.

Uma violação típica é uma classe que simultaneamente processa dados, salva no banco de dados e envia notificações por e-mail. O exemplo abaixo mostra uma violação de SRP em Kotlin e como corrigi-la.

// Violação SRP — classe faz três coisas diferentes
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Validação de dados
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Salvar no banco
        val user = User(email, name)
        database.save(user)
        
        // 3. Enviar notificação
        emailService.sendWelcomeEmail(email, name)
    }
}

// Correção — dividir em três classes
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

Na versão corrigida, cada classe é responsável por sua própria tarefa: UserValidator — pela validação, UserRepository — por salvar, NotificationService — pelas notificações. Isso torna o código testável e reutilizável — você pode substituir a implementação do banco de dados sem alterar a lógica de validação.

GRASP e Lei de Demeter

GRASP (General Responsibility Assignment Software Patterns) — nove princípios de arquitetura para distribuir responsabilidade entre objetos, descritos por Craig Larman. Ao contrário do SOLID, GRASP responde à pergunta «qual classe deve conter este método?». Padrões-chave: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Lei de Demeter (LoD, princípio de acoplamento mínimo) — uma regra simples: um objeto deve se comunicar apenas com seus vizinhos imediatos. Não se deve escrever a.getB().getC().doSomething() — isso cria um forte acoplamento entre classes. LoD melhora a reutilização e simplifica os testes.

Na IT Sectr, verificamos a conformidade com LoD durante a Revisão de Código. Se um método «passa por» três ou mais objetos, é um sinal de que a arquitetura precisa ser simplificada. A violação de LoD é um dos Code Smells mais comuns em grandes projetos.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) e YAGNI (You Ain't Gonna Need It) — três princípios básicos de arquitetura conhecidos por todo desenvolvedor. Apesar de sua simplicidade, as violações ocorrem constantemente.

DRY — não duplique código. Se a mesma lógica aparecer em dois lugares, extraia-a para um método ou classe comum. A duplicação é a principal fonte de bugs: uma correção em um lugar é esquecida de ser aplicada em outro. DRY não significa que você não possa ter código semelhante — o importante é que a lógica de negócios não se repita.

KISS — quanto mais simples, melhor. Soluções complexas com muitas abstrações e heranças são frequentemente excessivas. Comece com uma solução simples e torne-a mais complexa apenas quando necessário. YAGNI — não escreva código para funcionalidades que podem ser necessárias «algum dia depois». Isso leva ao inchaço do código e aumenta a complexidade da manutenção.

DRY — Don't Repeat Yourself

DRY — não se trata apenas da ausência de copiar e colar. É um princípio segundo o qual cada pedaço de conhecimento ou lógica deve ter uma representação única e inequívoca no sistema. A duplicação pode ser explícita (código copiado) e implícita (mesma lógica em camadas diferentes).

Na IT Sectr, usamos métricas de análise de código para detectar duplicação. Ferramentas como SonarQube e Detekt mostram a porcentagem de código duplicado. Um valor acima de 5% é motivo para refatoração. No entanto, é importante lembrar: DRY não deve ser alcançado ao custo de abstrações erradas — às vezes é melhor deixar dois pedaços de código semelhantes como estão se combiná-los dificultar a compreensão.

Separação de Preocupações e Modularidade

Separação de Preocupações (SoC) — um princípio de arquitetura onde um sistema é dividido em partes independentes (preocupações), cada uma resolvendo sua própria tarefa. Um exemplo clássico é a separação em camadas: apresentação, lógica de negócios, acesso a dados. Cada camada depende apenas da camada inferior.

Modularidade — o grau em que um sistema pode ser dividido em módulos. Um módulo é um grupo de classes logicamente relacionadas com uma interface bem definida. Os módulos devem ser fracamente acoplados (baixo acoplamento) e altamente coesos (alta coesão).

Coesão vs Acoplamento

Coesão — uma medida de quanto os elementos dentro de um mesmo módulo estão relacionados entre si. Alta coesão é boa: uma classe faz uma coisa e a faz bem. Baixo acoplamento — uma medida de quanto os módulos são independentes entre si. Baixo acoplamento é bom: mudar um módulo não quebra outros.

Arquitetura ideal é alta coesão e baixo acoplamento. Na prática, isso significa: uma classe contém métodos que trabalham nos mesmos dados (coesão) e depende apenas de abstrações, não de implementações concretas (acoplamento). Um desequilíbrio leva a «Objetos Deus» ou «código espaguete».

Dívida técnica e Code Smell

Dívida técnica — uma metáfora introduzida por Ward Cunningham que descreve os «juros» que uma equipe paga por decisões de arquitetura subótimas e violação de princípios de arquitetura. Como a dívida financeira, a dívida técnica pode ser intencional (decidimos fazer rápido, refaremos depois) e não intencional (má arquitetura devido à falta de experiência).

Code Smell — sinais superficiais de problemas profundos no código. O termo foi popularizado por Martin Fowler no livro «Refactoring». Code Smells típicos: métodos longos, classes grandes, cadeias de chamada longas, duplicação de código, uso excessivo de comentários (em vez de código claro).

Na IT Sectr, a dívida técnica é rastreada no Jira como tarefas separadas. A cada sprint, alocamos 20% do tempo para refatoração e pagamento da dívida. O trabalho sistemático com a dívida técnica é a única maneira de evitar uma situação em que adicionar um novo recurso leva mais tempo do que desenvolvê-lo do zero.