Gambi Design Patterns

Origem: Desciclopédia, a enciclopédia livre de conteúdo.
Ir para: navegação, pesquisa


Atenção: Este artigo, de forma semelhante aos programas que ele descreve, cresceu e sofreu modificações de forma desordenada e desorganizada, por autoria de diversas pessoas. O resultado é que este artigo é excessivamente longo, pesado e desestruturado, exatamente como qualquer programa que segue a metodologia POG. Este artigo precisa ser refatorado em artigos menores, mas nenhum dos POGramadores que são autores dele têm tempo ou vontade de fazer isto, preferindo seguir os conceitos da POG e ficar apenas remendando-o e inchando-o cada vez mais.

Índice

Padrão de Projeto Gambis[editar]

As Soluções Técnicas de Contorno / Engenharias de Emergência ou Solução Criativa (aka. gambiarras) podem ser aplicadas de várias formas. No entanto, não há ainda consenso entre desenvolvedores e analistas acerca de padrões de projeto para desenvolvimento orientado a gambiarras. Uma prática muito comum é criação de uma entidade específica, com o intuito único de prover uma funcionalidade emergencial a um sistema. Não são raros os casos de utilização de classes "gambiarra.java", "agoravai.java", "funcionapeloamordedeus.java", métodos "void ajeita()", "public String bruto()" e afins. Em alguns casos, métodos com nome sofisticados como "setMagicOn()" e "setApellationMode(true)" também são utilizados para dar um ar mais profissional. Também para tornar o código mais amigável e legível alguns programadores fazem uso abusivo do MO de métodos, utilizando nomes como "check"(), "checka()", "xeka()" ou "pussy()". São os chamados Gambiwares, componentes de software que promovem a entrega de projetos com o mínimo de atraso possível.

Nesta técnica as linhas de comentário devem ser evitadas ou proibidas. Em caso de extrema necessidade o uso de línguas como hebraico ou tupi-guarani é recomendado.

A técnica mais usada pelos programadores POG é usar sempre softwares que fazem todo serviço para ele e, claro, o Google para pegar scripts prontos e usar. Os programadores POG sempre são mais rápidos que o normal e cobram mais barato, enquanto que os outros programadores precisam cobrar mais caro pelo serviço porque eles sempre se enrolam e não conseguem entregar nada no prazo.

As métricas e estimativas da Programação Orientada a Gambiarras provêm das metodologias de medição de software denominadas Conceito Holístico Unilateral para Tipificação Estrutural, mais conhecido pela sua abreviação: C.H.U.T.E. e Cálculo Hipotético Usando Técnicas Estatísticas, mais conhecido pela sua abreviação: C.H.U.T.E..


Gambi Design Patterns catalogados[editar]

Best-seller da O'Reilly no mercado brasileiro. Note o animal tipicamente nacional: a Anta

Zé do Caixão, ou "À Meia Noite Rodarei o teu Script"[editar]

É o tipo de código que faz um bocado de absurdos, como apagar logs e outros arquivos que possam comprometer o desenvolvedor do sistema (que por "acaso" é uma merda), todo dia à meia noite. Em alguns casos, é tão subversivo, que funciona como um vírus, e é possível que alguns antivírus detectem como tal.

Global Manual Counter[editar]

Padrão aplicado para quem não conhece variaveis globais (ou não consegue aplica-las em sua linguagem). Trata-se de criar uma classe utilizada só para contar. Ex:

class contador{
  public static $c = 0;
}

Para utilizar:

echo contador::$c++;

1234 Reorder[editar]

Código feito para quem precisa inverter a string "1234"! Muito comum hoje, nas provas seletivas em empresas. SIM ESTE CÓDIGO ESTAVA EM UMA PROVA!

funtion string Inverte_valor()
{
    string valor;
    valor = "1234";
    return "4321";
}

Programação Keep Walking[editar]

É um estilo de produção de código rápido. O código de 10 dias é gerado em alguns minutos, com lógica avançada e estrutura complexa. Talvez não funcione. Uma das característica desse estilo é a frequente reinvenção da roda e substituição de variáveis por letras do alfabeto. Exemplo:

// conta itens
$c = 0;
foreach($a as $val){
 $c++;
}
return $c;

Transformer Integer[editar]

Questão de uma prova VB6:

Conforme as variáveis declaradas abaixo:

Dim x, y as integer

Determine quais são os tipos de x e y.

Conforme os novos padrões de desenvolvimento, patches aplicados no VB6 e plugando um controle de play no pc, basta abrir a IDE ligar o controle e dar meia lua + X, para essa variável virar uma STRING!

Encapsulation[editar]

O usuário não precisa saber o que está acontecendo, algo não precisa acontecer, precisa parecer que acontece. Você não precisa apagar um objeto, mas sim deixá-lo invisível, ou mudar sua posição para um lugar "invisível" ao usuário.

-Exemplo em HTML misturado com flash

< form type="Button" name="apagar" function=apaga() >
  function apagar={
  desenho._y=40000000000 //* aposição em y do desenho
  }
< /embed>

selfLang[editar]

Caso você esqueça uma função que você irá precisar, faça a sua própria função: -Exemplo para converter um número digitado numa caixa de texto em número mesmo

if(t=="1"){
  tnúmero=1;
  acheiONumeroPorra="sim";
}if(t=="1"){
  tnúmero=1;
  acheiONumeroPorra="sim";
}if(t=="2"){
  tnúmero=2;
  acheiONumeroPorra="sim";
}if(t=="3"){
  tnúmero=3;
  acheiONumeroPorra="sim";
}
...
if(t=="infinito"){
  tnúmero=infinito;
  acheiONumeroPorra="sim";
}
else{
  acheiONumeroPorra="nao";
  aPorraDoUsuarioNãoDigitouUmNumero="sim"
}

Conversão de Tipos[editar]

Convertendo uma string para integer em VB (Acredite, isso é um exemplo real!)

   Dim numeroParcelas As Integer

   Select Case codInstallmentsComboBox.Text
                Case "1"
                    numeroParcelas = 1
                Case "2"
                    numeroParcelas = 2
                Case "3"
                    numeroParcelas = 3
                Case "4"
                    numeroParcelas = 4
                Case "5"
                    numeroParcelas = 5
                Case "6"
                    numeroParcelas = 6
   End Select
   ' ARRUMAR
   ' tem que fazer ate 240, fiz ate 6 pq eh o mais comum

Pattern Exception Success[editar]

O tratamento de exceções é uma construção incluída em linguagens de programação modernas que é mais adequada para controlar fluxo de resultados excepcionais. Como o algoritmo que você bolou não funciona mesmo, a execução com sucesso é um resultado excepcional, e por este motivo quando uma operação é executada com sucesso, uma exceção é lançada. Em especial, é altamente recomendado o uso de exceções para controle de fluxo em lugar de outras estruturas mais arcaicas como ifs, whiles e returns. Por exemplo:

 public static void somar(int a, int b) {
   System.out.println(a+b);
   throw new RuntimeException("Operação realizada com sucesso!");
 }

Abaixo, um exemplo real, mostrando uma variação deste método:

if (!request.getSession(true).getAttribute("TipoUsuario").toString().equals("1"))
   throw new Exception("<span style=\"color:#ff0000;\"><b><u>Acesso negado</u>:</b> somente usuários com perfil de "+
"administrador podem ter acesso a esta página.</span>");

No código acima, quando o usuário autenticado não for um administrador, é lançada uma exceção cuja mensagem é exibida pelo catch, já devidamente formatada em HTML.

Sleeper / Human Factor[editar]

Imagine que o POGramador precise criar uma tela que mostre o progresso de uma operação. Um problema muito comum é que determinadas operações executam muito rápido, impedindo que o usuário veja a tela de progresso. Então, para que o usuário tenha a certeza de que algo está sendo executado, o algoritmo é modificado intencionalmente para que este execute de forma mais ineficiente. Este pattern também é conhecido como Human Factor, pois é nada mais que uma tentativa de demonstrar o esforço computacional de uma tarefa em uma medida humanamente perceptível, implementando avançados conceitos de usabilidade. Isso prova que, ao contrário dos programadores convencionais, os programadores POG pensam no bem-estar dos seus usuários.

public class MedidorDePOGresso implements Runnable {
   public void run() {
      while (true) { // Até terminar o processo..
        
         // Realiza um processamento rápido aqui...

         try {
            Thread.sleep(1000); // ... e ferra com a performance aqui
         }
         catch (InterruptedException exc) {}

         // Atualiza a ProgressBar
         progress.setValue(blablabla.getPorcentagem());
     }
   }
}

Abaixo segue um exemplo real. O detalhe é que, originalmente, ele tinha sido implementado sem o sleep, o que foi adicionado posteriormente sob solicitação dos usuários:

    public function action_sortear(){

        //aqui você implementa o eficiente algoritmo de sorteio de Fisher–Yates O(n)
        $this->realizarSorteio();

        //aqui você leva em conta o fator humano
        sleep("5");

        $this->request->response = View::factory('sorteio_realizado');
    }

QPÉ[editar]

Mais conhecido como "Que p* é essa!?" ou ainda WTF (What'a'fuck) ou WTH (What'a'hell). É aquele código que você sabe como funciona, mas depois do resultado pronto olha para aquela merda e não quer nem saber como vão dar manutenção depois! Exemplo:

"/ .*?<  ".replaceAll("","").trim();

Outro exemplo interessante retirado de um sistema real em produção.

private static void setDayOfMonth(Calendar calendar, int day)
    {
        calendar.setLenient(false);
        
        Date date = null;
        int offset = 0;
        while (date == null)
        {
            calendar.set(Calendar.DAY_OF_MONTH, day - offset);
            try
            {
                date = calendar.getTime();
            }
            catch (IllegalArgumentException e)
            {            	
            	System.out.println("offset = " + offset);
                offset++;                
            }
        }        
    }

FORCEPS[editar]

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.

/* Variável é inicializada */
String valor = "123";

/* ... lógica do programa ... */

/* Dentro de um método que utiliza a variável 'valor' */
if(valor != "123"){
    valor = "123";
    processaValor(valor);
}

Método Philber para Debug[editar]

Se há um erro na linha 10, remova a linha 10.

Método Sokoban para Debug[editar]

(Lembra do joguinho "Sokoban"? Onde vc tinha q empurrar umas caixas?)

Se você aplicar o Método Philber e remover a linha 10, o erro vai para a linha 11. Aplique o Método Philber novamente e remova a linha 11 e assim por diante. Inadvertidamente, uma hora o programa vai ficar sem bugs.

M.A.R.R.E.T.A.[editar]

Método Alternativo de Ratificação e Resolução Emergencial de Tarefas Abortadas. Conhecido pelos americanos como "workaround", nem os POGramadores mais respeitados admitem usá-lo com regularidade, pois se trata de uma solução hardware para um problema de software, usada principalmente quando o POGramador defronta-se com a Tela Azul da Morte. Ela conta com o princípio de que muitos computadores são habitados por espíritos malignos (ou folgados mesmo: ver Fé em Deus neste artigo). Trata-se de certificar-se que ninguém está olhando (nem o peixinho do aquário), correr até a manutenção (ou cozinha), pegar o instrumento mais destrutivo que aparecer, voltar para o PC e ameaçá-lo da forma mais intimidadora possível (se tiver uma fantasia de Conan, o Bárbaro, use-a, é extremamente eficaz). Inclua na ameaça uma contagem regressiva longa o bastante para o computador entender a ameaça e curta o bastante para deixá-lo em pânico, como 3,1415 segundos. Eficaz em 99,9999% dos casos. No restante, a falha ocorre geralmente porque o POGramador apressado trocou o martelo por um batedor de ovos, tendo sucesso apenas em pagar um bruta mico.

Programação Orientada a Estagiário[editar]

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 criaturas 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 ou ficar o dia inteiro na cantina, 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).

Nem-rela[editar]

Padrão avançado de configuração e resolução de problemas que, quando aplicado, nem o usuário, programador, chefe ou a secretária sabe porque tudo voltou a funcionar depois de um reboot no servidor, de remover algumas linhas que estavam comentadas ou até mesmo depois de setar uma variável pra null. O padrão nem-rela é amplamente utilizado, principalmente em trocas de arquivos dentro da própria empresa ou em locais onde a utilização de SVN (sistema versionador de nada) é comum. Caso o padrão nem-rela não for aplicado com rigor após tais ocorrências, o sistema entrará em colapso generalizado. Isso inclui cancelar atualizações do servidor, esconder a pasta do projeto, cortar relações de manutenção com o cliente. Tudo para não ter que mexer novamente no código. Esse padrão é crítico: caso não seja respeitado, poderá acarretar a demissão de diversos POGramadores.

ATE[editar]

Artificio Técnico de Emergência (Dispensa comentários)

WYSIWYG[editar]

Também conhecido por what you see is what you get (o que você vê é o que você tem), esse nesse caso você começa um sistema fazendo uma única tela de cadastro (somente inclusão), sem a menor consistência de campos e já disponibiliza para o usotário digo usuário, e diz para ele ir cadastrando enquanto você termina o resto do sistema e libera os módulos de relatórios. Combinado com a técnica de fazer menus utilizando a técnica, wysiNwyg what you see is NOT what you get (o que você vê é o que você NÃO tem / ou nunca vai ter), você disponibiliza um menu cheio de opções e sub-menus para o usuário vislumbrar a totalidade do sistema. Não se esqueça de colocar em cada item a mensagem "Disponível na versão premium".

Else Forever[editar]

Pattern que visa facilitar o perfeito entendimento de um operador condicional, com o avançado uso do ELSE. Seu princípio básico é: "CONDIÇÃO QUE DEFINE SE UMA COISA OU OUTRA SEMPRE IRÁ ACONTECER". Sua aplicação é muito simples (utilização do else), porém o entendimento obtido é total, visto que não fazer nada, também é tomar uma ação. (Ex: deputados, senadores, etc).

Resumo:

O entendimento se resume a:

Sempre que uma condição for testada duas coisas podem acontecer: 
(1) - Se a condição for verdadeira : Uma ação é realizada.
(2) - Senão : outra ação é realizada.

Utilização Recomendada do Else Forever:

    ...
    ...
    -- Observe o algorítimo abaixo:    
    IF x = true THEN
       realiza ação Y 
    END IF
    
    Este algoritimo poderia ser lido da seguinte forma:
    "Se x for verdadeiro, então realiza ação Y e fim"
    
    -- porém o patern 'Else Forever' vem mostrar que isto está errado, pois você lembra
    da definição "(2) - Senão : outra ação é realizada.", então cade a outra ação?
    ...
    ...
    A forma correta seria:
    IF x = true THEN
       realiza ação Y 
    ELSE
       não faça nada
    END IF    
    
    Desta forma é mostrada claramente a fundamental importância da utilização do 
    comando ELSE para estes casos, visto que não fazer nada, também é tomar uma ação.

    Uma forma alternativa seria:

    IF x = false THEN
       não faça nada
    ELSE
       realiza ação Y 
    END IF  

Static Spree[editar]

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".

Big This[editar]

Técnica muito útil principalmente em Java. Use ela quando é necessário utilizar a classe acima de uma superclasse, exemplo retirado de aplicação real:

class GUI {
  GUI() {
    bigThis = this;
    //...
  }
  //...
  private JMenuItem getJMenuItem14() {
    if (jMenuItem14 == null) {
      jMenuItem14 = new JMenuItem();
      jMenuItem14.setText("OPEC");
      jMenuItem14.addActionListener(new java.awt.event.ActionListener() {
         public void actionPerformed(java.awt.event.ActionEvent e) {

           //NOTA: o this aqui nao é o this que eu quero.
           //Não gosto de "GUI.this" porque não sei usar isso.
	   Localizar l = new Localizar("OPEC", fx,bigThis);

	   JInternalFrame ifr = new JInternalFrame();
	   ifr.setContentPane(l.getJPanel());
	   ifr.setSize(l.getJPanel().getSize());
	   jDesktopPane.add(ifr);
	   ifr.setClosable(true);
	   ifr.setTitle("Buscar OPEC");
	   ifr.setVisible(true);
        }
       });
      }
      return jMenuItem14;
  }
  //...
}

Public Global Access[editar]

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.

Lone Wolf[editar]

Também conhecido por Highlander (só pode haver um), esse é a boa e velha "classe-faz-tudo". O sistema todo está concentrado numa 'classe procedimental' que faz tudo, geralmente usando o padrão Static Spree.

Generic processor[editar]

Alguma classe que recebe qualquer coisa como parâmetro e que faz alguma ação genérica dependendo de mais e mais dessa classe geralmente tem mais parâmetros que o seu monitor é capaz de exibir.

The Hitchhiker's Guide to the Galaxy (Mochileiro das Galáxias)[editar]

Também conhecido como Jornada nas Estrelas ou Across the Universe.

Um objeto que atravessa todo o sistema, do banco de dados à interface, da rede ao sistema de arquivos, sem sofrer NENHUMA transformação. Não importa em que lugar, em que módulo, em que camada você esteja, o mochileiro está lá, sabe Zahl porque...

Quando você deleta o arquivo tudo para de compilar, da interface ao código de banco e dados, e até o Microsoft Word passa a dar problemas estranhos.

Old Times of Yore Pattern[editar]

É bastante usado quando o gambiarrizador não se lembra de algumas operações matemáticas a serem implementadas. Geralmente são algumas das operações que aprendeu na Universidade.

Apenas gambiarrizadores de nível Genial ou maior conseguem fazê-lo, com a ajuda de um lápis com tabuada.

Exemplo:

/*Essa função soma dois termos, só que eu não sei somar!*/
int Eunaoseisomar(int a, int b) // e tem que ser INTEIRO, pois não sei usar fração também.
{   
    //Gambiarrizador baseou-se naquele lápis que tem a tabuada.
    
    if((a==0)&&(b==0))
        return 0;
    else if(((a==0)&&(b==1))||((a==1)&&(b==0)))
        return 1;
    else if(((a==0)&&(b==2))||((a==1)&&(b==1))||((a==2)&&(b==0)))
        return 2;
    else if(((a==0)&&(b==3))||((a==1)&&(b==2))||((a==2)&&(b==1))||((a==3)&&(b==0)))
        return 3;
    else if(((a==0)&&(b==4))||((a==1)&&(b==3))||((a==2)&&(b==2))||((a==3)&&(b==1))||((a==4)&&(b==0)))
        return 4;
/*[...]
 *  .    Aqui eram todos as outras possibilidades que tinham no lápis. 
 *  .    
 *  .
 *[...]
*/   
    else  //caso o usuário tente botar número negativo
        printf("Para acesso à este recurso(soma de números negativos) é necessário um 
                Add-on, disponível na versão Premium deste software.");
}

Nonsense Flag[editar]

Por um legítimo impulso gambiarrizador solucionador de problemas, o desenvolvedor salpica um monte de variáveis com nomes sensacionais como "pepeJaTireiAVela", "newCounter2", "jaTrocouDeAba", "passouPorAqui", "numeroMagico", "naoAchou", "anterior5", "atual5","anteriorDoAnterior5", "quatroDaManha" (caso em que se aplica a técnica de Programação de Véspera).

UTF-8 Abuse[editar]

Esta gambiarra consiste no uso abusivo de acentuações em nomes de variáveis e métodos caso a linguagem suporte, como é o caso do Java e Scheme. Dane-se se você usa Windows com ISO e não aprendeu que o padrão mundial é UNICODE, dane-se a incompatibilidade com sistemas de controle de versão etc. O que importa é usar variáveis com acentuação correta, para se adequar à língua portuguesa e evitar o duplo sentido. Variáveis e métodos assim são altamente recomendados em POG:

  • (poderia ser confundido com "no")
  • faça() (poderia ser confundido com "faca", objeto cortante)
  • ação() (quanto mais acentos num mesmo símbolo melhor)

Se possível use também nome de classes com acentuação, assim:

  • ClasseNó
  • FaçaIssoJá

Exemplo de uso de caracteres Unicode para fazer seu código mais bonito:

public class 無 extends Exception { }

public class OperaçãoDeDivisão {
    int façaDivisão(int x, int y) {
        if (y == 0) {
             throw new 無();
        }

        return x / y;
    }
}

RCP Pattern[editar]

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[editar]

Black Cat in a Dark Room (Gato Preto em um Quarto Escuro). Consiste em criar métodos que recebem apenas um Map como parâmetro. O argumento que você precisa está lá dentro, no Map, 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 (vide padrão Generic Processor). 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[]: pode ser pior que o Map, pois normalmente consiste em um mix de tipos (String, int, etc).

Um exemplo prático é o sistema de gerência de Mensagens do Windows.

Uma variante deste padrão, utilizada muito na programação em Java para Web é a de passar apenas o objeto HttpServletRequest para todos os outros lugares do sistema (normalmente métodos estáticos, void e que não recebem nenhum outro parâmetro). Ao se utilizar dos métodos setAttribute e getAttribute para ler, inserir e alterar quaisquer parâmetros que forem necessários em qualquer parte da aplicação. Com isso cria-se um design simples e poderoso que reduz a necessidade de refatorações no futuro pois os parâmetros dos métodos jamais precisarão mudar nem é necessário se preocupar com o tipo de retorno de nenhum método.

Também muito utilizado em PHP, para que criar estruturas de dados se tudo pode ser feito com uma hashtable? Traz grande facilidade em resolver os problemas rápida e criptograficamente.


justKillIf[editar]

Quando a execução de uma função causa algum bug devido a um parâmetro ou evento, é feito o seguinte tratamento (também utilizando o Static Spree):

A função divide um número por i, não podendo vir 0

    if(i == 0)
         return;
    Divisao.resp = Classe.número/i;

este padrão de projeto ja foi utilizado com sucesso em aplicações para jogos de celular e existem outras inúmeras utilizações possíveis.

Mega Zord[editar]

Programadores dos anos 80 o conhecem como Daileon. Semelhante ao padrão Lone Wolf. Motivo: criar várias funções, cada uma executando um passo de um algoritimo, causam lentidão no sistema por este ter que interromper seu fluxo para chamá-las. Esse problema pode ser resolvido com uma única e gigante guerreira função, que recebe vários parâmetros que definirão o que esta deverá fazer. Geralmente usado em conjunto com Nonsense Flag.

Exemplo(Atenção! A quebra de linhas foi usada aqui apenas para melhor entendimento! Evite essa prática! Escreva os parâmetros e as exceções tudo em uma única linha para não comprometer a eficiência do código!!!):

 //Processa
 public static Object[] processar(String file, int dados, char variavel, Object[] status,
                                  int linhas, String query, String usuario, String senha,
                                  String banco, String host, int dia, int mes, int ano,
                                  Object[] entrada, Object[] saída, Object... maisDados)
       throws NullPointerException, ArrayIndexOutOfBoundsException, SQLException, IOException,
              OutOfMemoryError, FileNotFoundException, SocketException, MalformedURLException,
              ArithmeticException, UnknownHostException, SAXException, ParseException,
              ClassNotFoundException, StackOverflowError, ExceptionInInitilizerError,
              InvocationTargetException, SecurityException, ClassCastException,
              NoSuchMethodException, NoSuchFieldException, UnsatisfiedLinkError,
              InstantiationException, ArrayStoreException, IllegalArgumentException,
              NumberFormatException, AssertionError, InternalError, RemoteException,
              RuntimeException, Exception, UnknownError, Error, Throwable {
 
 //Aí é aquilo, mermão...
 ...
 ...
 return processado;
 }

Esse padrão também pode ser usado com SQL. SELECTs aninhados devem ser evitados pois diminui a eficiência, foda-se se ninguém entender que merda aquilo faz.


Thunder Mega Zord[editar]

Por vezes, o Mega Zord se mostra insuficiente para resolver uma série de problemas, e apesar da quantidade de parâmetros que o método recebe, sempre aparece mais um que não foi pensado, e daí, para não quebrar as interfaces os POGamadores são obrigados a adicionar mais um método, replicando o código anterior, etc. Para evitar esse retrabalho, POGamadores mais avançados aplicam o padrão Thunder atropelando esse bla bla bla de linguagem fortemente tipada ao combiná-lo com o Black Cat in a Dark room...

 //Processa
 public static Object[] processar(Map parametros) throws Throwable {
 //Aí é aquilo, mermão...
 ...
 ...
 return processado;
 }

There is No Spoon[editar]

Padrão para C/C++. Dar o mesmo nome aos arquivos .h e aos .c(pp) onde estão definidas as funções podem causar conflitos durante a compilação. Dar um nome diferente aos .c evita esse problema. Outro ganho é evitar com que os programadores percam tempo querendo saber como e onde aquelas funções is no function", onde toda a lógica é escrita em um único arquivo no corpo principal do programa ( main() no C++ e meinKempf() em Java), atingindo-se assim o ápice da eficiência computacional, denominado Sétimo sentido.

BaseBean[editar]

É um pattern avançado de POG, recomendado sempre que for necessário o máximo de reaproveitamento e flexibilidade sem perda de backward compatibility em processos iterativos. A primeira versão do sistema deve estar toda implementada na classe BaseBean, decomposta no maior número possível de métodos. Assim que for requisitada uma alteração ou nova funcionalidade, deve-se criar uma nova classe Bean2 herdando de BaseBean, sobrescrevendo alguns métodos existentes e adicionando novos métodos. As próximas alterações vão para a Bean3, Bean4,... (esses beans são mais conhecidos como POGBeans - from GoP - Gang of POG) e assim sucessivamente. Além das vantagens já citadas, essa técnica garante um mecanismo de controle de versões built-in.

Chain of Flags[editar]

Pattern viável em qualquer linguagem de programação. Consiste em inserir uma série n (onde n > 0) de ifs e else s para todas as possibilidades que satisfaçam uma condição. A medida que surgem novas possibilidades, basta acrescentar mais um if-else ao fim da estrutura. Se uma possibilidade desaparece, ela não precisará ser eliminada do código, afinal um dia ela poderá voltar mesmo. Caso a condição não seja satisfeita por nenhum dos if-else's, pode-se utilizar o padrão User Friendly Exception, descrito abaixo.

User Friendly Exception[editar]

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 não aborta nunca!
    }
  }
}

Um array vale mais que mil variáveis[editar]

A declaração de variáveis, na maior parte das linguagens de programação tende a ser uma tarefa tediosa e cansativa. É muito mais eficiente e fácil declarar um array com elementos suficientes para colocar todas as variáveis que o programador julgar necessárias. Ex:

public static void processaDados(Object[] dados) {
  ((Produto) dados[23]).setPreco((Float) dados[64]);
  ((Produto) dados[23]).setMargem((Float) dados[25]);
  ((Produto) dados[23]).setPrecoCusto((Float) dados[82]);
  ((Produto) dados[23]).setPromocao((String) dados[47]);
  ((Venda) dados[49]).addProduto((Produto) dados[23]);
  dados[51] = dados[44]; // Se não fizer isso dá pau.

  // O Marcão desativou essa linha e o bug da impressão de produtos arrumou,
  // mas a tela de funcionários ficou deslocada para a direita, ninguém sabe porque.
  //dados[88] = dados[21];
}

Deus Ex Machina[editar]

Deus Ex Machina é uma técnica avançada de proteção contra erros complexos que possam ameaçar a integridade do sistema. Quanto mais poderosa a plataforma utilizada, mais simples sua utilização. Consiste em passar a batata quente adiante sempre que houver alguma suspeita de que o código poderá causar erros imprevisíveis e portanto insolúveis por vias próprias. Neste caso apenas delegamos o controle a alguma entidade superior desconhecida que certamente será capaz de resolver o problema automaticamente.

É frequentemente antecedida por inúmeras tentativas frustradas por parte do desenvolvedor de ter alguma ideia do que raios está codificando. Ante o êxtase do insucesso, o profissional sucumbe a uma entidade superior que certamente existirá e resolverá tudo com certeza. Um exemplo clássico deste elegante pattern é o famoso "On Error Resume Next" da plataforma Visual Basic.

Timeline Relationship-Less[editar]

Este pattern consiste em não modelar seu banco de dados corretamente com as chaves estrangeiras (FKs) necessárias, pois tudo dá pra inferir através das datas dos registros. Exemplo: A tabela Order não precisa de uma coluna Visit_ID pois se um dia você quiser saber em QUAL visita o pedido foi feito, basta fazer um JOIN entre as tabelas com Order.dtOrder BETWEEN Visit.dtStart AND Visit.dtEnd.

Além disso JOINs com BETWEEN são altamente performáticos.

POGramadores plenos podem retirar relacionamentos entre Order e OrderItem por exemplo, afinal pela data em que o OrderItem foi inserido na tabela dá pra saber a qual pedido ele se refere, óbvio.

POGramadores senior podem retirar TODOS relacionamentos do banco e criar um aplicativo que rcode>FaçaIssob>b>b>Jáeconstrói todo o histórico de uso do aplicativo, de modo que os relacionamentos se tornam óbvios olhando o relatório. Além disso o seu gerente adora relatórios (e não entende relacionamentos), por isso vai adorar a ideia.

Generic-One-Table-Fits-All[editar]

Este pattern é muito inteligente, pois o pogueiro quando precisa criar uma nova entidade no banco de dados, ele olha as tabelas já existentes e procura aquela que já possui colunas parecidas.

Então funciona mais ou menos assim, você tem uma tabela chamada ProductClassification para armazenar classificações de Produtos, e a tabela tem campos ID e Description. Aí um belo dia você precisa criar uma tabela para classificar os clientes (CustomerClassification), mas pera lá.. ID e Description já existem na tabela ProductClassification? Então você aproveita a tabela existente e cria um novo campo chamado ClassifType indicando 1=Produto, 2=Cliente, 3=Qualquer outra coisa (este pattern é relacionado ao Polymorphic Confusion).

POGueiros avançados já modelam seus sistemas com tabelas genéricas como "Status" que servem para classificar dezenas de entidades diferentes, pois integridade referencial não é necessária se o código for bem feito (se bem que todos sabemos que ele não é bem feito, mas foda-se).

Uma vantagem óbvia deste pattern é que seu modelo de dados fica sucinto, simplificando o entendimento, e economizando tabelas pra dar manutenção.

Dynamic Columns Report[editar]

Padrão utilizado para criação de relatórios aonde exija algum tipo de consolidação, largamente utilizado para relatórios que exijam consolidação por data.

Passos:

   1 - Criar uma tabela Chamada DynamicReport.
   2 - Cria-se uma Store Procedure que consolide todos os dados que você deseja por dia, 
       após o a captura desses dados criar-se uma coluna para cada dia que você deseje consolidar.

Se você quiser que este relatório seja diário coloca-se um job no SQL para que rode essa Store Procedure todo dia, assim você obtem um relatório diário, pois será acrescentado a coluna do dia na sua tabela.

vocês devem estar se perguntando, mas essa tabela ficará enorme depois de alguns dias, meses, anos... Mas esta técnica prevê esse comportamento. Para que este tipo de comportamento não aconteça 2 providencias são necessárias:

  1 - Alertar ao usuario que é possível somente visualizar o relatório de 31 dias apenas.
  2 - Na sua Store Procedure, colocar uma condição que caso os campos sejam maiores de 31, você dropa o primeiro e cria um novo

Segue código de exemplo da Procedure:

   CREATE PROCEDURE dbo.p_GenerateDynamicReport_s
   AS
   BEGIN
       SET NOCOUNT ON
       SET ANSI_WARNINGS OFF
   
       DECLARE
           @dtEnd AS DATETIME,
           @dtBegin AS DATETIME,
           @dtLoop AS DATETIME,
           @column AS VARCHAR(10),
           @period AS DATETIME
   
       SET	@dtEnd = CONVERT(DATETIME, CONVERT(VARCHAR, GETDATE(), 103), 103)
       SET	@dtBegin = DATEADD(dd, -60, @dtEnd)
       
       IF EXISTS (SELECT [NAME] FROM TEMPDB..[SYSOBJECTS] WHERE [NAME] LIKE '#TEMPVIEW%')
       BEGIN
           DROP TABLE #TEMPVIEW
       END
       
       IF EXISTS (SELECT * FROM DBO.SYSOBJECTS WHERE NAME = 'DynamicReport' AND OBJECTPROPERTY(ID, N'ISUSERTABLE') = 1)
           BEGIN
           DROP TABLE DynamicReport
       END
       
       SELECT
           CONVERT(SMALLDATETIME, CONVERT(VARCHAR, o.Date, 103), 103) AS [DATE], 
           COUNT(CONVERT(SMALLDATETIME, CONVERT(VARCHAR, o.Date, 103), 103)) AS QUANTITY
       INTO
           #TEMPVIEW
       FROM Order o
           INNER JOIN OrderItem oi ON o.OrderID = oi.OrderID
       GROUP BY
           CONVERT(SMALLDATETIME, CONVERT(VARCHAR, o.Date, 103), 103)
       HAVING
           CONVERT(SMALLDATETIME, CONVERT(VARCHAR, o.Date, 103), 103) >= @DTBEGIN
           AND CONVERT(SMALLDATETIME, CONVERT(VARCHAR, o.Date, 103), 103) <= @DTEND
       ORDER BY
           [DATE]
       
       
       SET 	@period = DATEDIFF(dd, @dtBegin, @dtEnd)
       SET	@dtLoop = @dtBegin
       
       WHILE	(@dtLoop <= @dtEnd)
       BEGIN
           SET	@column = RTRIM(DATEPART(dd, @dtLoop)) + '/' + RTRIM(DATEPART(mm, @dtLoop)) + '/' + RTRIM(DATEPART(yyyy, @dtLoop))
           SET	@query = 'ALTER TABLE DynamicReport ADD [' + @column + '] INT'
           EXEC (@query)
           
           SET	@query = 'UPDATE DynamicReport SET [' + @column + '] = #TEMPVIEW.QUANTITY FROM #TEMPVIEW 
           EXEC	(@query)
           SET	@dtLoop = DATEADD(day, 1, @dtLoop)
       END
       
       IF EXISTS (SELECT [NAME] FROM TEMPDB..[SYSOBJECTS] WHERE [NAME] LIKE '#TEMPVIEW%')
           BEGIN
               DROP TABLE #TEMPVIEW
           END
       END
   GO

Power-Cursor[editar]

O Power-Cursor é um recurso utilizado para tornar suas queries mais bonitas. A regra é simples: esqueça que uma query SQL pode trabalhar com um conjunto de registros em um único comando, e trabalhe com os registros um a um. Exemplo:

   DECLARE
   	@idReportSchedule int,
   	@dtCreation datetime,
   	@dtCreationFrom datetime
   
   DECLARE CUR_SCHEDULES CURSOR FOR
   	SELECT idReportSchedule, dtCreation FROM ReportScheduler
   
   OPEN CUR_SCHEDULES
   
   FETCH NEXT FROM CUR_SCHEDULES INTO @idReportSchedule, @dtCreation
   
   WHILE @@FETCH_STATUS = 0
   BEGIN
   
   	IF(DATEDIFF(dd, @dtCreation, GETDATE()) > 6)
   	BEGIN
   		DELETE FROM ReportScheduler WHERE idReportSchedule = @idReportSchedule
   	END
   	
   	FETCH NEXT FROM CUR_SCHEDULES INTO @idReportSchedule, @dtCreation
   END
   
   CLOSE CUR_SCHEDULES
   DEALLOCATE CUR_SCHEDULES


Repare que o resultado é o mesmo que DELETE FROM ReportScheduler WHERE dtCreation > DATEDIFF(dd, -6, GETDATE()), só que com o Power-Cursor o resultado é muito mais elegante, compreensível, e performático.

Como outros patterns, este também é um exemplo real.

AND 0=0[editar]

Outra Gambi Design Pattern largamente utilizada no mundo do SQL (de qualquer fabricante). Aqui a regra é montar uma query dinâmica com o menor esforço possível, e portanto a maior produtividade imaginável. Suponha que você precisa consultar a tabela de clientes e na tela de sua aplicação o usuário pode entrar duas informações diferentes para localizar o cliente. O experiente POGamador coloca tudo num linguição cheio de "AND", e depois coloca um "0=0" no final, pra não deixar nenhum "AND" sozinho (afinal, eles são muito carentes). E foda-se o plano de execução. Rodou? NEM RELA!

Segue um claro exemplo (retirado de aplicação real):

if ((txtNome.value == "") && (txtCPF.value == "")) {
   alert("Informe no mínimo um campo para realizar a busca!");
} else {
   var strSQL = "SELECT INDICE, NOME, CPF, ENDERECO FROM TB_CLIENTES WHERE ";
   if (txtNome.value != "")
      strSQL += " nome like '%" + txtNome.value + "%' AND "; //eis o truque. um AND aqui,
   if (txtCPF.value != "")
      strSQL += " CPF like '%" + txtCPF.value + "%' AND "; //e outro aqui.

   strSQL += " 0=0"; // e então entra o 0=0 que evita o erro dos AND's sozinhos
}

WHERE 0=0[editar]

Parecido com o AND 0=0, mas nesse caso você tem um SQL em que você vai adicionar condições dinâmicas. Em vez de sempre verificar se o WHERE já foi colocado ou não, o desenvolvedor coloca um WHERE 0=0 e depois só vai colando os ANDs no final, já que o 0=0 não vai fazer diferença e de quebra você economiza vários if's. Veja exemplo:

$sql = "SELECT * FROM Cliente ";
if($cond1 == =true){
$sql .= "WHERE id>50 ";
}

if($cond2 == true && $cond1 == true){ //tem que verificar, senão você vai acabar ficando com dois WHEREs
$sql .= "AND status=1 ";
}
else if($cond2 == true && $cond1 == false){
$sql .= "WHERE status=1";
}

//Implementando o padrão WHERE 0=0

$sql = "SELECT * FROM Cliente WHERE 0=0 ";

if($cond1 == =true){
$sql .= "AND id>50 ";
}

if($cond2 == true){
$sql .= "AND status=1 ";
}

//bem mais fácil e intuitivo

PogManager Pattern[editar]

Consiste numa classe que encapsula diversas técnicas POG. Deve ser usado em conjunto com as declarações try...catch conforme o exemplo abaixo.

try {
   businessObj.businessMethod();
} catch (KnownError err) {
   pogManager.doIt();
} catch (UnknownError err) {
   while(true) {
      pogManager.doItAgain();
   }
}

Continuous & Incremental POGging[editar]

Consiste na elaboração de projetos enormes incrementalmente. Este pattern acelera em muito o processo de implementação e facilita um posterior suporte. Projetos que seguem este pattern geralmente são chamados de teste.prj, HelloWorld.prj, tst.vcp, tst.vcw etc. Seus arquivos principais (onde se encontram a main() e a (única) função MegaZord) geralmente se chamam teste.cpp ou HelloWorld.cpp. Ainda outra característica comum nestes projetos é a antiga data de criação dos arquivos já citados anteriormente.

Polymorphic Confusion[editar]

Tática gambi adotada principalmente por DBAs, na qual a mesma informação pode possuir dezenas de utilidades e significados dependendo de flags ou de alguma condição obscura. Coisas como "se o ID for maior que 9999 não é mais produto comprado, é produto vendido!" e "a flag 'tipoEntidade' indica se é uma pessoa, empresa ou qualquer item".

Em um exemplo real, em produção, na tabela de débitos (que, aliás, se chama "créditos"), existe a coluna "IN_MULTA". Se for "N", indica que não se aplica a multa ao débito, e, se for "S", faz-se necessário verificar o campo de tipo de tipo de débito. Caso for "LO", e a chave estrangeira tripla de autorelacionamento "VINCULADO" (lembre-se que só os DBAs mais poderosos usam chaves primárias compostas) levar a um registro do tipo "MV" cujo situação for "6" com motivo 14, 15, 16, 17 ou 19, ou situação for "12" e existir um registro na chave estrangeira tripla de autorelacionamento "DESMEMBRADO" cuja regra inicial se aplique (ou seja, for do tipo "MV", etc, etc - lembre-se que o desmembrado pode ser redesmembrado), finalmente você descobre que o "S" de multa, na verdade representa desconto. Nos outros casos, é multa, mesmo - exceto se o indicador for "NA" ou nulo, nesse caso, utilize o User Friendly Exception para indicar um registro não previsto na base.

Controller Confusion[editar]

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.

DB is our God[editar]

Também conhecido como In DB we trust . Padrão gambi arquitetural em que TUDO é no banco de dados. Os dados, arquivos, imagens, lógica de negócio, tratamento de erros, geração de HTML. O programa em si é só um monte de strings (em variáveis estáticas, é óbvio) com as consultas.

Referential Integrity by Software[editar]

A Integridade Referencial é utilizada para garantir a Integridade dos dados entre as tabelas relacionadas. Após anos e anos de uso do padrão "DB is our God", o MPOG percebe que o principal problema em se usar banco de dados, é que ao tentar remover determinado registro um erro é retornado devido aos relacionamentos entre as tabelas. Visando sempre a metade da metade inferior do prazo, o MPOG simplesmente retira todos os relacionamentos entre as entidades, e, muitas vezes, desnormaliza cinco tabelas em uma só, garantindo assim o baixo tempo de desenvolvimento e fazendo com que a aplicação seja altamente performática.

Invisible Objects Blackhole[editar]

Também conhecido como Textbox Invisível ou GambiaHidden Utilizado para a manipulação de dados que devem ser persistentes, independentemente do programa de origem continuar em execução ou não. Ao se deparar com um problema semelhante, o MPOG utiliza um objeto (geralmente uma caixa de texto) presente no mesmo ou ainda em outro formulário da aplicação para armazenar o valor antes que o mesmo seja alterado de maneira aleatória pelo programa. Muito utilizado em conjunto com o Nonsense Flag, na programação VB. Tem como prática suprema de programação a definição do caption do objeto como INVISÍVEL, de modo a estabelecer já em design-time o tipo de utilização desejada para o mesmo.

N.M.L. Combat Action POG Pattern[editar]

É 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!

Reinvented Square Wheel Helper[editar]

Também conhecido como "Do not trust the others". Este design pattern visa aumentar a performance de tarefas corriqueiras, para as quais já existe uma API da própria linguagem que faz a mesma coisa. Ao invés de utilizar a referida API, o programador, em um instinto de provar a masculinidade ou por pura preguiça de ler o manual, reinventa diversas funções básicas, como por exemplo a de "adicionar um dia a uma data" e, utilizando tipos totalmente impróprios para manipulação de datas, tal como String, reconstroem toda a lógica de calendário só para fazer esta função.

Afinal de contas melhor 856 bugs em código seu do que 1 em código de outros.

Reinvented Square Wheel Wrapper[editar]

Variante da Reinvented Square Wheel Helper, este pattern é usado por quem não confia nas APIs existentes, mas não tem tempo hábil para reescrever tudo. Se algum estagiário já fez o serviço, não reescreva, encapsule! Basta criar uma classe que extenda a classe da API e pronto.

Exemplo real, vindo de uma empresa (realmente) grande que fabrica softwares (extremamente) caros:

 public class McTimestamp extends java.útil.GregorianCalendar {
   public McTimestamp(int year,
                  int month,
                  int date,
                  int hour,
                  int minute,
                  int second) {
     super(year, month, date, hour, minute, second);
   }
   public McTimestamp(int year,
                  int month,
                  int date,
                  int hour,
                  int minute,
                  int second,
                  int millisecond) {
     super(year, month, date, hour, minute, second);
     set(MILLISECOND, millisecond);
   }
 }

Pensamento positivo[editar]

Também conhecido como Wishful thinking. Este design pattern é extensivamente utilizado no ciclo de depuração do código POG:

  1. Execute o código.
  2. Não funciona?
  3. Pensamento positivo, e tente novamente.

Repita o ciclo até que o problema desapareça espontaneamente.

Perfectness Execution[editar]

Também denominado Unstoppable Redundancy consiste em uma complexa operação feita com extrema consistência e que sempre é executada com absoluto sucesso. Exemplo prático de utilização:

public class Main {
  public boolean alterar(Object valor1, Object valor2) {
    ...
  }
  public static void main(String args[]) {
    ...
    try {
      if (alterar(valor1, valor2)) {
        System.out.println("Operação concluída com sucesso!");
      } else {
        System.out.println("Operação concluída com sucesso!");
      }
    } catch (Throwable e) {
      System.out.println("Operação concluída com sucesso!");
    } finally {
      System.out.println("Operação concluída com sucesso!");    
    }
  }
}

You Shall Not PASS![editar]

Vulgarmente conhecido como "Vagões de ORs e ANDs", visa bloquear todo e qualquer erro que o poguizador não tem a menor ideia de como surgiu criando-se uma extensa linha de código de condições com diversos ANDs e ORs que barram de tudo, menos o desejado. Muitas vezes deve-se tomar essa medida quando se utiliza do artifício Contra o C Contra o V e infelizmente o User Friendly Exception ou o Chaotic Experimentation não puderam dar conta do recado.

The CoITO (Control of Interface Totally Obtainble)[editar]

Além das diversas dificuldades já citadas que o POGramador enfrenta, as linguagens ainda impõem outras como, por exemplo, não poder instanciar uma interface o que torna a expansão de softwares uma tarefa mais árdua. Desta forma, o The CoITO ou Gambi Casting soluciona o problema citado de forma elegante. Siga o exemplo em Java:

public interface Carro {
   public acelera ( );
}
public class Motorista implements Carro {
   public acelera ( ) {
   [...]
   }
}
public static void main ( String [ ] args ) {
   Motorista motorista = new Motorista ( );
   Carro c = motorista; // Veja a elegância do The CoITO sendo usado
   // Agora você já pode usar tranquilamente a chamada de métodos com a Interface
   c.acelera ( );
}

BulletProof[editar]

Semelhante ao Chaotic Experimentation
Também conhecido como Silenciator, este é um dos mais antigos, e ainda utilizados. O objetivo é fazer com que seu sistema, não apresente erros, afinal, os usuários não entenderiam porque aparece o número da linha de algum canto obscuro, ou aquela mensagem que parece um juramento de morte. Então deixe os erros para quem entende, no sistema em produção você irá desligar a exibição de erros.

# Lembre-se no PHP é:
error_reporting(0);
no ASP / VB
<%
On Error resume Next
%>
//no Java
try { fazAlgumaCoisa(); } catch (Throwable t) {}
try { fazOutraCoisa(); } catch (Throwable t) {}
try { fazMaisOutraCoisa(); } catch (Throwable t) {}
/* em Oracle PL/SQL */
begin
  ...
exception
  when OTHERS then
    NULL;
end;

É uma garantia de que ninguém te ligará na última hora por causa de uma tela em branco. O único efeito colateral é ter que sair ligando tudo na hora de debugar, portanto 'saboreie com moderação'!

Uso de Força Bruta[editar]

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);
}

...

Uso de Força Bruta 2[editar]

Método extremamente eficaz. se resume em tentar até funcionar. Muito eficaz para problemas que ocorrem de vez em quando.

...

public void ChamaMetodoSolucao()
{
  try
  {
     //faz alguma coisa
  }
  catch (Exception)
  {
     Sleep(1000); 
     ChamaMetodoSolucao();
  }

}
...

MOPED[editar]


O Método Orgânico de Programação Evolutiva Darwiniana consiste em utilizar conceitos do darwinismo em programação.
A cada passo, mutações aleatórias são feitas no sistema pelo experiente POGramador. Após isto apenas as gambiarras mais adaptadas ao meio sobreviverão à próxima série de mudanças aleatórias do POGramador.
O MOPED demonstra toda a sua glória e potencial quando se observa um sistema de milhares de linhas, 3D, com múltiplas threads, se formar à partir de um 'hello world'.
É a evolução do método de Chaotic Experimentation.

Rest Assurance Memory Allocation Pattern[editar]

Técnica utilizada por POGramadores da idade média das linguagens de computador (período pré-Cetáceo) para que suas Strings nunca explodissem inesperadamente seus POGramas. A técnica consiste em alocar uma quantidade "um pouquino" maior de caracteres que uma String precisaria. Também conhecida como "Caixa de Brita"

Isso se deve ao fato de que linguagens como C são extremamente rápidas, o que faz com que o contador de caracteres conte o tamanho da String TÃO RÁPIDO que passe batido por um ou outro byte.

Obserserve a técnica a seguir:

...
char* copiarString(char* string) {
    char* outra_string = malloc(strlen(string) + 2); // só para garantir
    strcpy(outra_string, string);
    return outra_string;
}
...

ICI ou CCI - Invisible/Comment Code Implementation[editar]

Técnica utilizada por POGramadores para acabar com Bugs de qualquer tipo. Geralmente é usada por POGramadores que realizam manutenções em códigos de outros POGramadores. De facil aplicabilidade a ICI ou ICC limita-se a apagar ou comentar o código com erros.

...
  public boolean checkValues( Object valor1, Object valor2 )
  {
     /* tinha alguma coisa aqui 
     .
     .
     .
     */

     return true;
  }
}
...


Modelo Grafo Completo[editar]

Um dos grandes problemas enfrentados pelas classes de projeto e de escravidão "implementação", vulgo programação, é a questão "Conseguirei ter acesso a um atributo X por meio desta classe Y ?". Partindo desta questão fundamental do espécimie humano foi desenvolvido o "Modelo Grafo Completo" ou, para seres mais desenvolvidos Complete Graph Model.

Este padrão dita que todas as classes devem estar ligadas com todas. Não importa se a classe é de persistência, fronteira ou de (des)controle tudo deve estar ligado com tudo.

Este Design Pattern traz diversas vantagens mas, dentre elas podemos destacar:

  • Maior facilidade na construção de Diagramas de Classes: Uma vez que tudo se liga a tudo basta definir quais classes existirão e inserir arestas. É tão simples que até um estagiário em seu primeiro dia de trabalho pode fazer portanto dê a ele esta tarefa e tire uma folga.
  • Escalabilidade: Qualquer acréscimo no sistema pode ser facilmente contornado já que é necessária a definição das novas classes. A partir daí é só socar arestas em todas as direções.
  • Suporte à mudança de requisitos: Sabe-se que a mudança de requisitos é um dos maiores problemas no desenvolvimento de softwares. Desta forma, utilizando-se o Modelo Grafo Completo qualquer mudança nos requisitos que implique em acréscimo ou retirada de classes podem ser contornados: remova ou adicione arestas e classes.
  • Produtividade: Após testes desenvolvidos no PSC (Progress Software Community POG Solution Center) verificou-se que em 315,8 % dos casos o projetista, programador e toda a equipe de desenvolvimento pode ir para casa mais cedo, pois seu trabalho já tinha sido concluído de forma magistral.

No Error Pattern[editar]

Este padrão consiste na abolição completa e total de tratamento de exceções e comandos IF colocados com o intuito de prevenir erros. Como todos sabemos, este tipo de implementação serve apenas para programadores iniciantes, que geram erros e, portanto, precisam tratá-los. Este padrão aumenta a produtividade em até 93%, visto que não será necessário código inútil destinado ao tratamento de erros e com a mudança da mentalidade do programador os programas serão feitos de maneira mais rápida e direta, afinal, quanto mais código, mais erros, e obviamente qualquer programa pode ser feito em uma única função.

BOB, o Esponja Psicopata[editar]

"Pega mais de cinco tecnologias, sem usar o toilette..."

É aquele vertente inovadora que brota na ideologia de redes de transmissão ininterrupta, com taxas excelentes, memória sobrando, clientes de QI normal, e sistemas 100%legalizados.

Então descobre que seu chefe (psicopata congênito), com aquele charme, habilidade de mentir e egoísta, usa a inteligência que tem para abrir as portas (as pernas também?) do cliente para o mundo tecnológico do amanhã e, com total ausência de culpa, passou-lhe (o P.E.P.I.N.O.) uma lista de tarefas, que mais parece um assassinato em série.

  • O link utilizado é um lixo
  • O Ajax trabalha feito servidor público
  • O Hibernate foi mal adaptado
  • O espeto não é só de pau, como também veio cheio de problema


Daqui em diante então segue o terror com os prazos forçados e vários incêndios.

Temporary Code[editar]

Este padrão tem como objetivo principal criar um código inicialmente temporário, seja para quebrar um galho ou tapar um buraco. Largamente utilizado por POGramadores, em aplicações de grande porte, normalmente foi testado inúmeras vezes e nunca deu rolo, sempre seguido da premissa "Tá funcionando? Nem rela", acaba virando relíquia no código da aplicação.

Abaixo um exemplo típico:

  ...
  // Fulano - 10/02/1990 - Trecho temporário (alterar assim que possível)
  if (codigoErro == -9887) {...}

Varalzão[editar]

Quando utilizado em grande escala é também conhecido como lavanderia, consiste na lendária arte de se pendurar códigos em cima de códigos para promover a estabilidade máxima do sistema.

Utilização prática:

  public class Pinga extends Cana
  public class Pinga2 extends Pinga
  public class PingaFinal extends Pinga2
  public class PingaFinal2 extends PingaFinal
  public class PingaDaPingaFinal extends PingaFinal2

POC[editar]

Programação Orientada à Compilador. O POC é uma prática bastante comum entre programadores do mundo. O programador adepto do POC, utiliza o compilador e os erros de compilação para verificar se o programa funciona.

O processo é iterativo, ou seja, muitas vezes várias compiladas no programa são necessárias para se corrigir todas as bugs. A prática é facilitada pelos software de programação que possuem teclas de atalho para compilar o software.

Quando o programa finalmente compila é possível ter-se a mais absoluta certeza de que este funcionará perfeitamente uma vez que é tarefa do compilador capturar todos os erros. Logo testar o programa é desnecessário: Se compilou então está certo!

CoPEL[editar]

Comentários Para Encher Linguiça é uma prática recomendada ao POGramador. O CoPEL, é todo comentário de código-fonte indispensável para completa compreensão do software. Sem os comentários do tipo CoPEL, a documentação do software fica incompleta e dificulta a leitura de outros programadores da equipe.

Por exemplo, observe este trecho de código sem CoPEL:

public static int somaAB(int a, int b) {
    return a + b;
}

public static boolean isAplicativoAberto = false;

public static String senhaSecreta = "123456";

public static boolean verificaSenha(String senha) {
    if (senha.equals(senhaSecreta)) {
        return true;
    }
    return false;
}

Entendeu alguma coisa?

Agora compare com a versão a seguir, onde o CoPEL foi aplicado, e note que os comentários são indispensáveis e certamente ajudam muito na compreensão do código e na produtividade de toda a equipe:

/** 
 * Método para somar o valor de A com o valor de B.<br>
 * Exemplo de uso deste método:<br>
 * <pre>
 *   int a = 5;
 *   int b = 3;
 *   int soma = somaAB(a, b);
 * </pre>
 * No exemplo supracitado, a variável <code>soma</code> conterá
 * o valor da soma das variáveis <code>a</code> e <code>b</code>.
 * Tendo em vista que o valor da variável <code>a</code> é 5 e o da variável <code>b</code> é 3,
 * será atribuido à variável <code>soma</code> o valor 8.
 *
 * @param [in] a O valor de A, a ser somado com o valor de B.
 * @param [in] b O valor de B, a ser somado com o valor de A.
 * @return O valor resultante da soma dos valores dos parâmetros A e B.
 * @see subtracaoAB(int, int)
 * @see multiplicaoAB(int, int)
 * @see divisaoAB(int, int)
 */
public static int somaAB(int a, int b)
{ /* Início da declaração do método somaAB. */
    return a + b; // Aqui é retornado a soma de a com b.
} /* Fim da declaração do método somaAB. */

/**
 * Variável que informa se aplicativo está aberto ou não.
 * Caso o valor contido nesta variável seja <code>true</code>,
 * então o aplicativo está aberto.
 * Caso o valor contido nesta variável seja <code>false</code>,
 * então o aplicativo não está aberto.
 */
public static boolean isAplicativoAberto = false;

/**
 * Campo que guarda a senha secreta para executar esta aplicação.
 * @see verificaSenha(String)
 */
public static String senhaSecreta = "123456";

/**
 * Método que verifica se a senha informada para a execução do aplicativo está
 * correta.<br>
 * Exemplo de uso deste método:<br>
 * <pre>
 *   if (verificaSenha(senha))
 *   { // Início do bloco de execução da estrutura condicional de decisão if.
 *      ... // Bloco de instruções a ser executado caso a senha esteja correta.
 *   } // Fim da estrutura condicional de decisão if.
 * </pre>
 *
 * @param [in] senha A senha a ser verificada com a senha secreta.
 * @return <code>true</code> caso a senha informada no parâmetro coincida
 * com a senha secreta, <code>false</code> caso a senha informada no parâmetro
 * não coincida com a senha secreta.
 * @see senhaSecreta
 */
public static boolean verificaSenha(String senha)
{ /* Início da declaração do método verificaSenha. */

    // Se a senha informada coincidir com a senha da aplicação,
    // retorna verdadeiro, pois isso significa que a senha está correta.
    if (senha.equals(senhaSecreta)) // Aqui tem que usar o equals porque o == dá pau.
    { /* Início do bloco de execução da estrutura condicional de decisão if. */
        return true; // Aqui o valor true é retornado.
    } /* Fim da estrutura condicional de decisão if. */

    // Se o valor true não foi retornado acima, é porque a senha está incorreta,
    // então o valor false deve ser retornado.
    return false; // Retorna o valor false.

} /* Fim da declaração do método verificaSenha. */

CoPEL 2.0[editar]

Muitas vezes, não basta aos POGramadores escrever comentários descrevendo o que o programa faz. Como em 99% das vezes ninguém vai ler eles, ou apenas os próprios POGramadores lerão, e o chefe é um daqueles caras que adora ter tudo documentado mas não lê uma vírgula do que foi escrito, é muito conveniente aos POGramadores escrever comentários que nada tem a ver com o código documentado. Além disso, a produtividade é aumentada, pois os POGramadores não precisam analisar o que determinada função faz ou qual variável é que deve ser passada, basta escrever qualquer coisa. E como todo mundo está se lixando com ortografia, então os comentários podem ser escritos em miguxês mesmo, afinal, ninguém vai ler eles mesmo. Este padrão também permite que os comentários do código-fonte possam ser utilizados como chat.

Veja o mesmo programa do exemplo anterior em CoPEL 1.0, mas agora com os comentários reescritos com CoPEL 2.0:

/** 
 * cara, ontem eu tava vendo um filme mto legal, tem uns alienigena mó locão, meu.
 * o melhor eh que eu conheci uma mina muito fileh na fila.
 * Tem um popozão de funkera que rebola ateh o chao.
 * <pre>
 *   int a = 5;
 *   int b = 3;
 *   int soma = 4;
 * </pre>
 * Aiai. Num aguento fikar olhando pro relogio, soh to esperando da 6 hora pra ir logo pra casa
 * E ainda vo te q pega transito nesta merda d cidade. 
 *
 * @param Po, mano e ai? fala mais da mina. como ela eh?
 * @param kra, Eh uma morena da hora, um pouco baixinha, mas meu eh mto gostosa
 * @return E vc pegou o telefone dela?
 * @see Cara, pegei sim! vo passa um xaveco nela e leva pro cinema
 * @see depois vai pro motel
 * @see heheh
 */
public static int somaAB(int a, int b)
{ /* e ai, bora pedi uma pizza? */
    return a + b; // eu num to a fim de fika um tempao no transito
} /* e ja q temos q entrega essa merda prakele viado mesmo, to pensando em ficar + um tempo!!!! */

/**
 * bora entao! que tal calabreza?
 * axo q ta meio kara to kerendo economiza uma grana. pq naum frango desfiado?
 * pode c!
 * vai da 18. tenho deiz aki, depois vc me da 1 reau.
 * blz!
 */
public static boolean isAplicativoAberto = false;

/**
 * Mas ai broder, meiu q mudando de assunto, o carlao vai sai de ferias
 * @see vai la pra recife
 */
public static String senhaSecreta = "123456";

/**
 * e nóis aki tem q fika dando manutencao nesta bosta d sistema
 * qeria mata akele viado
 * ele faz a merda e depois sobra pra nois.
 * no minimo vai la pra fika dando a bunda
 * puta q pariu, q merda.
 * nao aguento mais essa bosta d empresa
 * mas, po cara, eh assim mesmo
 * os cara nao manja nada de programacao, nao sabe eskreve um hello world, dai vira analista
 * ainda ganha mais e nois fika de otario tendo q resolve as cagadas
 *
 * @param no minimo deu o cu pro chefe
 * @return so pode, o cara eh um cuzao, nao manja bosta nenhuma so faz merda e ganha + q todo mundo
 * eh por isso q essa empresa eh uma merda
 * depois quem tem q fika trabalhando de noite e de fds eh a gente
 * @see to loko pra sai daki e ir pra algum outro lugar
 */
public static boolean verificaSenha(String senha)
{ /* Ja distribui curriculo, mas ta foda. */

    // Soh me chamam pra lugar ainda pior e ainda kerem
    // pagar menos do q essa miseria q pagam aki
    if (senha.equals(senhaSecreta)) // Pois eh, tem q sair mesmo. Eu tambem to kerendo vaza
    { /* E dai m (txtCPF.value == "")) {
   alert("Informe no mínimo um campo para realizar a busca!");
} else {
   var strSQL = "SELECT INDICE, NOME, CPF, ENDERECO FROM TB_CLIENTES WHERE ";
   if (txtNome.value != "")
      strSQL += " nome like '%" + txtNome.value + "%' AND "; //eis o truque. um AND aqui,
   if (txtCPF.value != "")
      strSQL += " CPF like '%" + txtCPF.value + "%' AND "; //e outro aqui.

   strSQL += " 0=0"; // e então entra o 0=0 que evita o lt;brerro dos AND's sozingt; e hogt;as
}
ando o carlao enfia esse sistema no cu dele! */
        return true; // Ele q invento essa merda, problema dele
    } /* dai eu quero ve ele c fude legal, hahah */

    // E qnd isso acontece eu kero esta longe
    // Imagina entao qnd descobrirem akele bug
    return false; // Ateh lá o estrago ja vai ter sido grande

} /* e eu ja vou kerer estar bem lng daki qnd a bomba explodi, hehehe */

Always/Forever ou Comentários-Eternos[editar]

Pode-se dizer, na ínteglt;prera, que este é um dos padrões largamente utilizados em empresas onde a rotatividade de POGgramadores é alta. Este padrão implementa (ou deveria) o padrão 'A bagaça funciona? Nem rela!'. O POGramador é novo na empresa e, como todo Gerente de TI é extremamente gente boa, atribui-lhe a tela mais bizarra de todo o sistema. De praxe, como haverá modificações, ele usara todo seu conhecimento para Gambiarrar o máximo que der,fazendo uso da premissa "Menos tempo, mais produtividade". Em caso de substituição de código, o código antigo não deverá ser apagado, mas sim comentado, e deixado exatamente onde estava PARA TODO O SEMPRE. Isso garante ao POGramador que, "se a bagaça não funcionar" e todo aquele Fluxograma maravilhoso entrar em sua funcionalidade, NO PIOR CASO, ele possa voltar o código original para onde estava, e então comentar seu código (nota-se um laço de repetição semelhante a um while(true) ou for(;;), pois, dependendo da capacidade mental do POGramador, o comentado volta a ser codigo, e o código volta a ser comentado, e assim sucessivamente).

Um exemplo pratico: imagine uma clausula if sendo modificada para a retirada de um dos termos comparativos

public class TelaBizarra extends tudo_q_vc_imagina implements uma_pancada_de_interfaces
{
  if(.....)
  {
    while(...)
     {
       if (i=j && j=k+1 || (ActionEvent.getSource().getClass().....toString().equalsIgnoreCase("ABC123")
          {
          }
     }
  }
  ......
  ......
}

ao invés de simplemesmente retirar ActionEvent e tudo que vai na frente, pode-se fazer

public class TelaBizarra extends tudo_q_vc_imagina implements uma_pancada_de_interfaces
{
  if(.....)
  {
    while(...)
     {
       /*if (i=j && j=k+1 || (ActionEvent.getSource().getClass().....toString().equalsIgnoreCase("ABC123")
          {
          }*/

        if (i=j && j=k+1)
          {
          }
     }
  }
  ......
  ......
}

A tendencia é que o POGramador, com o passar do tempo, torne o código TÃO caótico que nem mesmo os primeiros criadores serão capazes de desfazer tanta gambiarra.

Reversal Boolean[editar]

A teoria do Reversal Boolean é bem conhecida entre os POGramadores experientes, porém pouco difundida entre os mais novatos. Podendo ser usada juntamente com a Else Forever e Nonsense Flag, ou melhor dizendo, na maioria das vezes o pattern Nonsense Flag estará presente. A base de todo o reversal boolean vem da lógica matemática. Para todo e qualquer Nonsense Flag instanciado, 1 é false, 0 é true, ou false==true e vice-versa. Assim, quando um NonsenseFlag boolean for 0, a ação é executada, do contrario continue no else forever até achar a saída mais próxima.

public int Compara_e_Soma(int a, int b, boolean NonSenseFlag)
{
     if(a==b)
     {  
        if(NonSenseFlag == false)
          return a+b;
        else //pode-se gambizar a vontade para que ele retorne mesmo se a condição nao for satisfeita
          /*ação...*/
     }
}    

O que chama a atenção é que a junção de muitos Gambi Design Patterns em um mesmo projeto pode levar a formação expontanea de um padrão muito evitado até mesmo por POGramadores do nivel de Mestre Yoda, Obi-Wan-Kenobi, e derivados. O temido Chain of Chaos

N.E.N.E (Nao Existe Nenhuma Exceção)[editar]

O N.E.N.E é a arma mais eficaz a favor do POGramador, especialmente quando este precisa usar um componente não usual dentro do seu compilador POG. Tudo indica que este padrão é a versão de Exception Successfull, porem traduzida para Delphi. A ideia chave é tratar as exceções e mandá-las fazer extatamente o que o try não quis fazer por birra. Prático, limpo, e rapido. Possivelmente nem mesmo você ira entender o porque desta implementação ter funcionado tão bem. Não importa, pois utilizando como base a Máquina de Estados OG se funcionou, "nem rela".

Segue um exemplo pratico, e real, abaixo:


/**Problema: Impressora de etiquetas precisa de um método dinamico para achar alguma porta serial que exista, sem a necessidade de incomodar 
o usuario com "entre com o numero da porta serial por favor" 
(se é que algum usotár....aham, usuario, iria entender o que diabos vem a ser uma porta serial)**/

procedure TForm1.pegaConexaoImp (Sender: TObject)
var

          Impressora: TApdComport; //eis o componente
          str:        String;
          i:          Integer;
begin
    
   
     for i:=1 to 10 do //10 seria realmente um otimo intervalo. Você pode tentar, 20, 30..varia de acordo com o tempo disponivel do POGramador
     begin
     try
     begin
            Impressora.ComNumber := i;
            Impressora.PutChar(str); //Caso a porta não exista o usuario iria começar a chorar nesse momento POREM...........
     
     on e:except do
            Impressora.ComNumber := Impressora.ComNumber + 1; //Here lies the secret. Exception? Qual exception? onde?
     end;
     end;
     end;

end;

Concluido o teste de portas, o POGramador garante a seu usuário que realmente, sua impressora ira achar uma "COM" disponível. A não ser que o micro em questão infelizmente não possua alguma instalada. Ambos saem felizes, e o gerente de TI não lhe prega o aço, caso você não tivesse acabado o projeto a tempo de deixar o bolso da empresa satisfeito.

POG Delegation Aproach[editar]

Consiste em delegar a responsabilidade do POG para instâncias superiores, como um programador sênior ou líder técnico.

Exemplo:

public void doSomething()
{
   try{
     ......
     ......
   }catch(Exception e){
     // fiz assim porque o A.L. mandou fazer assim.
     // qualquer coisa falem com ele no ramal 9999!!!
  	
   }

}

Doubleton[editar]

Você já tem um Singleton (aquele padrão criacional pra criar apenas uma instância de um objeto) que funciona perfeitamente, mas agora, no meio do projeto, você precisa criar 2 (isso mesmo, duas) instâncias do seu singleton. Como você faz? Usa Doubleton. Um exemplo:

public class MeuDoubleton {
    private static MeuDoubleton instancia = new MeuDoubleton();

    // aqui está a chave do sucesso!!!
    private static MeuDoubleton instancia2 = new MeuDoubleton();

    private MeuDoubleton(){
        // algum código aqui
    }

    public static MeuDoubleton getInstance(){
        return instancia;
    }

    /**
     * hahaha! me livrei de ter que usar aquele maldito Factory!
     */
    public static MeuDoubleton getInstance2(){
        return instancia2;
    }

    // outros métodos legais do seu doubleton
}

Esse pattern é flexível o suficiente para poder ser ampliado indefinidamente, com os padrões Tripleton, Quadrupleton, Quintupleton. Por exemplo:

public class MeuQuarentaEOitopleton {
    private static MeuQuarentaEOitopleton instancia = new MeuQuarentaEOitopleton();

    private static MeuQuarentaEOitopleton instancia2 = new MeuQuarentaEOitopleton();

    private static MeuQuarentaEOitopleton instancia3 = new MeuQuarentaEOitopleton();

    ...

    private static MeuQuarentaEOitopleton instancia47 = new MeuQuarentaEOitopleton();

    private static MeuQuarentaEOitopleton instancia48 = new MeuQuarentaEOitopleton();

    private MeuQuarentaEOitopleton(){
        // algum código aqui
    }

    public static MeuQuarentaEOitopleton getInstance(){
        return instancia;
    }

    public static MeuQuarentaEOitopleton getInstance2(){
        return instancia2;
    }

    ...

    public static MeuQuarentaEOitopleton getInstance48(){
        return instancia48;
    }

    // outros métodos.
}

Debug Compiling[editar]

Método de debug altamente eficiente. Utilize seu compilador como debug. É um método amplamente utilizado juntamente com o padrão nem-rela, aonde o pogramador utiliza seu compilador para debugar. Também conhecida como programação orientada a compilação. Compilou funcionou.

Gera a Porra Toda[editar]

Este é o pattern com o uso mais difundido no mundo, fortemente utilizada em sistemas POG, onde uma única classe é responsável por gerar todo a parte de visualização do sistema. Exemplo:

public class GeraAPorraToda{

  public static String gerar(){
     String conteudo = '<div id="imagem">
     <p><a href="http://noticias.terra.com.br/ciencia/interna/0,,OI2261692-EI299,00.html" rel="100"  >
     <img src="http://img.terra.com.br/capa/imagens/navio_cruzara_atlantico_pipa_bbcBR_163.jpg" 
alt="BBC Brasil" title="BBC Brasil"         width="162" height="198"></a></p>
     <h5><a href="http://noticias.terra.com.br/ciencia/interna/0,,OI2261692-EI299,00.html" rel="100" >Navio cruzará Atlântico <br />com ajuda de pipa gigante</a></h5>
    </div>';

   /**
    * Caro desenvolvedor, se precisar inserir mais alguma coisa, favor concatenar com o a variável conteudo.
    */

   return conteudo;
   }
}

GeraAPorraToda instance = new GeraAPorraToda();
instance.gerar();

Caso você não queira instanciar esta classe na mão, é muito comum utilizar um factory:

   String conteudo = GeraAPorraTodaFactory.getInstance().gerarAPorraToda();
   System.out.println(conteudo);

Hardcoded data[editar]

Conceito POG muito utilizado que consiste em colocar-se os dados da aplicação diretamente no código-fonte, e não no banco de dados. Muito utilizado em diversas situações:

  1. Quando não se tem banco de dados.
  2. Quando se tem preguiça de se utilizar o banco de dados.
  3. Quando o pogramador não sabe usar o banco de dados.
  4. Quando a estrutura do banco de dados está suficientemente POGueada justificando a aplicação desta técnica.
  5. Quando se tem pressa porque o gerente ou o cliente estão enchendo o saco e só querem saber de ver o troço rodando.

Além disso, este padrão é utilizado para evitar que o usuário utilize o sistema inadequadamente cadastrando dados inválidos, pois todo e qualquer cadastro é feito pela equipe de programação. Desta forma, como o usuário nunca efetua o cadastro, o programa fica mais estável e ocorrem menos bugs.

Exemplos:

   if (usuario.getNome().equalsIgnoreCase("Fernando Dias dos Santos") {
      usuarioEhGerente = true;
   }
   switch (produto.getCodigo()) {
     case 32: case 56: case 60: case 67: case 73: case 90: case 115: case 131: case 147:
        produto.setTipo("Especial"); break;
     case 21: case 44: case 45: case 46: case 78: case 92: case 101: case 122: case 144:
        produto.setTipo("Promocional"); break;
     case 12: case 15: case 39: case 56: case 65: case 79: case 81: case 82: case 84: case 109: case 127:
        produto.setTipo("Super"); break;
   }

Este é um exemplo mais real, que além de mostrar o poder e flexibilidade da técnica hardcoded-data, ainda a combina com alguns outros Gambi Design Patterns:

public enum Usuario {
    ALFONSO("Gerente"),
    CARLOS("Técnico"),
    CLOTILDE("Vendedora"),
    HENRIQUE("Gerente"),
    ISAÍAS("Telefonista"),
    JOÃO_CARLOS("Auxiliar de escritório"),
    JOÃO_AUGUSTO("Técnico"),
    MARTA("Técnica"),
    NAIR("Vendedora"),
    RICARDO("Vendedor"),
    SEBASTIÃO("Técnico"),
    TIAGO("Telefonista");

    public String nome, cargo;

    //depois tem que achar 1 jeito de fazer o SVN naum mostrar isso aki.
    public String[] senhas = new String[] {
        "1234", "qwert", "clo clo", "120778",
        "multimedia", "buceta", "magueira", "q1w2e3", "123456",
        "xxxx", "asdf", "epson"};

    public String senha;

    private Usuario(String cargo) {
       this.cargo = cargo;
       this.nome = StringGOD.formataNome(this.name());
       for (int i = 0; i < this.values().length; i++) {
           if (this.values()[i] == this) this.senha = senhas[i];
       }
    }

    public String getNome() { return nome; }
    public String getCargo() { return cargo; }

    public static void cadastraUsuario() {
       throw new RuntimeException("Para cadastrar um novo usuario favor entrar em contato com o CPD e fornecer nome, cargo e senha.");
    }

    public void mudarSenha(String novaSenha) {
       throw new RuntimeException("Para mudar a senha, favor entrar em contato com o CPD.");
    }
}

Nmes de vars abrv cm pouc vgs[editar]

Pdrã que cnsist em abrv td no cod fnt p/ prgç d dgt nms d vars lngs d+. C/ 1 prfc mto frt d elim vgs. P/ exmp:

    Clnt cli = new Clnt(codCli);
    cli.setNme("Zé da Silva");
    cli.setTlfn("5421 9077");
    cli.setEml("[email protected]");
    cli.setEndr("Avenida Brasil 1234");

    Emp emp = new Emp("Ze da Silva LTDA");
    emp.setCNPJ("01.2345.67/8901-23");
    emp.setDtaCad("12/02/2005");

    String sql = SQLFctry.geraUpdt(emp);

Nonsense naming[editar]

Nonsense naming é um padrão de nomenclatura de variáveis, funções, métodos, classes, e qualquer coisa que possa receber um nome. Consiste em simplesmente ignorar qualquer convenção da linguagem e nem adotar qualquer outro tipo de convenção. Também dita que o nome das variáveis não devem ter nada a ver com o seu significado. Por exemplo:

public class BATATINHA {
    public static double[] To_a_fim_de_ir_na_praia(double mIGuXEixxX, double Buceta, double LEITE) {
       if (mIGuXEixxX == 0.0) {
           throw new putzdeupipocomano("po bixo, isso num pode ser zero naum!!!!");
       }

       // cara, ela ta moh gostosa hoje! Aquela saia justa com aquela bundinha gostosa me deixa de pau duro.
       double hoje_a_martinha_ta_gostosa = Buceta * Buceta - 4 * LEITE * mIGuXEixxX;

       // e imagina que aquele namorado dela é viado, meu que desperdicio!
       if (hoje_a_martinha_ta_gostosa < 0.0) {
           throw new putzdeupipocomano("xiiii a bagaça ta negativa");
       }

       // ontem fui no cinema ver o filme do batman. Kra, o filme é bom pra kct!
       double variable114 = (-Buceta + Math.sqrt(hoje_a_martinha_ta_gostosa)) / (2 * mIGuXEixxX);
       double variable115 = (-Buceta - Math.sqrt(hoje_a_martinha_ta_gostosa)) / (2 * mIGuXEixxX);
       double[] AAAAA = new double[2];
       AAAAA[0] = variable114;
       AAAAA[1] = variable115;

       // estou com fome agora, acho que vo pedi uma pizza!!!!!
       return AAAAA;
    }
}

Obviamente, pelos nomes das variáveis, é muito fácil perceber que esse código calcula as raízes de uma função de segundo grau de acordo com a fórmula de Bhaskara.

Maitabom POG[editar]


if (origem!= null)
{
     parametros[4] = new SqlParameter("@DESTINO", destino.Codigo);
}
else
{
    parametros[4] = new SqlParameter("@DESTINO", DBNull.Value);
}

Essa é o tipo de gambiarra dos esquecidos, reparem que a variável do desvio condicional é a variável origem porém o parâmetro que será eviado junto a query é o parâmetro destino. Eu eu não entendia porque o cliente dizia que a grid exibida na tela de pesquisa estava maluca, na verdade o POGAMADOR é que é maluco.

I.N.P.U.T.[editar]

Vem de INstalled Processor Universal Test (Teste Universal para o Processador Instalado), é baseado na ideia de que se um processador não funciona direito, ele ainda pode ser usado.


if (1==2)
{
    System.out.print("O seu processador está com problemas, compre outro ou contate o suporte");
    System.out.close();
}

Observe o resultado: (pelo menos com o meu processador)


  supoesdret cmpolms opeotoo onaeospre

(No meu caso o processador comia um caractere e deixava outro)

Note que caso este código seja executado, é um indício que o processador por ora instalado está apresentando mal-funcionamento, e gentilmente aconselha o usotário(...) digo usuário a tomar uma ação cabível.

Magic Number[editar]

No mundo da POGramação é comum surgirem números com propriedades mágicas desconhecidas. Tais números aparecem lá no meio do código-fonte, ninguém sabe porque e nem o que significam, mas se forem mudados tudo dá errado. O funcionamento correto do universo depende destes números. Por exemplo:

  if (x + y > 17) {
     a = 4;
  } else {
     a = 9;
  }

  if (totalDeElementos > 1200.0) h.x += 12;

Outro exemplo, retirado de um sistema real:

if(calendarIndice.get(Calendar.YEAR) == calendarAtual.get(Calendar.YEAR)) {
  if (calendarIndice.get(Calendar.MONTH) < calendarAtual.get(Calendar.MONTH) - 3) {
    forward = "failureExclusao";
  }
}
if(calendarIndice.get(Calendar.YEAR) < calendarAtual.get(Calendar.YEAR)) {
  if (calendarIndice.get(Calendar.MONTH) <= calendarAtual.get(Calendar.MONTH) + 8) {
    forward = "failureExclusao";
  }
}

Strombolic Bridge (ou, DRIBLE DA VACA)[editar]

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 !!!


Fagueiro Pattern[editar]

O Fagueiro Pattern busca a reutilização e o reaproveitamento do código ao EXTREMO!!!. Esse pattern é tão complexo que não conseguimos expressar em um modelo UML como o caso de alguns modelos poucos conhecidos como o Singleton.

Veja uns dos exemplos do Fagueiro Pattern em uma classe de negócio que faz a insercao numa base de Dados dos seus próprios dados. No nosso exemplo a classe se chama Pessoa.

Assinatura do método presente na Pessoa

void inserir(Pessoa p);

O Fagueiro Pattern é sutil nesse caso, mas podemos reparar que ela recebe como parametro uma instancia da classe Pessoa, ou seja, você pode inserir a própria classe através do comando ou uma outra instancia qualquer!!! Altamente flexivel e tendendo ao infinito na questão do reaproveitamento, além do fato de transmitir uma segurança e garantia ao programador pois você tem CERTEZA qual instancia irá persistir na base dados pois ela foi passada como parametro.

Pessoa p = new Pessoa();
p.inserir(p);

O Fagueiro Pattern é uns dos poucos Patterns que já prevê conceitos avançados da Física Quantica. Como é o caso do booleano de três valores, aonde temos o bit macho, bit femea e o bit viadinho.

Phoenix Exception[editar]

A Phoenix Exception consiste em um sistema que nunca morre, pois assim como a Phoenix, ele sempre renasce das cinzas.

Segue um exemplo da Phoenix Exception.

void inserir() {
	try {
		//realiza alguma ação.
	} catch (Throwable e) { //Aqui a Phoenix renasce...
		Thread.sleep(1000); //Espera um pouco e aproveita para usar o pattern: Pensamento Positivo.
		inserir();
	}
}

Com a Phoenix Exception implementada, seu sistema estará completamente imune de falhas já que que sempre que acontecer alguma M****, feita por algum POGramador, ele renascerá das cinzas e tentará executar o que falhou no primeiro ciclo de vida.

GRUD[editar]

É pronunciado "GRUDI", tal qual aqueles grudes que se "encontra" nas calçadas e não larga mais do seu pé. Define Gambiarra de Recover, Update e Delete. Claro que ele acaba fazendo mais coisa, mas se trata daquele padrão velhaco usado para criar telinhas para recuperação, atualização, inserção e deleção de registros em sistemas. Todos o odeiam, mas raramente escaparam de um desses. O padrão já é algo arquitetural. Áreas como bancos, comércios, são praticamente frameworks de GRUDs.

O que os olhos não veêm, o coração não sente[editar]

Também conhecida como técnica do avestruz (enfie a cabeça na terra e ignore o resto do mundo).

O verdadeiro POGramador não liga para todos os 2752 warnings que o compilador emite ao processar seu código. Entretanto, não é bom deixar esses warnings aparecerem cada vez que alguém faz um build do sistema. Lembre-se que existem os estagiários que não conhecem a arte do POG e que irão tentar remover os warnings um a um.

Todo bom compilador POG tem um modo de não emitir os warnings. O GCC, clássico compilador da GNU para C e C++, tem uma flag "-w" ("W" minúsculo, não confunda) que inibe todos os warnings da compilação.

O compilador Java também tem essa possibilidade. E, mais POG que colocar flags na compilação, é colocar no código em si! Veja alguns exemplos de warnings para desabilitar:

  • Variável não usada. Perfeito para auxiliar em patterns do tipo Static Spree
 public class MyClass {
   @SuppressWarnings("unused")
   private static int A, B, C, D, E, F, G, H, I, J, K, L, M;
 }
  • Campo oculta outro (field hides another field). Como dita os preceitos do POG, os métodos e atributos e variáveis de uma classe devem ter sempre o mesmo nome, para não precisar decorar milhares de nomes diferentes.
 @SuppressWarnings("hiding")
 public class A {
   public int teste;
   public void teste() {
     int teste = this.teste;
   }
 }
 @SuppressWarnings("hiding")
 public class B extends A {
   public int teste;
   public void teste() {
     int teste = this.teste + super.teste;
   }
 }
  • Ou, se você não quer decorar todas as diretivas (afinal, o fim de semana já está próximo demais):
 @SuppressWarnings("all")
 public class A {
   public int teste;
   public void teste() {
     int teste = this.teste;
   }
 }

If Always[editar]

Padrão de projeto que consiste em verificar sucessivamente a mesma condição para ter certeza de que o que é certo é certo, ou não. Este padrão de projeto era muito utilizado quando os POGramadores ainda não tinham o completo domínio sobre o padrão Else Forever, pois a estrutura IF ELSE era considerada um recurso muito avançado da linguagem. Exemplo:

  function ContaBaixada(numConta :integer):boolean;
  begin
    // Instrução para verificar se a conta está baixada
  end;

  procedure FazQualquerCoisa(numConta :integer);
  begin
    if ContaBaixada(numConta) then
    begin
      // Faz alguma coisa aqui
    end;

    if ContaBaixada(numConta) then
    begin
      // Faz outra coisa aqui
    end;

    if ContaBaixada(numConta) then
    begin
      // Faz mais um monte de coisa aqui
    end;

    if NOT ContaBaixada(numConta) then
    begin
      // ...
    end;
  end;

MVCKill DesignPatterns[editar]

Padrão de projeto que consiste em copiar a chamada ao modelo de dados abrindo várias conexões ao mesmo tempo, aproveitando todas as técnicas de pool de conexões, só para garantir que toda a memória do computador seja usada.

Padrões Relacionados: RCP(Reuse by copy and Paste)

Exemplo:

public Report generateReport(Report report) throws ReportException {
		this.report = report;
		
		switch (Report.getFormat()) {
			case RTF:
				return generateRTF();
			case HTML:
				return generateHTML();
			case PDF:
				return generatePDF();
			case XLS:
				return generateXLS();
			case XML:
				return generateXML();
			case CSV:
				return generateCSV();
			default:
				return null;
		}
	}

public Report generateHTML() throws ReportException {
		log.debug("  >> Gerando relatório em HTML..");
		ByteArrayOutputStream baos = new ByteArrayOutputStream();
		
		try {
			DAOFactory factory = DAOFactory.getDAOFactory(Constantes.DAOType.POSTGRES);
			DocumentoDAO DocumentoDAO = factory.getDocumentoDAO();
			DocumentoVO DocumentoVO = DocumentoDAO.findById(
					Integer.valueOf((String) this.Report.getParameters().get("DocumentoId")));

			ByteArrayInputStream bais = new ByteArrayInputStream(DocumentoVO.getImagemArquivo());
			
 			JasperPrint jasperPrint = (JasperPrint) JRLoader.loadObject(bais);
 			
			JRHtmlExporter htmlExporter = new JRHtmlExporter();
			htmlExporter.setParameter(JRExporterParameter.JASPER_PRINT, jasperPrint);
		    htmlExporter.setParameter(JRExporterParameter.OUTPUT_STREAM, baos);
		    htmlExporter.exportReport();
  			
  			this.Report.setFile(baos.toByteArray());
		    this.Report.setContentType(Constantes.ContentType.HTML.toString());
		    this.Report.setExtContentType(Constantes.ExtensionType.HTML.toString());
		} catch (DAOException e) {
			throw new ReportException(e);
		} catch (JRException e) {
			throw new ReportException(e);
		} 
		
		return this.Report;
	}

	
	public Report generatePDF() throws ReportException {
		log.debug("  >> Gerando relatório em PDF..");
		
		try {
			DAOFactory factory = DAOFactory.getDAOFactory(Constantes.DAOType.POSTGRES);
			DocumentoDAO DocumentoDAO = factory.getDocumentoDAO();
			DocumentoVO DocumentoVO = DocumentoDAO.findById(
					Integer.valueOf((String) this.Report.getParameters().get("DocumentoId")));

			ByteArrayInputStream bais = new ByteArrayInputStream(DocumentoVO.getImagemArquivo());
			
 			JasperPrint jasperPrint = (JasperPrint) JRLoader.loadObject(bais);
 			
  			byte[] bytes = JasperExportManager.exportReportToPdf(jasperPrint);
  			
  			this.Report.setFile(bytes);
  			this.Report.setContentType(Constantes.ContentType.PDF.toString());
	        this.Report.setExtContentType(Constantes.ExtensionType.PDF.toString());
		} catch (DAOException e) {
			throw new ReportException(e);
		} catch (JRException e) {
			throw new ReportException(e);
		} 
		
		return this.Report;
	}

	
	public Report generateXLS() throws ReportException {
		log.debug("  >> Gerando relatório em XLS..");
		ByteArrayOutputStream baos = new ByteArrayOutputStream();
		
		try {
			DAOFactory factory = DAOFactory.getDAOFactory(Constantes.DAOType.POSTGRES);
			DocumentoDAO DocumentoDAO = factory.getDocumentoDAO();
			DocumentoVO DocumentoVO = DocumentoDAO.findById(
					Integer.valueOf((String) this.Report.getParameters().get("DocumentoId")));

			ByteArrayInputStream bais = new ByteArrayInputStream(DocumentoVO.getImagemArquivo());
			
 			JasperPrint jasperPrint = (JasperPrint) JRLoader.loadObject(bais);
 			
 			JRXlsExporter xlsExporter = new JRXlsExporter();
			xlsExporter.setParameter(JRExporterParameter.JASPER_PRINT, jasperPrint);
		    xlsExporter.setParameter(JRExporterParameter.OUTPUT_STREAM, baos);
		    xlsExporter.exportReport();
  			
  			this.Report.setFile(baos.toByteArray());
		    this.Report.setContentType(Constantes.ContentType.XLS.toString());
		    this.Report.setExtContentType(Constantes.ExtensionType.XLS.toString());
		} catch (DAOException e) {
			throw new ReportException(e);
		} catch (JRException e) {
			throw new ReportException(e);
		} 
		
		return this.Report;
	}

	
	public Report generateRTF() throws ReportException {
		log.debug("  >> Gerando relatório em RTF..");
		ByteArrayOutputStream baos = new ByteArrayOutputStream();
		
		try {
			DAOFactory factory = DAOFactory.getDAOFactory(Constantes.DAOType.POSTGRES);
			DocumentoDAO DocumentoDAO = factory.getDocumentoDAO();
			DocumentoVO DocumentoVO = DocumentoDAO.findById(
					Integer.valueOf((String) this.Report.getParameters().get("DocumentoId")));

			ByteArrayInputStream bais = new ByteArrayInputStream(DocumentoVO.getImagemArquivo());
			
 			JasperPrint jasperPrint = (JasperPrint) JRLoader.loadObject(bais);
 			
			JRRtfExporter rtfExporter = new JRRtfExporter();
		    rtfExporter.setParameter(JRExporterParameter.JASPER_PRINT, jasperPrint);
		    rtfExporter.setParameter(JRExporterParameter.OUTPUT_STREAM, baos);
		    rtfExporter.exportReport();
		    
		    this.Report.setFile(baos.toByteArray());
		    this.Report.setContentType(Constantes.ContentType.RTF.toString());
		    this.Report.setExtContentType(Constantes.ExtensionType.RTF.toString());
		} catch (DAOException e) {
			throw new ReportException(e);
		} catch (JRException e) {
			throw new ReportException(e);
		} 

		return this.Report;
	}

	
	public Report generateXML() throws ReportException {
		log.debug("  >> Gerando relatório em XML..");
		ByteArrayOutputStream baos = new ByteArrayOutputStream();
		
		try {
			DAOFactory factory = DAOFactory.getDAOFactory(Constantes.DAOType.POSTGRES);
			DocumentoDAO DocumentoDAO = factory.getDocumentoDAO();
			DocumentoVO DocumentoVO = DocumentoDAO.findById(
					Integer.valueOf((String) this.Report.getParameters().get("DocumentoId")));

			ByteArrayInputStream bais = new ByteArrayInputStream(DocumentoVO.getImagemArquivo());
			
 			JasperPrint jasperPrint = (JasperPrint) JRLoader.loadObject(bais);
 			
			JRXmlExporter xmlExporter = new JRXmlExporter();
		    xmlExporter.setParameter(JRExporterParameter.JASPER_PRINT, jasperPrint);
		    xmlExporter.setParameter(JRExporterParameter.OUTPUT_STREAM, baos);
		    xmlExporter.exportReport();
		    
		    this.Report.setFile(baos.toByteArray());
		    this.Report.setContentType(Constantes.ContentType.TEXT.toString());
		    this.Report.setExtContentType(Constantes.ExtensionType.XML.toString());
		} catch (DAOException e) {
			throw new ReportException(e);
		} catch (JRException e) {
			throw new ReportException(e);
		} 
		
		return this.Report;
	}

	
	public Report generateCSV() throws ReportException {
		log.debug("  >> Gerando relatório em CSV..");
		ByteArrayOutputStream baos = new ByteArrayOutputStream();

		try {
			DAOFactory factory = DAOFactory.getDAOFactory(Constantes.DAOType.POSTGRES);
			DocumentoDAO DocumentoDAO = factory.getDocumentoDAO();
			DocumentoVO DocumentoVO = DocumentoDAO.findById(
					Integer.valueOf((String) this.Report.getParameters().get("DocumentoId")));

			ByteArrayInputStream bais = new ByteArrayInputStream(DocumentoVO.getImagemArquivo());
			
 			JasperPrint jasperPrint = (JasperPrint) JRLoader.loadObject(bais);
 			
			JRCsvExporter csvExporter = new JRCsvExporter();
			csvExporter.setParameter(JRExporterParameter.JASPER_PRINT, jasperPrint);
			csvExporter.setParameter(JRExporterParameter.OUTPUT_STREAM, baos);
			csvExporter.exportReport();
		    
		    this.Report.setFile(baos.toByteArray());
		    this.Report.setContentType(Constantes.ContentType.TEXT.toString());
		    this.Report.setExtContentType(Constantes.ExtensionType.CSV.toString());
		} catch (DAOException e) {
			throw new ReportException(e);
		} catch (JRException e) {
			throw new ReportException(e);
		} 

		return this.Report;
	}
}

DCDP[editar]

Defensive Code Design Pattern

Espécie de código feito por todo POGramador para tornar o seu software imune a bugs. Como exemplo de código demonstrado abaixo.


if(quote.getOpportunity().getValor() != null && !"0".equals(quote.getOpportunity().getValor()) 
	&& !"".equals(quote.getOpportunity().getValor()) && quote.getOpportunity().getValor().intValue() > 0){
                {
                    //faz algo              
                }
            }
else{
	throw new BusinessException("Services.FODEU");   
}

Uncommented Commented Code[editar]

Técnica extrema, que combina o CI ou CCI - Invisible/Comment Code Implementation com o Reversal Boolean, formando um método de comentário de código digno de um mestre do POG. Exemplo (real):


//codigo inutil...
 if (false)
 {
     DetailConfiguration dtConfig = new DetailConfiguration();
     dtConfig.RelationName = "MasterDetail";
     dtConfig.Title = "Cores";
     dtConfig.InitializingInsertionRow += new EventHandler<InitializingInsertionRowEventArgs>(dtConfig_InitializingInsertionRow);
     Column xceedColumn = new Column();
     xceedColumn.FieldName = "ID";
     xceedColumn.Visible = false;
     dtConfig.Columns.Add(xceedColumn);
     gridCombinacao.DetailConfigurations.Add(dtConfig);    
}

Only Once[editar]

Também conhecida como OO (Only Once - Somente Um Vez), é uma técnica apurada para garantir que o código seja executado apenas 1 (uma) vez a cada execução. Relatos provam que muitos POGramadores utilizando OO ao som da querida música de Nana Caymmi, "Solamente Una Vez" - Tema da Novela Laços de Família.

Abaixo, exemplo real (em ABAP, linguagem base do POG):


DO 1 TIMES.
  INCLUDE z_facaXXX.
ENDDO.

Podemos perceber que o código será executado APENAS 1 vez, não gerando a/pre>

Obviamente, pelos nomes das variáveis, é muito fácil perceber que esse código calcula as raízes de uma função de segundo grau de acordo com a fórmula de Bhaskara.

Maitabom POG[editar]

ssim confusões e/ou execuções repetidas.

String Sushi Man[editar]

Técnica muito difundida entre os POGramadores PHP. Consiste em utilizar apenas um, ou poucos parâmetros String e nessa String definir infinitas regras. Normalmente é utilizada para matar completamente a necessidade de utilizar técnicas da POO (Programação Orientadas a Objetos, a principal inimiga da POG). Em um ponto do POGrama você concatena todas as informações numa String, separando com um delimitador que você sabe que não corre o risco de aparecer no meio das informações, como #, % ou @. Depois em outro canto do programa basta separar essas strings partindo-as em várias partes e criando regras mirabolantes. Muito semelhante à técnica utilizada pelos Sushi Mans, que fazem toda uma coluna de sushi e depois a divide em partes e fica fazendo malabarismos para cada tipo de sushi. Veja um exemplo:



  public Tabela montaTabela(Lita itens, String ...colunas){

     for(String coluna : colunas){

          String[] campos = coluna.split(",");
         ///faz malabarismos com os valores
     }

     // Algum código suplementar...
  }

Uso desse método:


  Tabela tabelaPronta = montaTabela(listaItens, "Coluna1, itemColuna, sortable, 10%", "Coluna2, itemColuna2, 25%", "itemColuna, sortable, 10%");

Unique never Exists[editar]

Gambi design pattern largamente utilizado em sistemas vivos para projetos web nos quais os programadores das tabelas originais desprezaram o uso da cláusula UNIQUE, afinal de contas, esta é descartável...

Exemplo prático aplicado a um select de uma tabela que retorna quantas visitas únicas um site teve (estrutura da tabela: table Visualizacao { integer id, text ip, timestamp data }

select count( * ) from (Visualizacao join Visualizacao as Gambi)
  where (Gambi.id <> Visualizacao.id and Gambi.ip <> Visualizacao.ip and
  datediff(Visualizacao.data, Gambi.data) <> 0)

Ingratitude with Ancestors[editar]

Técnica avançada de POG, tão avançada que algumas linguagens não dão suporte a ela, obrigando o POGramador a trocar para uma linguagem que suporte completo ao POG, como é o caso do PHP. Consiste em criar uma subclasse e em seu construtor, chamar o construtor da sua classe pai apenas no final do método. (Exemplo Real) Em PHP:

class Pessoa {
  protected $tipo_pessoa;
  public function __construct() {
     $this->tipo_pessoa = 'F'; //Pessoa física
  }
}

E em sua subclasse, fazer:

class PessoaJuridica extends Pessoa {
  public function __construct() {
     $this->tipo_pessoa = 'J'; //Pessoa Jurídica
     parent::__construct();
  }
}

Por motivos claros, o comportamento desejado não é obtido. Solução? Alterar a classe pai!

class Pessoa {
  protected $tipo_pessoa;
  public function __construct() {
     if ( ! isset($this->tipo_pessoa) ) //Adiciona valor somente se classe filha não tiver feito!
         $this->tipo_pessoa = 'F';
  }
}

Dessa forma toda alteração feita nas classes filhas passa a necessitar de alterações na classe pai, mostrando que a culpa de uma programação mal-feita é sempre da classe pai.

Chameleon Behaviour[editar]

Este Gambi Design Pattern foi catalogado por uma grande consultoria muldialmente conhecida, inclusive entre jogadores de Golf psicopatas sexuais. Consiste em transformar um método coeso, que até então fazia apenas o que lhe era proposto, num método com dois ou mais comportamentos. Isso tudo para que premissas do tipo "atomicidade" entre casos de uso sejam atendidas de acordo com o contrato. É um pattern semi-atômico antes do modelo orbital ser inventado, pois 90% dos desenvolvedores não o entendem. No exemplo a seguir, é demonstrado um método "excluir" que após excluir uma Pessoa, retorna a lista de Pessoas atualizada (sem a pessoa que foi excluida):

class PessoaBoLoVo() {
..
    public List<Pessoa> delete(Pessoa p) {
        String sql = "delete from pessoa where :id = "+p.getId();
        SqlExecuter.execute(sql);
        sql = "select * from pessoa";
        return SqlExecuter.executeList(sql);
    }
}

class Pessoa {
..
  public List<Pessoa> excluir(Pessoa p) {
        return new PessoaBoLoVo().delete(p);
  }
}

Com isso, foi possível economizar uma "transação" no banco, pois onde eram duas "excluir" e "listar", virou apenas uma!

Uma variação desse pattern pode ser observada a seguir (auxiliando-se de outro pattern #gato preto num quarto escuro#):

public Object operacao(int tipo, Map<Object, Object> valores) {
   if (tipo == 1) {
       //codigo para excluir..
   } else if (tipo == 2) {
       //codigo para listar..
   }
//etc..
}

Clone Wars[editar]

Clone Wars se aplica a procedures ou funções onde ninguém avaliou o plano de execução e cujo código foi propagado usando a POG Patern RCP ( Reuse by Copy Paste), largamente usada pelos pogueiros. Como a única avaliação de performance foi o tempo de execução, em um banco onde as tabelas tinham dezenas de registros, com o tempo essas procedures consomem todos os recursos do servidor e saem no tapa por causa de 1 ciclo de processador e fila do disco.

Nameless Coding[editar]

Esta técnica largamente utilizada em editores visuais, como Visual Studio, Visual Basic e Delphi, consiste em arrastar controles na tela, mantendo o nome sugerido pela IDE. Exemplo de código usando a Nameless Coding:

private void button1_Click(object sender, System.EventArgs e)
{
	if(TextBox1.Text == "")
		Label4.Text = "Este campo não pode ficar vazio!";
	else
	{
		Label2.Text = "Cadastro efetuado!";
		ListView1.Items.Clear();

		Form2 form2 = new Form2();
		form2.Show();
	}
}

Observem a utilização persistente da técnica ao instanciar um objeto Form2 com o nome de variável form2.

I. S. C. D. V.[editar]

O I. S. C. D. V. (If's São Coisas De Viadinhos) é um design pattern muito eficiênte, pois reduz a complexidade de uma linguagem de programação. A idéia central é utilizar switch cases em vez de if's. Com isso, qualquer linguagem se torna mais simples de aprender, reduzindo o tempo e o custo de treinamento de profissionais. Um exemplo de código em PHP:

switch ($variavel)
{
       case true: //faz tal coisa
       case false: //faz outra coisa
}

HOC[editar]

HOC (Html Orientada à Coordenada) é um padrão amplamente utilizada por grandes programadores que consta em posicionar os objetos html a partir de coordenadas, lembrando que essa técnica é extremamente eficaz em todos os browsers e em todas as resoluções de telas.

EX: Supondo que o programador deseje alinhar uma figura ao lado da outra em html:

-Sem HOC:
...
  <table>
    <tr>
     <td> <img src="caminhoDasIndias.png"/></td>
     <td> <img src="outraImagem.png"/></td>
    </tr>
  </table>
...

-Com HOC:
...
<img src="caminhoDasIndias.png" style="position:absolute; left:0px+20%-x*y; top:32px+cos95º" /></td>
<img src="outraImagem.png" style="position:absolute; left:50%+log2; top:64px+sen180º*z" /></td>
...

ExceptionToBoolean[editar]

Este é um padrão muito usado nos projetos onde a documentação segue uma filosofia Sou Foda, ou seja, apenas o caminho feliz é necessário. Consiste em retornar um valor qualquer no bloco catch de uma expressão, já que o sistema nunca vai cair nesse bloco mesmo.

Exemplo:


public boolean isResultadoDivisaoMaiorCinco(int a, int b) {
  try {
    // ok, lembrei que uma divisão por zero vai falhar
    return (a / b) > 5;
  } catch (Exception e) {
    // mas como o sistema é fodástico ele nunca vai tentar dividir por zero
    // pq isso é coisa de gente fraca
    return false;
  }
}


ConcatByHashing[editar]

Tecnica avançada de concatenação de string baseado em busca hashing. No exemplo abaixo, para completar uma string com zeros a esquerda, foi utilizada essa técnica. (Obs: baseado em um codigo real, infelizmente)


/* funcao de  complemento (Zeros a esquerda) para codigo*/
public static string ComplementaCodigo(String _cod)
{
    _complementoCodigo = new string[11];
    _complementoCodigo[0] = "0000000000";
    _complementoCodigo[1] = "000000000";
    _complementoCodigo[2] = "00000000";
    _complementoCodigo[3] = "0000000";
    _complementoCodigo[4] = "000000";
    _complementoCodigo[5] = "00000";
    _complementoCodigo[6] = "0000";
    _complementoCodigo[7] = "000";
    _complementoCodigo[8] = "00";
    _complementoCodigo[9] = "0";
    _complementoCodigo[10] = "";

return _complementoCodigo[_cod.Length] + _cod;

}


Técnica P.E.P. (People “Entregration” Processes)[editar]

Técnica de automatização de processo através da integração com componentes do tipo People (vulgo carinha). Durante a execução, o sistema estimula o componente People através de uma interface padrão (vulgo email) e ENTREGA uma tarefa para o People realizar até um momento definido. Caso o componente People execute sua função de forma correta até o período definido (pois é pago para fazer isso, não é mais do que sua obrigação) o sistema efetua uma execução com sucesso. Caso o componente não execute sua função de forma correta e no tempo correto, o sistema pode ficar em espera eterna (while forever), inconsistente ou erro irreversível. Nesses casos, deve-se substituir o componente People por um mais competente.


Esse padrão é inspirado na técnica de automação residencial apresentada pelo chapolin conhecido como "Pepe ja tirei a vela" ( conheça mais no artigo Pepe_(Chapolin_Colorado) e veja uma demonstração http://www.youtube.com/watch?v=ftJMyfxp32Y ).


Vejamos alguns cenários do uso da técnica (infelizmente, baseado em casos reais).

- Você precisa agregar em uma base de clientes indicadores de perfil. Ao invés de investir em desenvolver algoritmos complexos de analise de perfil, através do padrão P.E.P podemos realizar a entrega automaticamente de arquivos para o componente People incluir esses indicadores e posteriormente obter os mesmo arquivos com os dados preenchido.
- Um cliente teve uma venda estornada, mas não refletiu no sistema. Então o cliente liga para a central, apresentando o problema. Então o atendente libera manualmente porque o sistema só libera uma vez por semana. Nesse caso é uma empresa que está trocando a implementação de P.E.P para “tipo Online, só que Batch” mas mantém o P.E.P. em paralelo devido sua robustez.


Benefícios esperados:
- Facilmente implementável
- Fácil evolução (só ensinar o People a fazer direito que o sistema funciona melhor)
- Crescimento do País (com geração de milhares de empregos)


HnS Pattern (Hide-and-Seek Pattern ou Padrão Esconde-esconde)[editar]

É um padrão de desenvolvimento amplamente utilizado em módulos ERP, em especial os escritos em VB6 e Delphi.


Este padrão dita que, a única forma de se visualizar o funcionamento da regra de negócios é durante o funcionamento do software. No momento em que a regra de negócios precisa passar por uma manutenção, ela se esconde. A regra pode se esconder em qualquer lugar: Na classe estática global do projeto, na interface, no banco de dados, na DLL de comunicação entre servidores, em um arquivo TXT adicionada como "Resource".


Em vários casos foram observados uma evolução natural do HnS, onde ele além de se esconder, se divide em vários outros procedimentos, criando assim o Puzzle Pattern.


Utilizando HnS, o POGramador já estará preparando o projeto para inserção de técnicas de Ofuscação de Código, colaborando assim para a segurança do código fonte.


Puzzle Pattern (Padrão Quebra-cabeças)[editar]

É uma forma avançada do HnS Pattern, utilizando principalmente os recursos de Ofuscação de Código e IoC (Indetermination of Calls), criando assim um verdadeiro inferno na vida do POGramador que precisa dar manutenção no código.


IoC Methodology (Indetermination of Calls ou Indeterminação das Chamadas)[editar]

Técnica de programação muito utilizada em conjunto com o HnS. Consiste em nomear as chamadas de métodos e funções de forma a não determinar o que este faz exatamente. Alguns exemplos:

public class ProcessosGerais {
    // classe de encapsulamento dos Processos do Pedido de Venda
    public void Processando(int valor) {
        // valida se o cliente está bloqueado
    }
    public void Gravando() {
        // bloqueia a interface preparando para salvar o pedido
    }
}

E agora segue um exemplo real em VB6:

Módulo: FuncoesGerais.bas

Public Function Barra(Nome_Menu As Menu) As String
    If Nome_Menu.Checked = False Then
        Nome_Menu.Checked = True
    Else
        Nome_Menu.Checked = False
    End If
End Function

Bicicleta Voadora (ou Suco do Chaves)[editar]

Técnica avançada de estruturação de classes, que funciona da seguinte forma. Primeiro, cria-se uma classe abstrata básica com as funcionalidades gerais. Depois criam-se implementações, mas com um pequeno porém que dará todo aquele gostinho especial. Imaginemos que a classe básica abstrata seja Veículo, e que desejamos criar duas implementações, o Avião e a Bicicleta. A implementação da técnica consiste justamente em embutir uma classe concreta na classe abstrata superior.

Assim, em nosso exemplo, a classe Veículo poderia ter as mesmas capacidades de um Avião. Portanto, obtemos um resultado surpreendente e inovador, quase mágico, onde qualquer veículo poderá agora voar! Ou no caso em que a classe Bicicleta é embutida, qualquer veículo passaria a ser então considerado ecologicamente correto, automaticamente, seja ele um avião barulhento, um ônibus movido a diesel, ou até mesmo um navio velho carregado de petróleo. Esta técnica é considerada por alguns gênios, tais como os engenheiros do Google, como "brilhante".

Retorno invertido[editar]

Técnica bastante utilizada para alterar o retorno de um método, fornecendo um melhor controle de fluxo. Primeiramente cria-se uma propriedade "retornoInvertido" na classe. Após esta setada pela classe que realiza a chamada fazemos a verificação:

if($this->retornoInvertido){
    if($retorno == true){
        return false;
    }
    else{
        return true;
    }
}
else{
    if($retorno == true){
        return true;
    }
    else{
        return false;
    }
}
v d e h
ARTIGO COMPLEMENTAR
v d e h
Jornal2.jpg
Não entende este artigo? Acha que é humor privado? Antes de fazer alguma besteira nesta página, leia o artigo Programação Orientada a Gambiarras para ter sentido e volte aqui para entender e achar engraçado (ou não).
Jornal2i.JPG

</td> ...