“另类” 设计模式

标签: 技术读物 杂项资源 轶事趣闻 design pattern Pattern | 发表时间:2011-06-16 08:46 | 作者:陈皓 Sean Lee
出处:http://coolshell.cn

下面这篇文章来自这里: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
作者Michael Duell

概要

任何一个熟悉那本由四个人写的经典的设计模式书的朋友,应该知道那本书里的模式都是非常优雅和划时代的。然而,不幸的是,从那些老代码中无法提练出这些模式,因为,在出现这些模式前,大家都不会使用模式。因此,这项工作是从大量的代码中提练出一个模式的目录。这些模式都有充足和永恒的示例。希望你能享受阅读这些模式,但千万不要模仿并使用他们!

1. Cremational Patterns 火葬模式 | Creational patterns 创建模式

下面是五个 cremational 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 模式,因为这样可以造成重要数据的重写。

参考

  • [1] Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
  • [2] Michael Duell is an Engineer at AG Communication Systems, where his Resign Patterns have been rejected in favor of the Gang of Four Design Patterns.
  • [3] “Resign Patterns: Ailments of Unsuitable Project-Disoriented Software,” The Software Practitioner, Vol. 7, No. 3, May-June 1997, p. 14.

(全文完)

相关文章

相关 [设计模式] 推荐:

Scala设计模式

- - ITeye博客
       我的话: 在国外网站上看到一篇文章,里面详细描述了很多设计模式,并且用Java及Scala两种语言描述,清晰的让我们看到各种常规的设计模式,在Scala中是如何在语言特性层面直接支持的. 基于文章很nice,我利用今天的空闲时间将其翻译,希望大家能一起学习,讨论. 翻译比较倡促,也就两小时左右,有何不当,请在下面留言指出.

Spring设计模式

- - 行业应用 - ITeye博客
springMVC通常采用属性注入的IOC方式和AOP织入方式相结合实现依赖注入 同时使用强制代理方式,代理类或者接口. 这里又涉及到单例模式(注入的类或者接口在容器中只存在一个)、工厂模式(通过反射实现类实例化过程的公用化)、楼上所说的装饰模式属于AOP织入的一部分. 想了解spring先从IOC和AOP开始吧.

“另类” 设计模式

- Sean Lee - 酷壳 - CoolShell.cn
下面这篇文章来自这里:http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns,这篇文章有点意思了,山寨了我们著名的Design Pattern. 这篇文章并不是很容易翻译,也许我翻译的不好,大家多指正. 另外,这篇文章将失去原有的趣味在于其使用了经典设计模式的单词很相似的单词,一走眼你还以为是正二八经的设计模式.

【译】屏幕设计模式

- 志强 - 所有文章 - UCD大社区
模式是广泛适用的解决一般问题的解决方案. 在开发应用程序过程中,无论是面对抽象还是实际问题,模式都大有用处. 而标准屏幕模式对于优秀的Web程序甚至企业级软件都很有帮助. 摘要/细节(Master/Detail). 摘要/细节模式可横向也可竖向. 该模式是满足用户既停留在一个页面又可浏览多个条目需求的典范.

设计模式之代理模式(Proxy)

- - 博客园_首页
这段时间一直忙于期末考试,好久没来博客园了,现在好了,终于考完了,也该过上正常的日子了. 开学就是大四的学生了,时间过的可是真快啊,转眼间大学四年已经接近尾声了. 回想大学这三年,成绩还可以吧(年级前10%),参加过各种竞赛(acm,数学建模等等),学生会也呆过(打了一年的酱油),好哥们也有那么五六个(希望以后能在一个城市发展,大学期间的宝贵财富啊),另外所谓的大学生创新实践项目也搞了一个(就算开阔一下视野吧,大学能生有什么创新呢.

设计模式原则总结

- - IT技术博客大学习
0、单一职责原则(SRP) 就一个类而言,应该仅有一个引起它变化的原因. 一、”开放-封闭”原则(OCP) 在软件设计模式中,这种不能修改,但可以扩展的思想也是最重要的一种设计原则. 即软件实体(类、模板、函数等等)应该可以扩展,但是不可修改. 【通俗】:设计的时候,时刻考虑,尽量让这个类是足够好,写好了就不要去修改了,如果新需求来,我们增加一些类就完事了,原来的代码能不动则不动.

Web应用的缓存设计模式

- - robbin的自言自语
从10年前的2003年开始,在Web应用领域,ORM(对象-关系映射)框架就开始逐渐普及,并且流行开来,其中最广为人知的就是Java的开源ORM框架Hibernate,后来Hibernate也成为了EJB3的实现框架;2005年以后,ORM开始普及到其他编程语言领域,其中最有名气的是Ruby on rails框架的ORM - ActiveRecord.

设计模式和设计原则

- - 编程 - 编程语言 - ITeye博客
26.1  设计模式和设计原则. 26.1.1  设计模式和设计原则的关系. 面向对象的分析设计有很多原则,这些原则大都从思想层面,给我们指出了面向对象分析设计的正确方向,是我们进行面向对象分析设计应该尽力遵守的准则.        而设计模式已经是针对某个场景下某些问题的某个解决方案. 也就是说这些设计原则是思想上的指导,而设计模式是实现上的手段,因此设计模式也是应该遵守这些原则的,换句话说,设计模式就是这些设计原则的一些具体体现.

面向对象设计模式的核心法则

- tonytech - Michael`s blog
有本经典的书叫《设计模式》,讲了经典的21种设计模式,建议大家都看看. 就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力. 这种耦合会导致脆弱的设计,当变化发生时,设计会遭到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把那些职责互相分离.

如何向妻子解释设计模式

- brett80 - 博客园-首页原创精华区
  自上篇翻译<如何向妻子解释OOD>后收到了很好的反应. 故特继续翻译作者的一文,以飨读者. 在此文中,作者依旧通过与妻子浅显易懂的对话,向读者解释了什么是设计模式. Shubho:通过我们关于面向对象设计原则(OODP,即SOLID原则)的对话,我想你已经对面向对象设计原则(OODP)有了基本的认识.