下面这篇文章来自这里：http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns，这篇文章有点意思了，山寨了我们著名的Design Pattern。这篇文章并不是很容易翻译，也许我翻译的不好，大家多指正。另外，这篇文章将失去原有的趣味在于其使用了经典设计模式的单词很相似的单词，一走眼你还以为是正二八经的设计模式。呵呵。所以，我在下文中，我会保留原有的英文单词，并把真正的23个经典设计模式的英文名放在旁边(灰色)。这篇文章和之前的如何写出无法维护的代码有异曲同工，个人感觉都是比较欢乐的。
辞职模式
Resign Patterns
Design Patterns
Ailments of Unsuitable Project-Disoriented Software
Elements of Reusable Object-Oriented Software
概要
1. Cremational Patterns 火葬模式 | Creational patterns 创建模式
1.1 Abject Poverty 一贫如洗 | Abstract Factory 抽象工厂
Abject Poverty 模式能让你的软件相当难测试和维护， 并且需要巨大的财政支出，预算已经完全赤字。
1.2 Blinder 眼罩模式 | Builder 建造模式
Blinder 模式是一个应急有效的解决方案，其不需要考虑需求在未来的变化。目前，我们还不太清楚我们为什么叫Blinder模式，一种说法是他们会在写代码的时候被设计人员戴上眼罩，另一种说法是他们希望在维护代码的时候挖出双眼。
1.3 Fallacy Method 错误方法 | Factory method 工厂方法
Fallacy方法主要是在于处理一些不明显的案例。代码逻辑看上去是正确的，当只要某想要去测试一下，或是某个不明显的案例发生了，那些代码中的错误也就出现了。
1.4 ProtoTry 尝试模式| Prototype 原型模式
ProtoTry 模式一个快速而肮脏的软件开发工作模型的尝试。这个模式的原意本来是想在后面有时间总结一下教训并改进或重写这些代码，但是可惜的是没有时间。所以，这些代码也就成了众所周知的 legacy code - 旧代码。
1.5 Simpleton 傻瓜模式 | Singleton 单例模式
Simpleton 模式，是把一个终极复杂的模式用于那些最最没有价值的工作上。这个模式精确地指出了人员的能力程度。
2. Destructural Patterns 无结构模式 | Structural patterns 结构模式
下面是七个经典的变性模式
2.1 Adopter 领养者模式 | Adapter 适配器模式
Adopter模式提供了一个给那些“孤儿函数”的家。这这些函数和整个大家族别的函数看上去一点也不一样，他们和整个家族的唯一联系就是通过我们的Adopter。
2.2 Brig 监狱模式 | Bridge 桥接模式
Brig 模式也就是那些坏代码的容器类。这就是众所周知的软件模块。
2.3 Compromise 妥协模式 | Composite 合成模式
Compromise 模式主要用来平衡软件开发的工期和质量。 使用这个模式的结果是――劣质的软件 + 延误的工期。
2.4 Detonator 地雷模式 | Decorator 修饰模式
Detonator 模式是极其普通的，在程序中放置一些不易查觉的地雷。一个常见的经典示例是只用两位数来表示年份。这个炸弹已经暴露出来了，并在那等着爆炸！(陈皓注：作者这里说的是千年虫问题，本文写在1997年)
2.5 Fromage 干酪模式 | Facade 外观模式
Fromage 模式让软件看上去满是漏洞。 Fromage 模式让我们的软件像Cheesy(芝士，也有劣质的意思)一样，有大量的奇淫巧技让你的软件没有任何一点可移值性。这个模式和奶酪一样，越是老越是香啊。
2.6 Flypaper 捕蝇纸模式 | Flyweight 享元模式
Flypaper 模式的意思是，代码是由设计的人完成，而由另一个人维护。维护着这个模式的那个写代码的人发现自己被粘住了，而且很有可能在软件失支控制前夭折。
2.7 ePoxy 沥清模式 | Proxy 代理模式
ePoxy 模式主旨把软件的模式紧密地耦合在一起。随着耦合模块的增加，我们就可以看到沾粘它们的沥清。
3. Misbehavioral Patterns 行为不检模式| Behavioral Patterns 行为模式
下面是11个行为不检点模式
3.1 Chain of Possibilities 可能性链模式 | Chain of responsibility 责任链模式
Chain of Possibilities 模式主旨是创造肥大的，拙劣文档的软件模块。没有人知道其功能有多宽泛，其可能性永无止境。也就是我们所说的――无确定性。
3.2 Commando 突击队模式 | Command 命令模式
Commando 模式主旨是用来应付工作，让事情快点完成。这个模式不管封装，只图快快把代码写完。反正不犯法。
3.3 Intersperser 散布模式| Interpreter 解释器模式
Intersperser 模式把一个功能的代码散布在系统的各个地方，其可以让功能无法被测试，修改，以及让人读懂。(陈皓注：这让我想起了以前VB，PB和Delphi的开发，功能的逻辑代码散步在各个组件的不同事件中)
3.4 Instigator 煽动模式| Iterator 迭代器模式
Instigator 模式看上去是良性的，但是其却大规模的以暴力的方式在破坏软件系统。(陈皓注：作者没有做过多的解释，不过，我想到了Windows编程革命史，应该说的就是这个吧)
3.5 Momentum 冲击模式| Memento 备忘模式
Momentum模式让软件大小，内存，CPU，和复杂度成极数级成长。(陈皓注：作者对此没做过多解释，这个特性很像Windows操作系统，每个Windows 的新版本，无论是在尺寸，内存和CPU要求上，和复杂度上都会比上一版有极数级的提高)
3.6 Medicator 用药模式| Mediator 媒介模式
Medicator 模式是一个实时的屠夫一样，其把其它的系统搞得就像被打过强力镇静剂一样没有反应。
3.7 Absolver 免责模式| Observer 观察者模式
Absolver模式表现于那些被以前员工开发的代码的问题。对于现任员工，其可以因为很多代码里历史上的问题而免除被批评，其声称其对软件中的任何问题都不负责。这也是我们从所周知的――“这不是我的代码”。(参看：程序员的借口)
3.8 Stake 利害关系模式 | State 状态模式
Stake 模式表现于那些被现已成为经理的人写的代码中的各种问题。虽然这些问题很不爽，但是经理们在这个软件里的利害关系太高了，所以，不能让任何人重写，因为这代表着我们经理的技术成就。
3.9 Eulogy 颂歌模式 | Strategy策略模式
Eulogy 模式存在于所有的项目中，也就是 Post-Mortem(事后总结分析会)。
3.10 Tempest Method 暴风雨模式| Template Method 模板方法
Tempest Method 主要用在软件快要发布的最后几天。这个模式的物征是，代码中没有注释，并有使用了好几个Detonator Pattern 地雷模式。
3.11 Visitor From Hell 地狱访问者模式 | Visitor 访问者模式
Visitor From Hell 模式一般是在运行时没有检查数组越界的一个巧合。这样一来，我们系统就可以实现Visitor From Hell 模式，因为这样可以造成重要数据的重写。