Origem: Desciclopédia, a idiotice livre.
Padrão de Projeto Gambis
As Soluções Técnicas de Contorno ou Engenharias de Emergência (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 fazem esprecisam 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 da metodologia de medição de software denominada Conceito Holístico Unilateral para Tipificação Estrutural, mais conhecido pela sua abreviação: C.H.U.T.E.
Gambi Design Patterns catalogados
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”
É 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 anti-vírus detectem como tal.
Conversão de Tipos
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
Pattern Exception Success
Usado geralmente para indicar que algo foi realizado com sucesso.
public static void somar(int a, int b) { System.out.println(a+b);
throw new RuntimeException("Operação realizada com sucesso!");
}
Sleeper
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. Isso prova 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());
}
}
}
QPÉ
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
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.
M.A.R.R.E.T.A.
Método Alternativo de Retificaçã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
Consiste na capacidade do analista de sistemas sobrecarregar o estagiário ou o técnico mais próximo com todas as suas funções, desde interação com clientes até desenvolvimento de casos de uso e bancos de dados, aproveitando ao máximo toda a energia gambiarrizadora que essas categorias possuem. Sabendo que fica mais fácil para o programador entender e realizar a POGização do sistema se ele conversar diretamente com o usuário, o analista sabiamente permite que o programador realize os contatos com o cliente, permitindo assim que o analista realize funções que condizem mais ao seu cargo, como acessar a desciclopédia 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).
Apellation Number Technic
É um método muito utilizado por MVP’s (MOST VALUABLE POGrammer), que resolve 90% dos BUGs sem que precise queimar nenhum neurônio. POGramadores experientes sabem que: Deu um BUG no sistema? Digita -1 em algum lugar que funciona!!! Ainda não se sabe o motivo, e nem precisa saber. apenas funciona e pronto.
WYSIWYG
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 “em desenvolvimento”.
Else Forever
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
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
Técnica muito útil em, principalmente em Java. Use ela quando é necessário utilizar a classe acima de uma classe in place, 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 eh 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
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
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
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)
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 pára de compilar, da interface ao código de banco e dados, e até o Microsoft Word passa a dar problemas estranhos.
(Descrito originalmente na revista Mundo Java #17)
Old Times of Yore Pattern
É 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
Por um legítimo impulso gambiarrizador solucionador de problemas, o desenvolvedor salpica um monte de variáveis com nomes sensacionais como “newCounter2“, “jaTrocouDeAba“, “passouPorAqui“, “numeroMagico“, “naoAchou“, “anterior5“, “atual5“,”anteriorDoAnterior5“, “quatroDaManha” (caso em que se aplica a técnica de Programação de Véspera –> Caso verídico) e etc.
UTF-8 Abuse
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:
-
nó(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çaIsso
Obs.: Quando usar acentuação em classe, não use JAR no seu software, porque não funciona. A compactação JAR dá problema quando compacta arquivos com acentuação. (Isso é sério) Duvida? Então olhe isso: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4244499
RCP Pattern
Significa Reuse by Copy-and-Paste (Reúso por Copiar e Colar). O RCP dita que, na pressa, quando não dá pra fazer a coisa por herança, basta copiar e colar, quantas vezes for necessário. Em geral se espera que futuras alterações sejam feitas por outros trouxas, digo programadores, perdão. Os trechos de código são copiados de todo e qualquer lugar possível, geralmente de outro programador (muitas vezes o estagiário) ou código da internet, para criar partes funcionais do programa. Utiliza-se a do “Ctrl+C” e “Ctrl+V” para juntar as partes e adaptá-las para funcionar, por tentativa e erro. Leva um considerável tempo para se adaptar o programa, e um número absurdo de compilações, mas pelo menos pode-se dizer que foi você quem fez o código. Este pattern também é conhecido como “Contra o C e Contra o V”.
CCOP (Ctrl+C, Ctrl+V Oriented Programming)
Novo estilo de programação que implementa fortemente o pattern RCP. Seguindo o dito por Lavoisier, este novo paradigma promete revolucionar o mercado. Não é recomendado para inicitantes em POG.
BCDR Pattern
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.
justKillIf
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 numero por i, não podendo vir 0
if(i == 0) return; Divisao.resp = Classe.numero/i;
este padrão de projeto ja foi utilizado com sucesso em aplicações para jogos de celular e existem outras inumeras utilizações possiveis.
Mega Zord
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 todos 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 saida, Object... maisDados)
throws Exception { //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.
There is No Spoon
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 evitam 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
É 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,… 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
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
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
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];
}
Chaotic Experimentation
Padronização de construção de funções para continuar a executar o programa mesmo que dê pau em alguma rotina. Exemplo clássico: On Error Resume Next (Visual Basic).
Timeline Relationship-Less
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 reconstró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 idéia.
Generic-One-Table-Fits-All
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.
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
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 voce deseja por dia, após o a captura desses dados criar-se uma coluna para cada dia que voce deseje consolidar.
Se voce quiser que este relatório seje diário coloca-se um job no SQL para que rode essa Store Procedure todo dia, assim voce obtem um relatório diario, pois será acrescentado a coluna do dia na sua tabela.
Voces devem estar se perguntando, mas essa tabela ficará enorme depois de alguns dias, meses, anos… Mas esta técnica prever esse comportamento. Para que este tipo de comportamento não aconteça 2 providencias são necessárias:
1 - Alertar ao usuario que é possivel 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, voce 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
O Power-Cursor é um recurso utilizado para tornar suas queries mais bonitas. A regra é simples: esqueça que uma query SQL pode trabalhar simultaneamente em mais de um registro, 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.
PogManager Pattern
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
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
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“.
Controller Confusion
Tática que permite uma menor escrita de classes no sistema. Consiste simplesmente em eliminar o M do padrão MVC, ficando um padrão muito mais legal – o VCC (“View/Controller Confusion”, ou “Vai catar coquinho”). Alguns tem sugerido inclusive a eliminação do V – ou seja, ficando apenas o CC (Codigo coco para os usuarios mais intimos) – a lógica, o modelo, os templates, o HTML, tudo e mais um pouco dentro do controller confusion. Como você pode ver, o padrão cêcê faz jus ao nome.
DB is our God
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
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
Também conhecido como Textbox Invisível 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
É 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
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, geralmente provocando erros intermitentes, tais como anos bissextos ou então em horários que antecedem 10 horas da manhã, pois a hora vem com apenas 1 dígito e isto atrapalha o cálculo.
Pensamento positivo
Também conhecido como Wishful thinking. Este design pattern é extensivamente utilizado no ciclo de depuração do código POG:
- Execute o código.
- Não funciona?
- Pensamento positivo, e tente novamente.
Repita o ciclo até que o problema desapareça espontaneamente.
Perfectness Execution
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 void alterar( Object valor1, Object valor2 )
{
...
} public static void main( String args[] )
{
...
if ( alterar( valor1, valor2 ) == void )
{
System.out.println( "Operação concluída com sucesso!" );
}
}
}
You Shall Not PASS!
Vulgarmente conhecido como “Vagões de ORs e ANDs”, visa bloquear todo e qualquer erro que o poguizador não tem a menor idéia 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)
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
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 Javatry { fazAlgumaCoisa(); } catch (Throwable t) {}
try { fazOutraCoisa(); } catch (Throwable t) {}
try { fazMaisOutraCoisa(); } catch (Throwable t) {}
É 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’!
UFB
Uso de Força Bruta
Método muito famoso no meio dos programadores POG.
O método se aplica para solucionar problemas sem perder tempo voltando no código para procurar onde deu errado.
...if (var==20) ChamaMetodoSolucao(var);
else{
var=20;
ChamaMetodoSolucao(var);
}
...
MOPED
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 eleató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
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.
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
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
Um dos grandes problemas enfrentados pela classes de projeto e de escravidão “implementadçã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 (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 majestral.
No Error Pattern
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
“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
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
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
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
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;
}
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 a O valor de A, a ser somado com o valor de B.
* @param 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 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. */
Always/Forever ou Comentários-Eternos
Pode-se dizer, na íntegra, 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
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 saida 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)
Na boca do povo, 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 (aka DELPHI). Tudo indica que N.E.N.E é a versão de Exception Successfull, porem traduzia para delphi. A questão chave é: Trate as exceções…e mande-as fazer EXATAMENTE o que o try NÃO quis fazer por birra. Pratico, Limpo, e rapido. Possivelmente nem mesmo voce ira entender o porque desta implementação ter funcionado tão bem. Não importa, pois: Premissa básica —-> Funcionou? NEM RELA. Há toda uma hierarquia de premissas e POG patterns e, definitivamente, N.E.N.E merece seu lugar destacado.
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 incomodaro 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. Voce 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 usuario que REALMENTE, sua impressora ira achar uma COM disponivel. 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 voce não tivesse acabado o projeto a tempo de deixar o usuario satisfeito.
POG Delegation Aproach
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
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 o POG pattern “Doubleton”!!! Lá vai 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
}