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