IT牛人博客聚合

之前，@风枫峰 在“这是谁的错？”中说过开发团队对需求来者不拒，而@weidagang 也在“需求变更和IoC”中说过用IoC来最大程度地解决需求变更。今天我也想从Unix设计思想的角度来说说什么是好的软件设计，什么样的设计可以把需求变更对开发的影响降低。（注意：这并不能解决用户或是PM的无理需求，面对无理需求，需要仔细分析需求，而用技术的手段无法搞定这个事，但是可以减轻需求变更带来的痛苦） 我曾经在《Unix传奇》的下篇中写过一些Unix的设计哲学和思想（这里重点推荐大家看一下《The Art of Unix Programming》，我推荐过多次了），以前也发过一篇《一些软件设计的原则》，不过，这些东西都太多了，记不住。其实，这

查看全文: http://www.udpwork.com/item/7273.html

【感谢 Todd投递本文 – 微博帐号：@weidagang 】

需求又变了，怎么办？

先上一个轻松的段子：

程序员XX遭遇车祸成植物人，医生说活下来的希望只有万分之一，唤醒更为渺茫。可他的Lead和亲人没有放弃，他们根据XX工作如命的作风，每天都在他身边念：“XX，需求又改了，该干活了，你快来呀！”，奇迹终于发生了，XX醒来了，第一句话：“需求又改了？”。

这个段子用幽默的方式反映了需求变化是每一个程序员、架构师或项目经理都会经常遇到的问题。面对这个问题，不同的人有不同的应对之道，最近微博上有一段关于需求变化的讨论：

@假装刺猬的猪：我们在软件开发过程中，会持续碰到客户需求变更的情况。如果没有领域建模，我们单纯将问题使用

查看全文: http://www.udpwork.com/item/7041.html

所谓装饰器，英文称之为Decorator，亦或者Wrapper。如果让我选择最喜爱的模式，我想我会毫不犹豫的投它一票。那到底什么是装饰器呢？且听我慢慢道来。

热身问题：顾客来买车，车本身有一个价格，如果要加内饰、镀膜、导航等配件，就需要另加钱。等到结帐的时候，程序应该如何处理呢？最直接的方法就是创建车类，和内饰、镀膜、导航等配件类，然后根据顾客的购买情况遍历获取最终价格。这样做最大的问题是对象的概念被割裂了，计算价格的操作变得过程化。当然我们可以通过创建子类来解决这类问题，比如根据不同的配件组合创建不同的车子类，如：内饰车类，镀膜车类，导航车类，但这还不算完，还有内饰镀膜车类，内饰导航车类等等。如果新加一个配件，还会衍生出若干个新

查看全文: http://www.udpwork.com/item/6933.html

下面是我这段时间来收集的一些有意思的东西。本站这样的文章还很多，如这个，这个，这个。

Javascript Garden，这是学习Javascript最好的网站了。http://bonsaiden.github.com/JavaScript-Garden，这个文档由两具StackOverflow的人写成, Ivo Wetzel(Writing) 和 Zhang Yi Jiang (Design)，表示敬意。

想看看Web开发有哪些技术吗？你得看看这个网站：http://stackparts.com/，他对目前几乎所有Web上用得到的技术都分了个类。下面是个抓图。

Mozilla的安全编程规范 https://wiki.mozi

查看全文: http://www.udpwork.com/item/6372.html

下面这篇文章来自这里：http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns，这篇文章有点意思了，山寨了我们著名的Design Pattern。这篇文章并不是很容易翻译，也许我翻译的不好，大家多指正。另外，这篇文章将失去原有的趣味在于其使用了经典设计模式的单词很相似的单词，一走眼你还以为是正二八经的设计模式。呵呵。所以，我在下文中，我会保留原有的英文单词，并把真正的23个经典设计模式的英文名放在旁边（灰色）。这篇文章和之前的如何写出无法维护的代码有异曲同工，个人感觉都是比较欢乐的。

 

辞职模式

Resign Patterns

Design Patt

查看全文: http://www.udpwork.com/item/5283.html

下面是JDK中有关23个经典设计模式的示例，在stakeoverflow也有相应的讨论：

http://stackoverflow.com/questions/1673841/examples-of-gof-design-patterns

Structural（结构模式）

Adapter:

把一个接口或是类变成另外一种。

java.util.Arrays#asList()

javax.swing.JTable(TableModel)

java.io.InputStreamReader(InputStream)

java.io.OutputStreamWriter(OutputStream)

javax.xml.bi

查看全文: http://www.udpwork.com/item/3583.html

在上一篇文章里，我们完成了 Dispatcher 类的接口设计，现在我们就来考虑一下如何实现这个类。

Notify & Capture

要实现 notify 和 capture 就太容易了，我们只需要把 capture 传入的 handler 都保存下来，然后在 notify 里面找到匹配的 handler 就可以了。

var filterHandlerBundles = [];

Dispatch.capture = function(pattern, handler) {
  var filter = createFilter(pattern);
  filterHandlerBundles.push(

查看全文: http://www.udpwork.com/item/2103.html

在《从 if else 到 switch case 再到抽象》这篇文章里面说到，解决 if else 和 switch case 分支过多的一个方法，就是做一个专用的 dispatcher ，让它来负责进行筛选与转发。至于筛选条件的描述，模式匹配是一种很常见也很好用的方式。在 JavaScript 里面，用 JSON 来描述模式又是相当方便的事情，所以我们来做一个 JSON 模式匹配工具吧。

用例设计

作为一个 dispatcher ，我们只需要两个方法： notify 和 capture 。一个最简单的用例是这样的：

Dispatcher.capture({
  "status": 200,
  "com

查看全文: http://www.udpwork.com/item/2104.html

During the search about Python singleton pattern, I discovered [ActiveState recipe 66531].

In this Borg Pattern, instances’ internal dictionary points to the same place, so all instances share the same state. Also, [Alex Martelli], the author of this recipe, has a interesting comment: Borg Pattern != Singleton

查看全文: http://www.udpwork.com/item/1099.html

There are three ways to get this job done.

1 Module Implementation

The easiest implementation is to use a module scope variable. Module is persistent and shared by all references through its life time, no matter how it is renamed or modified.

See this [stackoverflow post on Python singleton]. Xen Xend makes use of

查看全文: http://www.udpwork.com/item/1100.html