Beyond Objects
Este artigo argumenta que o princípio central da orientação a objetos de mapear a funcionalidade do sistema diretamente para indivíduos do domínio do problema é inerentemente falho e leva à fragmentação, propondo, em vez disso, abandonar a orientação a objetos em favor de uma abordagem que desacopla os indivíduos do domínio dos módulos funcionais.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
A Grande Ideia: O Erro do "Tamanho Único para Todos"
Imagine que você está construindo uma casa. Nos últimos 50 anos, a regra padrão na construção de software tem sido: "Cada cômodo da casa deve ser gerenciado pela pessoa que mora nele."
No mundo do software, isso é chamado de Programação Orientada a Objetos (POO). A ideia é que, se você tem um "Usuário" no mundo real, você cria um "Objeto Usuário" no código. Esse objeto deve conter todos os dados sobre esse usuário (seu nome, senha) e realizar todo o trabalho relacionado a ele (fazer login, escrever avaliações, reservar mesas).
Daniel Jackson argumenta que essa regra é uma armadilha. Ela parece lógica, mas, na prática, força o software a se tornar uma bagunça emaranhada. Ele sugere que paremos de tentar espremer cada tarefa dentro da "pessoa" e, em vez disso, organizemos o software pelo que está acontecendo (as ações), não por quem está fazendo (os indivíduos).
O Problema: O "Canivete Suíço" vs. A "Ferramenta Especializada"
Jackson diz que forçar cada tarefa sobre um único "Objeto Usuário" causa dois principais problemas:
1. O Problema do "Canivete Suíço" (Conflação)
Imagine que um Objeto Usuário é um Canivete Suíço. Ele tem uma lâmina, uma chave de fenda, um saca-rolhas e um palito de dente.
- O Problema: Se você quiser usar o saca-rolhas (para lidar com a senha de um usuário), você tem que carregar o canivete inteiro e pesado. Se você quiser mudar a lâmina (corrigir um erro no sistema de avaliações), pode acabar quebrando acidentalmente o saca-rolhas.
- No Software: Um objeto "Usuário" acaba contendo a senha do usuário, seu histórico de avaliações, suas configurações de notificação e sua lógica de reserva, tudo em um único arquivo gigante. Se você quiser mudar como as avaliações funcionam, terá que vasculhar o código das senhas. É bagunçado e difícil de consertar.
2. O Problema das "Muitas Mãos" (Fragmentação)
Imagine uma tarefa como "Reservar uma mesa".
- O Problema: Quem deve fazer isso? O Usuário? O Restaurante? A Mesa? O Restaurante?
- No Software: Como a regra diz "atribua o trabalho ao objeto", o código fica dividido. O objeto "Usuário" verifica se ele tem uma reserva. O "Restaurante" verifica se a mesa está livre. O objeto "Reserva" cria o ticket.
- O Resultado: Para fazer uma única reserva, o computador precisa rodar três pessoas diferentes em três quartos diferentes e fazê-las conversar entre si. Se uma pessoa esquecer de avisar a outra, o sistema quebra. Isso é chamado de fragmentação.
A Analogia: A Reserva de Restaurante
Jackson usa um restaurante para explicar isso.
O Jeito Antigo (Orientado a Objetos):
Você tem um objeto "Usuário" e um objeto "Restaurante".
- Quando Alice quer reservar uma mesa, ela pergunta ao seu objeto "Usuário".
- O objeto Usuário pergunta ao objeto "Restaurante" se uma mesa está livre.
- O objeto Restaurante pergunta ao objeto "Slot" (Vaga).
- O objeto "Reserva" é criado.
- A Bagunça: Se você quiser mudar a regra para que "Alice não possa reservar duas mesas ao mesmo tempo", você terá que atualizar o objeto Usuário, o objeto Restaurante e o objeto Reserva. Eles estão todos emaranhados.
O Novo Jeito (Conceitos):
Em vez de perguntar "Quem é o dono disso?", perguntamos "Sobre o que é este grupo de regras?".
Jackson propõe organizar o software em Conceitos. Pense em um Conceito como uma equipe especializada ou um departamento em uma empresa, em vez de uma pessoa.
- Conceito 1: "Reservar"
- Esta equipe lida com todas as regras sobre fazer compromissos. Ela não se importa com quem é o usuário; ela apenas se importa com o ato de reservar. Ela detém a lista de quem reservou o quê.
- Conceito 2: "Disponibilidade"
- Esta equipe lida com o ato de verificar se uma mesa está aberta. Ela não se importa com quem está reservando; ela apenas se importa com os espaços/horários.
- Conceito 3: "Autenticação de Usuário"
- Esta equipe apenas verifica se a pessoa é quem diz ser.
Como eles trabalham juntos:
Em vez do objeto Usuário chamar o objeto Restaurante, esses "Conceitos" conversam entre si através de Sincronizações (como um semáforo).
- Regra: "Quando um Pedido chega, verifique se a Disponibilidade diz 'Sim', e se a Autenticação diz 'Siga em frente', então a Reserva pode fazer a reserva."
Por Que Isso é Melhor
- Sem Nós Emaranhados: A equipe de "Reserva" não precisa saber como verificar uma senha. A equipe de "Autenticação" não precisa saber como verificar uma mesa. Eles são separados.
- Sem Discussões de "Quem é o Dono Disso?": Você não precisa discutir se o botão de "cancelar" pertence ao Usuário ou à Reserva. Você apenas coloca a lógica de "cancelar" no Conceito que gerencia o estado da reserva.
- Mapas Mais Claros: Se você olhar para o código, você vê as regras de negócio (Reserva, Disponibilidade) claramente, em vez de um mapa confuso de quem é dono de qual dado.
O "Conceito" vs. O "Objeto"
- Objeto: Uma pequena máquina que tenta ser tudo (Dados + Lógica + Identidade). É como uma pessoa tentando ser chef, garçom e caixa ao mesmo tempo.
- Conceito: Um módulo que lida com um trabalho ou relacionamento específico. É como um departamento especializado. O "Departamento de Chefia" cuida do cozimento; o "Departamento de Garçons" cuida do serviço. Eles se coordenam, mas não se fundem em uma única pessoa.
A Conclusão
Jackson não está dizendo que devemos jogar fora todo o software. Ele está dizendo que a regra central da Programação Orientada a Objetos — "Atribua cada trabalho à pessoa a quem ele pertence" — é a raiz do problema.
Ao mudar para Conceitos, paramos de tentar forçar o software a parecer uma coleção de pessoas. Em vez disso, organizamos o software como uma coleção de regras e relacionamentos. Isso torna o código mais fácil de ler, mais fácil de consertar e menos propenso a quebrar quando você tenta mudar uma pequena coisa.
É um retorno a uma forma de pensar mais antiga e simples (como bancos de dados relacionais), mas atualizada para as necessidades modernas de software, permitindo-nos construir sistemas que são menos frágeis e mais lógicos.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.