下面这篇文章来自这里:http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns,这篇文章有点意思了,山寨了我们著名的Design Pattern。这篇文章并不是很容易翻译,也许我翻译的不好,大家多指正。另外,这篇文章将失去原有的趣味在于其使用了经典设计模式的单词很相似的单词,一走眼你还以为是正二八经的设计模式。呵呵。所以,我在下文中,我会保留原有的英文单词,并把真正的23个经典设计模式的英文名放在旁边(灰色)。这篇文章和之前的如何写出无法维护的代码有异曲同工,个人感觉都是比较欢乐的。
概要
任何一个熟悉那本由四个人写的经典的设计模式书的朋友,应该知道那本书里的模式都是非常优雅和划时代的。然而,不幸的是,从那些老代码中无法提练出这些模式,因为,在出现这些模式前,大家都不会使用模式。因此,这项工作是从大量的代码中提练出一个模式的目录。这些模式都有充足和永恒的示例。希望你能享受阅读这些模式,但千万不要模仿并使用他们!
1. Cremational Patterns 火葬模式 | Creational patterns 创建模式
下面是五个 cremationalpatterns.
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 无结构模式 | Structuralpatterns 结构模式
下面是七个经典的变性模式
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 ofresponsibility 责任链模式
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 主要用在软件快要发布的最后几天。这个模式的物征是,代码中没有注释,并有使用了好几个DetonatorPattern 地雷模式。
3.11 Visitor From Hell 地狱访问者模式 | Visitor 访问者模式
Visitor From Hell 模式一般是在运行时没有检查数组越界的一个巧合。这样一来,我们系统就可以实现Visitor FromHell 模式,因为这样可以造成重要数据的重写。
链接http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns
原文如下:
Resign Patterns
Ailments of Unsuitable Project-Disoriented Software
by
Michael Duell
mitework@yercompany.com
Abstract
Anyone familiar with the book of patterns bythe Gang of Four [1]
knows that the patterns presented in the bookrepresent elegant
solutions that have evolved over time.Unfortunately, extracting these
patterns from legacy code is impossible,because nobody knew that they
were supposed to be using these patterns whenthey wrote the legacy
code. Hence, this work is a catalog ofpatterns for the masses. The
patterns presented here represent abundantsolutions that have endured
over time. Enjoy reading the patterns, butplease don't use them!
1 Cremational Patterns
Below is a list of five cremational patterns.
1.1 Abject Poverty
The Abject Poverty Pattern is evident insoftware that is so difficult
to test and maintain that doing so results inmassive budget overruns.
1.2 Blinder
The Blinder Pattern is an expedient solutionto a problem without
regard for future changes in requirements. Itis unclear as to whether
the Blinder is named for the blinders worn bythe software designer
during the coding phase, or the desire togouge his eyes out during
the maintenance phase.
1.3 Fallacy Method
The Fallacy method is evident in handlingcorner cases. The logic
looks correct, but if anyone actually bothersto test it, or if a
corner case occurs, the Fallacy of the logicwill become known.
1.4 ProtoTry
The ProtoTry Pattern is a quick and dirtyattempt to develop a working
model of software. The original intent is torewrite the ProtoTry,
using lessons learned, but schedules neverpermit. The ProtoTry is
also known as legacy code.
1.5 Simpleton
The Simpleton Pattern is an extremely complexpattern used for the
most trivial of tasks. The Simpleton is anaccurate indicator of the
skill level of its creator.
2 Destructural Patterns
Below is a list of seven destructuralpatterns.
2.1 Adopter
The Adopter Pattern provides a home fororphaned functions. The result
is a large family of functions that don'tlook anything alike, whose
only relation to one another is through theAdopter.
2.2 Brig
The Brig Pattern is a container class for badsoftware. Also known as
module.
2.3 Compromise
The Compromise Pattern is used to balance theforces of schedule vs.
quality. The result is software of inferiorquality that is still
late.
2.4 Detonator
The Detonator is extremely common, but oftenundetected. A common
example is the calculations based on a 2digit year field. This bomb
is out there, and waiting to explode!
2.5 Fromage
The Fromage Pattern is often full of holes.Fromage consists of cheesy
little software tricks that make portabilityimpossible. The older
this pattern gets, the riper it smells.
2.6 Flypaper
The Flypaper Pattern is written by onedesigner and maintained by
another. The designer maintaining theFlypaper Pattern finds herself
stuck, and will likely perish before gettingloose.
2.7 ePoxy
The ePoxy Pattern is evident in tightlycoupled software modules. As
coupling between modules increases, thereappears to be an epoxy bond
between them.
3 Misbehavioral Patterns
Below is a list of eleven misbehavioralpatterns.
3.1 Chain of Possibilities
The Chain of Possibilities Pattern is evidentin big, poorly
documented modules. Nobody is sure of thefull extent of its
functionality, but the possibilities seemendless. Also known as
Non-Deterministic.
3.2 Commando
The Commando Pattern is used to get in andout quick, and get the job
done. This pattern can break anyencapsulation to accomplish its
mission. It takes no prisoners.
3.3 Intersperser
The Intersperser Pattern scatters pieces offunctionality throughout a
system, making a function impossible to test,modify, or understand.
3.4 Instigator
The Instigator Pattern is seemingly benign,but wreaks havoc on other
parts of the software system.
3.5 Momentum
The Momentum Pattern grows exponentially,increasing size, memory
requirements, complexity, and processingtime.
3.6 Medicator
The Medicator Pattern is a real time hog thatmakes the rest of the
system appear to be medicated with strongsedatives.
3.7 Absolver
The Absolver Pattern is evident in problemridden code developed by
former employees. So many historical problemshave been traced to this
software that current employees can absolvetheir software of blame by
claiming that the absolver is responsible forany problem
reported. Also known as It's-not-in-my-code.
3.8 Stake
The Stake Pattern is evident in problemridden software written by
designers who have since chosen themanagement ladder. Although
fraught with problems, the manager's stake inthis software is too
high to allow anyone to rewrite it, as itrepresents the pinnacle of
the manager's technical achievement.
3.9 Eulogy
The Eulogy Pattern is eventually used on allprojects employing the
other 22 Resign Patterns. Also known as PostMortem.
3.10 Tempest Method
The Tempest Method is used in the last fewdays before software
delivery. The Tempest Method is characterizedby lack of comments, and
introduction of several Detonator Patterns.
3.11 Visitor From Hell
The Visitor From Hell Pattern is coincidentwith the absence of run
time bounds checking on arrays. Inevitably,at least one control loop
per system will have a Visitor From HellPattern that will overwrite
critical data.
4 References
Gamma, E., Helm, R., Johnson, R., Vlissides,J., Design Patterns -
Elements of Reusable Object-OrientedSoftware. Addison-Wesley, 1995.
-----
Michael Duell is an Engineer at AGCommunication Systems, where his
Resign Patterns have been rejected in favorof the Gang
of Four Design Patterns.
"Resign Patterns: Ailments of UnsuitableProject-Disoriented Software,"
The Software Practitioner, Vol. 7, No. 3,May-June 1997, p. 14.