另类看设计模式[来自酷壳网]

下面这篇文章来自这里：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

                   [e-mail]

 

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.