 |
| The Duck Tape Programmer Foto: Graeme - New Zealand |
A POG, Programação Orientada a Gambiarra, possui diversas formas de implementação.
A escolha da abordagem mais adequada, é geralmente na base do que funcionar primeiro. Por incrível que pareça, na programação POG, o que vale nem sempre é o menor esforço, pois o que está em jogo é o resultado e não a capacidade do programador entender o que está fazendo. Isto inclui também, os misteriosos problemas no kernel ou nas ferramentas de desenvolvimento e softwares de terceiros, para os quais, nem sempre o fabricante fornece suporte adequado.
Vejamos alguns dos tipos de POG mais encontrados:
FORCEPS
De fácil compreensão, esse recurso é largamente utilizado, caso um valor não seja atribuído a sua variável durante a execução de um programa por algum problema desconhecido pelo programador POG. Assim em vez de perder horas e horas debugando um programa, através do altíssimo nível de programação orientada a gambiarra, o programador POG atribuiu um valor na base da porrada e o programa roda livre e sem bugs. É claro que de tempos em tempos esse pequeno ajuste deve ser mantido.
Programação Orientada a Estagiário
Consiste na capacidade do analista de sistemas sobrecarregar o estagiário ou o técnico mais próximo com todas as suas funções, desde interação com clientes até desenvolvimento de casos de uso e bancos de dados, aproveitando ao máximo toda a energia gambiarrizadora que essas categorias possuem. Sabendo que fica mais fácil para o programador entender e realizar a POGização do sistema se ele conversar diretamente com o usuário, o analista sabiamente permite que o programador realize os contatos com o cliente, permitindo assim que o analista realize funções que condizem mais ao seu cargo, como acessar a desciclopédia, ficar o dia inteiro na cantina ou ir puxar o saco do chefe, por exemplo. Além do mais, o contato do programador com o usuário economiza papel e tinta de impressora, pois a parte da documentação impressa é nula, já que o analista não participa do processo e assim não gera as toneladas de folhas com diagramas e especificações. O acoplamento do sistema é muito maior, pois foi desenvolvido por uma única pessoa, facilitando na manutenção, pois existem poucas classes para serem modificadas (no máximo cinco, para programas muito complexos).
Apellation Number Technic
É um método muito utilizado por MVP's (MOST VALUABLE POGrammer), que resolve 90% dos BUGs sem que precise queimar nenhum neurônio. POGramadores experientes sabem que: Deu um BUG no sistema? Digita -1 em algum lugar que funciona!!! Ainda não se sabe o motivo, e nem precisa saber. apenas funciona e pronto.
Static Spree
Um dos patterns mais utilizados da POG. O objetivo desse padrão é que tudo fique visível em qualquer canto, porque private é coisa de gente sem vergonha. Também conhecido por Public Static Spree, pois comumente tudo é feito "public static".
 |
| Imagem: Dom Herms |
Pattern que simplifica o desenvolvimento eliminando todos aqueles métodos de acesso inúteis, tornando todos os atributos acessíveis globalmente, diminuindo a quantidade de lixo no código. Apesar da semelhança com o Static Spree, os atributos não precisam ser static.
RCP Pattern
Significa Reuse by Copy-and-Paste (Reúso por Copiar e Colar). O RCP dita que, na pressa, quando não dá pra fazer a coisa por herança, basta copiar e colar, quantas vezes for necessário. Em geral se espera que futuras alterações sejam feitas por outros trouxas, digo programadores, perdão. Os trechos de código são copiados de todo e qualquer lugar possível, geralmente de outro programador (muitas vezes o estagiário) ou código da internet, para criar partes funcionais do programa. Utiliza-se a do "Ctrl+C" e "Ctrl+V" para juntar as partes e adaptá-las para funcionar, por tentativa e erro. Leva um considerável tempo para se adaptar o programa, e um número absurdo de compilações, mas pelo menos pode-se dizer que foi você quem fez o código. Este pattern também é conhecido como "Contra o C e Contra o V".
BCDR Pattern
Black Cat in a Dark Room (Gato Preto em um Quarto Escuro). Consiste em criar métodos que recebem apenas um parâmetro (um Map em Java ou um params em .NET). O argumento que você precisa está lá dentro, mas você não sabe exatamente onde. Esse padrão permite passar quantos argumentos forem necessários a um método, sem poluir o código. Permite criar métodos cujas assinaturas seriam, de outra forma, extremamente longas . Evita a alteração de assinaturas de métodos no momento da manutenção do código, fazendo desnecessário qualquer tipo de refactoring.
Há registro de programadores de Black Cat in a Dark Room. Um exemplo complementar é o parâmetro String[]:
Um exemplo prático é o sistema de gerência de Mensagens do Windows.
User Friendly Exception
Consiste na padronização de todas as mensagens de erro do sistema para uma única mensagem amigável ao usuário. Um sistema 100% compatível com esse padrão, nunca trava nem encerra de forma inesperada, mas apenas não atende ao usuário exibindo uma mensagem do tipo "Caro usuário, tente novamente observando as regras de uso do sistema". Observação: Trata-se da evolução de um padrão amplamente utilizado em sistemas Microsoft com mensagens "Catastrophic Failure" e "Unexpected Error".
Exemplo de implementação em Java:
public static void main(String[] args){
while (true) {
try {
...
} catch (Throwable ex) { // qualquer erro do sistema cai aqui
// só pode ser culpa da besta ignorante do usuário
System.out.println("Caro usuário, tente novamente observando as regras de uso do sistema");
// após a mensagem, o while(true) garante a robustez do sistema que nunca aborta!
}
}
}
Chaotic Experimentation
Padronização de construção de funções para continuar a executar o programa mesmo que dê pau em alguma rotina. Exemplo clássico: On Error Resume Next (Visual Basic).
Controller Confusion
Tática que permite uma menor escrita de classes no sistema. Consiste simplesmente em eliminar o M do padrão MVC, ficando um padrão muito mais legal - o VCC ("View/Controller Confusion", ou "Vai catar coquinho"). Alguns tem sugerido inclusive a eliminação do V - ou seja, ficando apenas o CC (Codigo coco para os usuarios mais intimos) - a lógica, o modelo, os templates, o HTML, tudo e mais um pouco dentro do controller confusion. Como você pode ver, o padrão cêcê faz jus ao nome.
N.M.L. Combat Action POG Pattern
É um Design Pattern POG ousado, moderno, revolucionário e NÃO-EMO. Os arquitetos emos e POGuistas ADORAM, junto com seus miguxus, incrementar suas frameworks utilizando MUITAS camadas, geralmente desnecessárias. A N.M.L. (No More Layers) aborda uma estrutura onde todas as regras de negócio, validação (client e server side) e acesso à dados estão na tela! Para que Facades, Commands, Bussines Delegate e outras viadagens EMO detonando a performance da aplicação? Manutenção? Não é necessário, pois quem domina e faz uso dessa técnica modesta e humilde produz códigos Chuck Norris Style, ou seja: PERFEITOS. Esse paradigma está amplamente difundido por programadores VB e Delphi, e tem migrado com sucesso para a plataforma .NET, porque o que importa é a beleza da tela, e não a tecnologia que está por trás!
UFB -Uso de Força Bruta
Método muito famoso no meio dos programadores POG.
O método se aplica para solucionar problemas sem perder tempo voltando no código para procurar onde deu errado.
while (true) {
try {
...
} catch (Throwable ex) { // qualquer erro do sistema cai aqui
// só pode ser culpa da besta ignorante do usuário
System.out.println("Caro usuário, tente novamente observando as regras de uso do sistema");
// após a mensagem, o while(true) garante a robustez do sistema que nunca aborta!
}
}
}
Chaotic Experimentation
Padronização de construção de funções para continuar a executar o programa mesmo que dê pau em alguma rotina. Exemplo clássico: On Error Resume Next (Visual Basic).
Controller Confusion
Tática que permite uma menor escrita de classes no sistema. Consiste simplesmente em eliminar o M do padrão MVC, ficando um padrão muito mais legal - o VCC ("View/Controller Confusion", ou "Vai catar coquinho"). Alguns tem sugerido inclusive a eliminação do V - ou seja, ficando apenas o CC (Codigo coco para os usuarios mais intimos) - a lógica, o modelo, os templates, o HTML, tudo e mais um pouco dentro do controller confusion. Como você pode ver, o padrão cêcê faz jus ao nome.
N.M.L. Combat Action POG Pattern
É um Design Pattern POG ousado, moderno, revolucionário e NÃO-EMO. Os arquitetos emos e POGuistas ADORAM, junto com seus miguxus, incrementar suas frameworks utilizando MUITAS camadas, geralmente desnecessárias. A N.M.L. (No More Layers) aborda uma estrutura onde todas as regras de negócio, validação (client e server side) e acesso à dados estão na tela! Para que Facades, Commands, Bussines Delegate e outras viadagens EMO detonando a performance da aplicação? Manutenção? Não é necessário, pois quem domina e faz uso dessa técnica modesta e humilde produz códigos Chuck Norris Style, ou seja: PERFEITOS. Esse paradigma está amplamente difundido por programadores VB e Delphi, e tem migrado com sucesso para a plataforma .NET, porque o que importa é a beleza da tela, e não a tecnologia que está por trás!
UFB -Uso de Força Bruta
Método muito famoso no meio dos programadores POG.
O método se aplica para solucionar problemas sem perder tempo voltando no código para procurar onde deu errado.
...
if (var==20)
ChamaMetodoSolucao(var);
else
{
var=20;
ChamaMetodoSolucao(var);
}
Strombolic Bridge (ou, DRIBLE DA VACA)
O Paradigma Strombolic Bridge (Ponte Estrombólica) ou mais conhecido no Brasil pelo Pseudonome de "Drible da Vaca" é uma evolução do já consagrado BRUTE FORCE. Consiste em alimentar uma variável global que será utilizada dentro de algum método, mas certificando-se de que seu valor inicial será retornado ao original após o uso dela pelo método. Por exemplo:
ChamaMetodoSolucao(var);
else
{
var=20;
ChamaMetodoSolucao(var);
}
Strombolic Bridge (ou, DRIBLE DA VACA)
O Paradigma Strombolic Bridge (Ponte Estrombólica) ou mais conhecido no Brasil pelo Pseudonome de "Drible da Vaca" é uma evolução do já consagrado BRUTE FORCE. Consiste em alimentar uma variável global que será utilizada dentro de algum método, mas certificando-se de que seu valor inicial será retornado ao original após o uso dela pelo método. Por exemplo:
varTemporaria = varOriginal;
varOriginal = "NovoValor";
Executa(varOriginal);
varOriginal = varTemporaria;
Reparem que, tal como o "Drible da Vaca":
- A varOriginal dá um 'totózinho' lateral do seu valor para a variável temporária,
- Recebe o novo valor que será utilizado pelo método,
- (corre) e recebe de volta seu valor la na frente...
Não tem erro.... assim você sempre terá certeza que o valor original será sempre o mesmo !!!
Space Kick Pattern
Consiste em ir chutando pro espaço, até acertar e a coisa dar certo!
Abstract Observer Pattern
Método para dar manutenção em código POG. Você observa um monte de gambiarra, mas abstrai e considera a coisa como funcional.
varOriginal = "NovoValor";
Executa(varOriginal);
varOriginal = varTemporaria;
Reparem que, tal como o "Drible da Vaca":
- A varOriginal dá um 'totózinho' lateral do seu valor para a variável temporária,
- Recebe o novo valor que será utilizado pelo método,
- (corre) e recebe de volta seu valor la na frente...
Não tem erro.... assim você sempre terá certeza que o valor original será sempre o mesmo !!!
Space Kick Pattern
Consiste em ir chutando pro espaço, até acertar e a coisa dar certo!
Abstract Observer Pattern
Método para dar manutenção em código POG. Você observa um monte de gambiarra, mas abstrai e considera a coisa como funcional.
------------------------------------------------------------------------------------------------------
O texto acima está com algumas pequenas modificações e acréscimos feitos por mim. O original foi encontrado no Blog Mundo .Net do Constantine
.'.
