Translate

Mostrar mensagens com a etiqueta SRP. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta SRP. Mostrar todas as mensagens

domingo, 1 de junho de 2025

☕💣🚀 PADAWAN, O ASSEMBLER NÃO É UMA LINGUAGEM. É O MOMENTO EM QUE VOCÊ PARA DE DISCUTIR COM O COMPUTADOR E COMEÇA A CONVERSAR DIRETAMENTE COM A CPU!

Bellacosa Mainframe e a linguagem assembler em mainframe o mitico hlasm

☕💣🚀 PADAWAN, O ASSEMBLER NÃO É UMA LINGUAGEM. É O MOMENTO EM QUE VOCÊ PARA DE DISCUTIR COM O COMPUTADOR E COMEÇA A CONVERSAR DIRETAMENTE COM A CPU!

As Lições Ocultas do Curso IBM z/Architecture Assembler Language – Part 2

Existe um momento na vida de todo profissional de Mainframe em que COBOL deixa de ser suficiente.

Não porque COBOL seja limitado.

Não porque o Mainframe seja antigo.

Mas porque surge uma pergunta perigosa:

"O que realmente acontece quando meu programa executa?"

É nesse momento que nasce o interesse pelo Assembler.

O curso IBM EZ341G — z/Architecture Assembler Language Part 2: Machine Instructions — não ensina apenas instruções. Ele ensina como o processador IBM Z pensa.

E isso muda tudo.


O Grande Segredo: Tudo é Registrador

Durante o curso inteiro existe uma mensagem escondida:

LH    3,NUM
AR    3,4
CR    3,5
BE    IGUAL

Tudo gira em torno dos registradores.

Quando um programador COBOL escreve:

ADD VALOR-A TO VALOR-B

o compilador transforma isso em dezenas de instruções de máquina.

O processador não entende COBOL.

Não entende Java.

Não entende Python.

Ele entende apenas instruções.

E quase todas elas envolvem registradores.


A Regra de Ouro: Se Tem G, Pense em 64 Bits

Uma das maiores pegadinhas do curso é distinguir instruções de 32 e 64 bits.

O padrão da IBM é elegantemente simples:

G = Grande = 64 bits

Exemplos:

LG
LGR
LGFI
AG
AGFI
CG
CGR

Todos trabalham sobre o registrador completo.

Já:

L
A
C
AFI

operam apenas sobre a low half do registrador.

Essa pequena letra "G" aparece em dezenas de questões do exame.


O Mistério do Condition Code

O Condition Code é provavelmente o conceito mais importante do curso.

Após uma comparação:

CR  3,4

a CPU grava um valor invisível dentro do PSW.

Esse valor é:

CC=0 Equal
CC=1 Low
CC=2 High

Depois disso:

JE    IGUAL
JL    MENOR
JH    MAIOR

tomam decisões baseadas nesse resultado.

Perceba a beleza do mecanismo.

O processador não executa "IF".

Ele apenas produz Condition Codes.

Todo o resto é interpretação.


O Macete 8421

Outro conceito que aparece repetidamente no exame:

8 = Zero
4 = Minus
2 = Plus
1 = Overflow

Esse é o famoso padrão das máscaras de branch.

Por isso:

JZ
JM
JP
JO

são apenas apelidos amigáveis para máscaras numéricas.

Quando você entende isso, dezenas de Extended Mnemonics deixam de ser um problema.


Packed Decimal: A Religião Financeira do Mainframe

Se existe uma tecnologia que sobreviveu a todas as modas da computação, é o Packed Decimal.

Enquanto o restante do mundo usa floating point para tudo, bancos continuam confiando bilhões de dólares diariamente em instruções como:

AP
SP
MP
DP
CP

O motivo é simples.

Dinheiro não tolera aproximações.


Como Reconhecer um Packed Decimal Válido

Muitos alunos perdem pontos porque esquecem uma regra básica.

Os dígitos devem conter:

0-9

E o último nibble deve conter um sinal:

C
D
F

Exemplos válidos:

123C
123D
550F

Exemplos inválidos:

12AC
00C1
1ABC

Quando isso acontece:

S0C7
Data Exception

O famoso terror dos programadores COBOL.


O Verdadeiro Significado do S0C7

Muitos iniciantes acreditam que:

S0C7 = erro de COBOL

Errado.

O S0C7 é um erro da CPU.

Ela tentou executar uma operação decimal e encontrou dados inválidos.

O COBOL apenas estava no lugar errado na hora errada.


Multiplicação: Onde Todo Mundo Erra

As instruções:

M
MR
MP

parecem simples.

Mas escondem algumas das regras mais cruéis da arquitetura.

Por exemplo:

MR 2,3

não multiplica R2 por R3.

Na verdade utiliza:

Par R2-R3

e coloca o resultado distribuído entre os dois registradores.

Essa é uma das pegadinhas favoritas da IBM.


Divisão: A Arte de Produzir S0CB

A instrução:

DP

é responsável por um dos abends mais famosos do mundo Mainframe:

S0CB
Decimal Divide Exception

Ele ocorre quando:

  • O divisor é zero.

  • O quociente não cabe no campo de destino.

Ou seja, a CPU está protegendo seus dados.


SRP: A Instrução que Parece Magia

Poucas instruções impressionam tanto quanto:

SRP

Shift and Round Packed.

Com ela podemos:

123.95 -> 123
123.95 -> 124
55 -> 5500

Tudo sem realizar multiplicações ou divisões explícitas.

Na prática, SRP é uma calculadora financeira embutida no hardware.


ED: O Momento em que o Mainframe Aprende a Falar com Humanos

Packed Decimal é excelente para cálculos.

Mas humanos não gostam de ler:

12345C

É aí que entra:

ED

A instrução EDIT.

Ela transforma números internos em formatos amigáveis:

12.345,67
24.00
999.99

O ED é literalmente a ponte entre o mundo da CPU e o mundo dos relatórios.


O Poder das Máscaras

A maioria dos alunos demora para perceber que:

ED

não faz a formatação.

Quem faz é a máscara.

Por isso encontramos padrões como:

20
21
4B
6B
40

onde:

20 = Digit Selector
21 = Significance Starter
4B = Ponto Decimal
6B = Vírgula
40 = Espaço

É um mecanismo brilhante criado décadas antes da maioria das linguagens modernas.


O Que o Curso Realmente Ensina

Oficialmente o curso fala sobre:

  • LOAD

  • STORE

  • ADD

  • SUBTRACT

  • MULTIPLY

  • DIVIDE

  • COMPARE

  • BRANCH

  • CHARACTERS

  • PACKED DECIMAL

Mas na prática ele ensina algo muito mais profundo.

Ele mostra que toda linguagem moderna, toda API, todo framework e toda aplicação corporativa acabam reduzidos a algumas operações fundamentais:

Mover dados
Somar
Subtrair
Comparar
Desviar
Formatar

O Mainframe apenas faz isso de forma extremamente explícita.


Conclusão

☕💣🚀 PADAWAN, quando você aprende Assembler, descobre um segredo que poucos profissionais conhecem.

O computador nunca executou COBOL.

Nunca executou Java.

Nunca executou Python.

Ele sempre executou instruções de máquina.

O Assembler apenas remove o tradutor e permite que você converse diretamente com a arquitetura IBM Z.

E quando isso acontece, você deixa de ser apenas um programador.

Você começa a entender como a própria CPU pensa.


sexta-feira, 27 de novembro de 2020

God Object Rules: Quando um Programador COBOL Descobriu que Nem Mesmo o Arquiteto da Matrix Deveria Controlar Tudo Sozinho

 

Bellacosa Mainframe e a god object rules

☕ Um Café no Bellacosa Mainframe

God Object Rules sem Mistérios

Quando um Programador COBOL Descobriu que Nem Mesmo o Arquiteto da Matrix Deveria Controlar Tudo Sozinho

"Todo sistema precisa de liderança. Nenhum sistema sobrevive quando uma única entidade tenta fazer absolutamente tudo."


Prólogo — O Programa que Governava Toda a Matrix

Neo caminhava pelos corredores infinitos da Matrix.

Depois de atravessar dezenas de portas, finalmente chegou até a sala do Arquiteto.

Mas desta vez havia algo diferente.

No centro da sala existia apenas um gigantesco programa.

Seu nome era:

SYSTEM-CORE-MASTER-PROCESSOR-UNIVERSAL

Neo perguntou:

— O que esse programa faz?

O Arquiteto respondeu calmamente.

— Tudo.

Neo estranhou.

— Tudo?

— Sim.

Ele:

  • autentica usuários;

  • calcula empréstimos;

  • processa PIX;

  • envia e-mails;

  • controla cartões;

  • consulta saldo;

  • gera boletos;

  • grava auditoria;

  • imprime relatórios;

  • conversa com APIs;

  • envia mensagens MQ;

  • acessa o Db2;

  • manipula VSAM;

  • chama CICS;

  • controla segurança;

  • gera logs;

  • cria arquivos;

  • calcula impostos;

  • fecha o mês;

  • abre o dia.

Neo ficou em silêncio.

Olhou para o tamanho do programa.

412.873 linhas

Morpheus respirou profundamente.

— Neo...

você acaba de encontrar um God Object.


O que é God Object?

God Object (Objeto Deus) é um antipadrão onde um único componente concentra responsabilidades demais.

Ele conhece tudo.

Controla tudo.

Decide tudo.

Depende de todos.

E todos dependem dele.

Em Programação Orientada a Objetos normalmente é uma classe gigantesca.

No universo COBOL, normalmente aparece como:

  • um programa enorme;

  • um módulo central;

  • um "programa mestre";

  • um controlador universal.


A origem do termo

O conceito surgiu durante a popularização da Programação Orientada a Objetos nos anos 80 e 90.

Quando OO começou a crescer, percebeu-se que muitos desenvolvedores criavam classes responsáveis por praticamente todo o sistema.

Essas classes violavam praticamente todos os princípios de bom projeto.

Receberam então o apelido de:

God Object

Porque pareciam onipresentes.


Matrix explica isso perfeitamente

Durante boa parte da trilogia acreditamos que:

O Arquiteto controla tudo.

Depois descobrimos que não.

Existe também:

  • Oráculo

  • Merovíngio

  • Chaveiro

  • Agentes

  • Programas independentes

  • Sentinelas

Cada um possui responsabilidades diferentes.

Imagine se apenas o Arquiteto tentasse executar tudo sozinho.

A Matrix entraria em colapso.


O nascimento do God Object

Curiosamente...

ele costuma nascer de uma boa intenção.

Primeira versão.

Programa de Clientes

Depois.

"Vamos colocar autenticação."

Depois.

"Aproveita e grava log."

Depois.

"Já calcula limite."

Depois.

"Também envia e-mail."

Depois.

"Também atualiza cartão."

Depois.

"Também consulta PIX."

Cinco anos depois.

O programa virou um universo inteiro.


O COBOL conhece isso muito bem

Imagine um programa chamado:

CLIENTE01

Originalmente fazia apenas cadastro.

Anos depois passou a:

  • consultar saldo;

  • emitir extratos;

  • calcular tarifas;

  • atualizar endereço;

  • validar CPF;

  • gerar auditoria;

  • integrar Open Finance;

  • enviar SMS;

  • gerar arquivos CNAB.

O nome permaneceu.

A responsabilidade desapareceu.


Um exemplo simples

Arquitetura saudável.

CLIENTE

↓

Cadastro

↓

Consulta

↓

Atualização

Agora.

God Object.

CLIENTE

↓

Tudo.

O efeito psicológico

Existe uma razão interessante.

Nosso cérebro gosta de centralizar.

Quando surge uma nova funcionalidade pensamos.

"Vou colocar aqui mesmo."

É mais rápido.

Mais fácil.

Mais conveniente.

Até deixar de ser.


Matrix Reloaded

Imagine Neo.

Cada novo poder descoberto.

Voar.

Parar balas.

Ler código.

Controlar máquinas.

Agora imagine.

Além disso.

Ele também:

pilota a nave.

Conserta motores.

Programa a Matrix.

Opera comunicações.

Faz medicina.

Cozinha.

Conserta o Db2.

Absurdo.

Mas exatamente isso acontece com um God Object.


Como reconhecer?

Existem sinais clássicos.

Programa enorme

Dezenas de milhares de linhas.


Muitas responsabilidades

Faz tudo.


Muitas dependências

Conhece dezenas de módulos.


Muitas chamadas

Todo mundo depende dele.


Alterações frequentes

Sempre muda.

Porque tudo passa por ele.


O Agente Smith adora isso

Porque basta derrubar um único componente.

Todo o sistema sofre.

É um enorme ponto único de falha.


Um exemplo COBOL

Programa:

PGMCORE

Ele:

  • acessa Db2;

  • grava VSAM;

  • chama MQ;

  • consulta REST;

  • gera XML;

  • gera JSON;

  • controla autenticação;

  • calcula impostos;

  • imprime relatórios.

Pergunta.

Qual é sua responsabilidade?

Resposta.

Todas.


O custo invisível

Nova regra.

Antes.

Alterava um programa.

Agora.

Precisa entender:

80 mil linhas.


O impacto no Mainframe

Quanto maior o God Object.

Maior:

  • CPU;

  • tempo de compilação;

  • tempo de testes;

  • risco;

  • dependência.


Existe God Object em arquitetura?

Sim.

Às vezes não é um programa.

É um microsserviço.

Chamado:

CoreService.

Ele atende:

todos.

Isso também é um God Object.


A diferença

Módulo central.

Coordena.


God Object.

Executa tudo.


O papel do Arquiteto

O verdadeiro arquiteto distribui responsabilidades.

Nunca concentra.


O princípio SOLID

God Object viola vários princípios.

Principalmente.

SRP

Single Responsibility Principle.

Um módulo.

Uma responsabilidade.


Matrix e o Oráculo

O Oráculo não tenta controlar toda a Matrix.

Ela aconselha.

O Chaveiro cuida das chaves.

O Merovíngio controla informações.

Cada programa possui função específica.

Essa divisão torna o sistema resiliente.


Como evitar?

Modularização

Divida funções.


CALL

Extraia responsabilidades.


APIs

Separe serviços.


COPYBOOK

Compartilhe estruturas.

Não comportamento.


Refatoração

Remova responsabilidades pouco a pouco.


Revisões

Questione sempre.

"Esse módulo realmente deveria fazer isso?"


Atenção!

Existe uma diferença importante.

Um programa pode ser grande.

Sem ser God Object.

O problema não é o tamanho.

É a quantidade de responsabilidades.


Curiosidade

Muitos sistemas bancários antigos possuem programas chamados:

MASTER

CORE

MAIN

CONTROL

MANAGER

Nem todos são God Objects.

Mas muitos acabaram se tornando.


O perigo

Acoplamento

Tudo depende dele.


Baixa reutilização

Funções ficam escondidas.


Testes difíceis

Cenários infinitos.


Deploy arriscado

Qualquer alteração afeta tudo.


Conhecimento concentrado

Poucas pessoas entendem.


Um exemplo inspirado na Matrix

Imagine.

Existe apenas um personagem.

Ele é:

Arquiteto.

Oráculo.

Neo.

Trinity.

Smith.

Merovíngio.

Chaveiro.

Todos ao mesmo tempo.

A história seria impossível.

Software também.


Ferramentas ajudam

Hoje conseguimos identificar God Objects usando:

  • SonarQube

  • IBM ADDI

  • IBM Application Discovery

  • Enterprise Analyzer

  • IBM COBOL Check

Elas medem:

  • acoplamento;

  • complexidade;

  • dependências;

  • tamanho;

  • responsabilidades.


O papel da IA

IA consegue identificar:

métodos enormes.

Dependências.

Objetos excessivos.

Mas ainda depende da análise humana para decidir como dividir responsabilidades.


Aplicabilidade

God Object aparece em:

  • COBOL

  • Java

  • C#

  • Python

  • PHP

  • JavaScript

  • Microsserviços

  • APIs

  • Cloud

Nenhuma tecnologia escapa.


Erros clássicos

  • Colocar tudo no mesmo programa.

  • Misturar negócio com infraestrutura.

  • Misturar interface com persistência.

  • Acrescentar funcionalidades indefinidamente.

  • Evitar modularização.


Boas práticas

  • Alta coesão.

  • Baixo acoplamento.

  • Uma responsabilidade.

  • Pequenas funções.

  • Interfaces claras.

  • Código reutilizável.

  • Documentação.


O ensinamento do Oráculo

O Oráculo entrega um espelho para Neo.

Ele olha.

Vê apenas um rosto.

Depois o espelho se quebra.

Agora aparecem centenas de pequenos espelhos.

Ela pergunta.

"Qual deles é mais resistente?"

Neo responde.

"Os pequenos."

Ela sorri.

"Quando um quebra, os outros continuam refletindo."

Essa é exatamente a ideia da arquitetura modular.


Lições para um Programador COBOL Padawan

Ao longo da carreira, você encontrará programas que parecem controlar o universo inteiro. A tentação será continuar acrescentando funcionalidades porque "já existe muita coisa ali".

Resista.

Sempre que possível:

  • identifique responsabilidades distintas;

  • extraia regras para módulos especializados;

  • separe acesso a dados das regras de negócio;

  • utilize programas chamados (CALL) para funcionalidades reutilizáveis;

  • mantenha interfaces simples e bem definidas.

Cada responsabilidade removida de um God Object reduz riscos, facilita testes e torna o sistema mais compreensível.


Curiosidades

O antipadrão God Object possui "parentes" famosos:

  • Blob – um objeto gigante rodeado de objetos quase vazios.

  • God Class – termo usado em Java e C# para classes com centenas de métodos.

  • Swiss Army Knife Class – classe que tenta oferecer uma ferramenta para qualquer situação.

  • Manager Mania – classes chamadas Manager, Helper ou Util que acabam concentrando comportamento demais.

Todos compartilham a mesma característica: excesso de responsabilidades.


Conclusão — Nem Mesmo o Arquiteto Controlava Tudo

No universo Matrix existe uma lição fascinante.

Embora o Arquiteto parecesse controlar toda a simulação, ele não fazia tudo sozinho. A estabilidade do sistema dependia da colaboração entre diversas entidades, cada uma especializada em uma função.

A Engenharia de Software segue exatamente esse princípio.

Quando um único programa COBOL, uma classe Java ou um microsserviço tenta assumir todas as responsabilidades, ele se transforma em um God Object. No início parece eficiente. Depois torna-se pesado, difícil de testar, arriscado de modificar e praticamente impossível de compreender.

Para um Programador COBOL, especialmente em ambientes IBM Z que processam milhões de transações críticas, a maior virtude não é escrever o maior programa da empresa.

É construir componentes pequenos, coesos, bem definidos e capazes de cooperar entre si.

No universo Bellacosa Mainframe existe uma máxima digna do Oráculo:

"Um sistema forte não nasce de um único programa poderoso. Nasce de muitos módulos simples que sabem exatamente qual é sua missão."

Porque até a Matrix precisou aprender que nenhum programa deveria tentar ser um deus.

sábado, 25 de abril de 2020

SOLID Rules : Quando um Programador COBOL Descobriu que a Matrix Não Permanecia de Pé por Magia… Mas Porque Seus Alicerces Seguiam Cinco Princípios Fundamentais

 

Bellacosa Mainframe apresenta solid rules

☕ Um Café no Bellacosa Mainframe

SOLID Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Não Permanecia de Pé por Magia… Mas Porque Seus Alicerces Seguiam Cinco Princípios Fundamentais

"Construir software é como construir Zion. O segredo não está apenas nas paredes. Está nos pilares invisíveis que impedem tudo de desabar."


Prólogo — Os Cinco Pilares da Matrix

Depois de atravessar inúmeras versões da Matrix, Neo finalmente chegou ao salão mais antigo da Cidade das Máquinas.

Ao contrário do que imaginava, não encontrou processadores gigantes nem supercomputadores.

No centro da sala havia apenas cinco colunas de cristal.

Cada uma emitia uma luz diferente.

Neo perguntou ao Arquiteto:

— O que sustentam essas colunas?

O Arquiteto respondeu:

— Tudo.

Neo olhou ao redor.

— A Matrix inteira?

— Sim.

Neo aproximou-se da primeira coluna.

Nela estava gravado:

S

Na segunda.

O

Na terceira.

L

Na quarta.

I

Na quinta.

D

O Oráculo apareceu com duas xícaras de café.

Entregou uma para Neo.

Depois disse:

"A maioria dos programadores acredita que grandes sistemas sobrevivem porque foram escritos por pessoas inteligentes. Na verdade, eles sobrevivem porque foram construídos sobre princípios inteligentes."

Neo percebeu que aquelas cinco letras sustentavam toda a Matrix.


O que é SOLID?

SOLID é um conjunto de cinco princípios de projeto de software que ajudam a criar sistemas:

  • fáceis de entender;

  • fáceis de manter;

  • fáceis de evoluir;

  • menos propensos a bugs;

  • mais preparados para mudanças.

Embora tenham surgido no contexto da programação orientada a objetos, seus conceitos são muito mais amplos e podem ser aplicados a COBOL, CICS, Db2, APIs, microsserviços, arquitetura corporativa e praticamente qualquer tecnologia.


A origem do SOLID

Os princípios foram sendo formulados por Robert C. Martin, conhecido mundialmente como Uncle Bob, durante as décadas de 1990 e 2000.

O acrônimo SOLID foi posteriormente organizado por Michael Feathers, reunindo cinco ideias fundamentais:

  • S – Single Responsibility Principle

  • O – Open/Closed Principle

  • L – Liskov Substitution Principle

  • I – Interface Segregation Principle

  • D – Dependency Inversion Principle

Esses princípios tornaram-se referência mundial para arquitetura e design de software.


Matrix explica perfeitamente

Imagine que cada um dos cinco pilares da Matrix seja removido.

Primeiro.

As responsabilidades ficam confusas.

Depois.

Toda mudança exige alterar tudo.

Em seguida.

Componentes deixam de ser compatíveis.

Depois.

Interfaces tornam-se enormes.

Por fim.

Tudo depende diretamente de tudo.

Resultado.

A Matrix entra em colapso.


Primeiro Pilar — S

Single Responsibility Principle (SRP)

Uma classe, módulo ou programa deve possuir apenas um motivo para mudar.


O COBOL entende isso perfeitamente

Imagine um programa chamado:

CLIENTE01

Ele:

  • cadastra clientes;

  • calcula empréstimos;

  • imprime boletos;

  • envia e-mails;

  • atualiza estoque;

  • gera PIX.

Quantas responsabilidades existem?

Muitas.

Se qualquer uma mudar.

O programa inteiro muda.


Matrix

Neo pergunta.

— Quem controla Zion?

O Oráculo responde.

— Todo mundo.

Resultado?

Ninguém sabe quem é responsável.


Segundo Pilar — O

Open/Closed Principle (OCP)

Software deve estar aberto para extensão e fechado para modificação.


Em vez de alterar código antigo.

Criamos novas funcionalidades.


Exemplo COBOL

Criar um novo subprograma para um novo cálculo.

Não modificar dezenas de programas antigos.


Matrix

Em vez de reconstruir toda a Matrix.

O Arquiteto cria uma nova versão.


Terceiro Pilar — L

Liskov Substitution Principle (LSP)

Criado por Barbara Liskov, vencedora do Prêmio Turing.

A ideia.

Componentes derivados devem poder substituir seus componentes originais sem quebrar o sistema.


Mesmo em COBOL.

Isso significa.

Módulos equivalentes devem respeitar os mesmos contratos.


Matrix

Se Neo substitui um operador da Matrix.

O restante não deve perceber.


Quarto Pilar — I

Interface Segregation Principle (ISP)

Não obrigue consumidores a depender de funcionalidades que não utilizam.


Exemplo

Uma API com:

300 operações.

Quando seu programa usa apenas duas.


COBOL

COPYBOOK gigantesco.

Quando o programa utiliza apenas cinco campos.


Matrix

Neo recebe um painel com mil botões.

Mas usa apenas três.


Quinto Pilar — D

Dependency Inversion Principle (DIP)

Módulos de alto nível não devem depender diretamente dos de baixo nível.

Ambos devem depender de abstrações.


COBOL

Em vez de acessar diretamente um arquivo específico.

Criar uma camada de acesso.


Matrix

Neo não precisa saber onde está cada cabo da Matrix.

Ele conversa com interfaces.


O efeito psicológico

Programadores iniciantes gostam de resolver problemas rapidamente.

Programadores experientes pensam.

"Como alguém manterá isso daqui a dez anos?"

Essa é a essência do SOLID.


O Programador COBOL Padawan

Você recebe um programa com:

18 mil linhas.

120 PERFORMs.

90 IFs.

40 GO TO.

Depois pergunta.

— Podemos dividir?

Resposta.

"Não mexe."

SOLID começa exatamente aí.


O Agente Smith odeia SOLID

Porque SOLID reduz:

  • duplicação;

  • acoplamento;

  • bugs;

  • retrabalho.

Quanto melhor a arquitetura.

Menos espaço existe para o caos.


Matrix Reloaded

Observe.

O Oráculo.

O Arquiteto.

O Chaveiro.

Cada personagem possui uma responsabilidade clara.

Nenhum tenta fazer o trabalho do outro.

Essa divisão é um excelente exemplo do primeiro princípio.


SOLID no universo IBM Z

Embora muitos associem SOLID apenas a Java ou C#, seus conceitos aparecem naturalmente no ecossistema IBM Z.

Por exemplo:

SRP

  • Programas COBOL menores.

  • Serviços CICS especializados.

  • Jobs batch com uma finalidade clara.

OCP

  • Inclusão de novos produtos por parametrização.

  • Novos módulos de cálculo.

  • Regras externas em tabelas.

LSP

  • Subprogramas intercambiáveis.

  • APIs mantendo contratos compatíveis.

  • Serviços reutilizáveis.

ISP

  • COPYBOOKs específicos.

  • APIs enxutas.

  • Mensagens MQ contendo apenas o necessário.

DIP

  • Camadas de acesso ao Db2.

  • Encapsulamento de VSAM.

  • APIs REST desacoplando consumidores da implementação interna.


Curiosidade

Uncle Bob nunca afirmou que SOLID resolve todos os problemas.

Na verdade.

Ele sempre reforçou que princípios são ferramentas de raciocínio.

Não regras absolutas.


Atenção!

Aplicar SOLID em excesso também pode gerar problemas.

Sistemas pequenos.

Podem tornar-se desnecessariamente complexos.

O segredo.

É equilíbrio.


SOLID conversa com toda esta série

Observe como os princípios estudados anteriormente convergem naturalmente para SOLID.

KISS

Ajuda o SOLID a permanecer simples.


DRY

Evita duplicação entre responsabilidades.


YAGNI

Impede abstrações desnecessárias.


Lava Flow

É reduzido por módulos pequenos.


Spaghetti Code

Desaparece quando responsabilidades são claras.


God Object

É praticamente o oposto do SRP.


Lasagna Code

É combatido quando abstrações possuem propósito.


Ferramentas ajudam

Hoje temos:

  • SonarQube.

  • IBM ADDI.

  • COBOL Check.

  • Enterprise Analyzer.

  • Architecture Decision Records (ADR).

  • Revisões de Código.

Todas ajudam a medir qualidade arquitetural.


O papel da IA

A IA consegue:

  • sugerir refatorações;

  • dividir módulos grandes;

  • detectar responsabilidades misturadas;

  • localizar acoplamentos.

Mas apenas arquitetos humanos compreendem profundamente o domínio do negócio.


Os riscos

Ignorar SOLID gera:

  • programas gigantes;

  • manutenção cara;

  • regressões;

  • dificuldade de testes;

  • baixo reaproveitamento;

  • arquitetura rígida.


Erros clássicos

  • Um programa faz tudo.

  • Alterar código antigo continuamente.

  • Interfaces enormes.

  • Dependências diretas.

  • Acoplamento excessivo.


Boas práticas

  • Dividir responsabilidades.

  • Criar contratos claros.

  • Favorecer composição.

  • Reduzir acoplamento.

  • Escrever módulos pequenos.

  • Refatorar continuamente.

  • Documentar decisões arquiteturais.


Um exemplo inspirado na Matrix

Imagine construir Zion.

Uma única pessoa seria responsável por:

  • energia;

  • defesa;

  • alimentação;

  • medicina;

  • transporte.

Parece absurdo.

Mas muitos sistemas são exatamente assim.


O ensinamento do Oráculo

O Oráculo leva Neo até as cinco colunas novamente.

Depois remove uma delas.

Toda a estrutura começa a vibrar.

Ela pergunta.

— Qual era a mais importante?

Neo observa.

Depois responde.

— Nenhuma.

Todas.

Ela sorri.

"Grandes sistemas não sobrevivem por causa de um único princípio. Eles sobrevivem pelo equilíbrio entre todos eles."


Lições para um Programador COBOL Padawan

Ao longo da sua carreira, você perceberá que escrever um programa que funcione é apenas o primeiro passo.

O verdadeiro desafio é escrever um programa que continue funcionando e possa evoluir durante vinte ou trinta anos.

Sempre que iniciar uma nova funcionalidade, faça algumas perguntas:

  • Este programa possui apenas uma responsabilidade?

  • Posso adicionar novas funcionalidades sem alterar tudo?

  • Estou respeitando contratos existentes?

  • Minha interface é realmente necessária ou ficou grande demais?

  • Estou acoplado diretamente a detalhes de implementação?

Essas perguntas farão enorme diferença quando o sistema crescer.


Curiosidades

Embora SOLID tenha sido popularizado na orientação a objetos, seus princípios influenciaram:

  • Arquitetura Hexagonal.

  • Clean Architecture.

  • Domain-Driven Design.

  • Microsserviços.

  • APIs REST.

  • Engenharia de Software Ágil.

  • DevOps.

  • Engenharia de Plataformas.

Todos compartilham a mesma ideia:

software preparado para mudança.


Conclusão — Os Cinco Pilares Que Mantêm a Matrix de Pé

Quando Neo entrou no núcleo da Matrix, imaginou encontrar máquinas extraordinárias.

Em vez disso, encontrou cinco princípios.

Foi uma metáfora poderosa.

Na Engenharia de Software acontece exatamente o mesmo.

Ferramentas mudam.

Linguagens evoluem.

Frameworks surgem e desaparecem.

Mas princípios sólidos continuam relevantes por décadas.

Para um Programador COBOL que trabalha com IBM Z, isso significa escrever programas claros, bem divididos, desacoplados e preparados para evoluir conforme o negócio muda.

SOLID não é uma receita pronta.

É uma forma de pensar.

Uma forma de projetar sistemas que resistem ao tempo, às mudanças de requisitos e às inevitáveis transformações tecnológicas.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria gravada nas colunas do núcleo da Matrix:

"Tecnologias envelhecem. Frameworks desaparecem. Linguagens evoluem. Mas sistemas construídos sobre princípios sólidos continuam sustentando o mundo muito depois de seus criadores terem deixado o teclado."

Porque, no fim, o verdadeiro Escolhido não é quem escreve o código mais complexo.

É quem constrói software que a próxima geração conseguirá compreender, evoluir e manter vivo por muitas décadas.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...