<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>Martin Fowler's Bliki 中文版</title><link>http://blog.csdn.net/mfowler/</link><description>记录Martin Fowler关于软件开发想法片断的blog与wiki的交叉体</description><dc:language>zh-CN</dc:language><lastUpdateTime>Thu, 19 Oct 2006 19:18:00 GMT</lastUpdateTime><ttl>60</ttl><item><dc:creator>mfowler</dc:creator><title>最小接口</title><link>http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx</link><pubDate>Thu, 19 Oct 2006 08:03:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1340364.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx#Feedback</comments><slash:comments>6</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1340364.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1340364</trackback:ping><description>所谓最小接口，其设计风格与人本接口形成鲜明对照，它背后的主旨是设计一套API不仅能满足用户完成所有操作的需求，还要把这种能力积聚到一个最精简的方法集合上。

如果你是在编写一个库，一旦发布，就很难再从中去掉什么东西了。因此，最好是先天不足，后天逐渐丰富，这样要强于先天营养过剩成了胖子，之后想减肥也减不下来。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1340364.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>人本接口</title><link>http://blog.csdn.net/mfowler/archive/2006/10/19/1340358.aspx</link><pubDate>Thu, 19 Oct 2006 07:57:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/10/19/1340358.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1340358.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/10/19/1340358.aspx#Feedback</comments><slash:comments>3</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1340358.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1340358</trackback:ping><description>人本接口的本质思想是找出人们想要的操作并设计出接口，之后所有常见的操作都可以轻松搞定了。

以什么标准来判断一个方法该不该添到一个人本接口里呢？要是把所有人可能用得到的所有方法全都添上，最后会造出一个极其复杂的class。人本接口设计者的处理原则是努力甄别哪些方法是一个class最常用的，再加以设计以方便大家使用。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1340358.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>RubyPloticus</title><link>http://blog.csdn.net/mfowler/archive/2006/09/20/1254537.aspx</link><pubDate>Wed, 20 Sep 2006 18:12:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/09/20/1254537.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1254537.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/09/20/1254537.aspx#Feedback</comments><slash:comments>2</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1254537.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1254537</trackback:ping><description>在最近的帖子“评估Ruby”中，我提到一位同事曾在一个Web应用中加入了一些漂亮的数据图表，有人email问我是怎样实现的，我在原来那篇帖子上添了句简短的回答：用Ploticus。这就带来另一个问题——他是怎样把Ruby和Ploticus连起来的呢？

最近我自己也遇到个类似的问题，要用Ploticus把一个个人项目的一些数据图表化。我的解决办法虽然远不如那位同事的那么精致，但实际上很相似。于是我觉得应该和大家分享一下。

这个例子非常简单，但它很好地展示了一个模式——我称之为Gateway模式。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1254537.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>让版本管理遍地开花</title><link>http://blog.csdn.net/mfowler/archive/2006/09/14/1222046.aspx</link><pubDate>Thu, 14 Sep 2006 12:33:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/09/14/1222046.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1222046.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/09/14/1222046.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1222046.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1222046</trackback:ping><description>最近Apple发布了Time Machine，能让时光倒流来查看你的文件的所有修改，包括找回已删除的文件。

Time Machine被视为一个自动备份系统，因此它不支持版本管理系统里“提交”这种意义明确的概念。我觉得这是最好的发展方向，至少以此作为发展起点是最好的，这样利于人们习惯这种系统的思想。

我觉得更重要的一步在于把具备这种能力的范围拓展得更广，这样能给应用开发者们一个促动。我在“更广泛的版本管理”中说支持diff和merge的应用软件数量还不够。可能Time Machine能促使人们开始考虑在应用中加入这种能力，这会让版本管理更方便好用。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1222046.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>多台桌面电脑</title><link>http://blog.csdn.net/mfowler/archive/2006/09/12/1214386.aspx</link><pubDate>Tue, 12 Sep 2006 20:22:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/09/12/1214386.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1214386.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/09/12/1214386.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1214386.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1214386</trackback:ping><description>我经常转战于三台机器：Mac PowerBook、Windows笔记本、Ubuntu桌面。

我大部分工作文件都被Subversion管理起来了，每当切换机器时我就提交（commit）工作目录，再到新机器上更新（update）。一切都同步得好好的，还全面享受了版本管理服务。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1214386.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>更广泛的版本管理</title><link>http://blog.csdn.net/mfowler/archive/2006/09/11/1206875.aspx</link><pubDate>Mon, 11 Sep 2006 10:33:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/09/11/1206875.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1206875.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/09/11/1206875.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1206875.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1206875</trackback:ping><description>作为版本管理工具的重度用户，我觉得版本管理可以拓展到计算机的更多应用领域。目前除了软件开发者，很少其他计算机用户会用版本管理，但软件开发者们都知道它对协同工作的意义实在太重大了——因为它允许多个人一起工作于同一软件系统上。如果把版本管理的应用范围拓展到更广会带来什么好处呢？

既然所有人都可以轻松获得并使用Subversion，那么让常规的应用软件向这个方向发展或许正是开源社区的一个契机。由此浮现出来的一些好点子会真正提高协同工作水平。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1206875.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>语义diff</title><link>http://blog.csdn.net/mfowler/archive/2006/09/11/1206800.aspx</link><pubDate>Mon, 11 Sep 2006 10:22:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/09/11/1206800.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1206800.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/09/11/1206800.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1206800.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1206800</trackback:ping><description>如果diff有了语义，它就不单单知道改变的效果，还能理解做这个修改的目的了，

举个例子，想一下我用工具对一个class做了一个提炼函数（Extract Method）重构，两个版本之间只有这个修改。现在的diff工具只能看到代码文本变了，但它们不知道我刚才做的是一个重构，因此查看diff结果只能告诉我哪儿修改了，无法以某种方式凸显这是个提炼函数重构。如果真能知道我做了什么，merge功能也会更好用。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1206800.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>即席演讲</title><link>http://blog.csdn.net/mfowler/archive/2006/09/07/1188620.aspx</link><pubDate>Thu, 07 Sep 2006 09:38:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/09/07/1188620.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1188620.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/09/07/1188620.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1188620.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1188620</trackback:ping><description>不久前Jon Udell把公开演讲根据其特点划分为按稿讲和按幻灯片讲两类，我多数的公开演讲是另外一类——即席演讲。即席演讲准备工作很少，比一个粗略提纲多不了什么，其余所有内容随讲随想。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1188620.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>翻译</title><link>http://blog.csdn.net/mfowler/archive/2006/09/04/1174830.aspx</link><pubDate>Mon, 04 Sep 2006 06:52:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/09/04/1174830.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1174830.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/09/04/1174830.aspx#Feedback</comments><slash:comments>8</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1174830.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1174830</trackback:ping><description>不仅有人愿意把自己宝贵的工作时间浪费在阅读这个博客上，而且还有人愿意翻译它。我很欢迎一份中文翻译版加入，现在正在由马皓明做这件事。我被告知自己拥有广大的中国读者，我很欢迎他们来这里看我这些不甚成熟的想法。

在页面边侧，可以找到多种语言翻译版本的永久链接。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1174830.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>评估Ruby</title><link>http://blog.csdn.net/mfowler/archive/2006/09/02/1161118.aspx</link><pubDate>Sat, 02 Sep 2006 16:11:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/09/02/1161118.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1161118.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/09/02/1161118.aspx#Feedback</comments><slash:comments>20</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1161118.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1161118</trackback:ping><description>我自己喜欢用Ruby，我们的客户就也应该用吗——两件事距离甚远。但我们可以根据其特性评估它是否适合用来做客户的项目，这就引起对后边一堆东西好坏利弊的争论：动态类型、惯例重于配置（convention over configuration）、进程 VS 线程，等等。这些讨论有帮助，但我对此持审慎态度，因为只凭空争论无法判断的事情太多了——有些东西在高尔夫球课上听起来头头是道，但它们致使客户项目进展变慢让我们多投入的时间难道还少吗？所以，我做判断倾向于依据现实经验——要找到人们在主流环境下交付项目的跟踪记录，还有使用Ruby开发的记录。

我已经可以根据好几个项目的经验做分析了，到目前为之，分析结果力挺Ruby。每次我问他们：“你觉得用Ruby 比用Java或C#生产力有显著提高吗？”我听到的无一例外都是一句有力的肯定：“是的！”

了解了来自我们值得信赖的同事们的切身经验，我对在注重速度、响应性以及生产力的严肃工作中使用Ruby持越来越肯定的态度。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1161118.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>以例为规</title><link>http://blog.csdn.net/mfowler/archive/2006/08/30/1144166.aspx</link><pubDate>Wed, 30 Aug 2006 14:23:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/08/30/1144166.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1144166.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/08/30/1144166.aspx#Feedback</comments><slash:comments>4</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1144166.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1144166</trackback:ping><description>在做需求分析时单靠范例规格这一种技术是不够的，但这并非说“以例为规”不能用作捕获需求的首要手段。

既然已明确单以范例做规格还不够，显然就需要做更多工作，通过彻底的沟通交互，确保敲定需求中的每一件事。而以传统的需求分析技术，人们总是想当然地以为把东西写出来了，交互过程也就完成了 ——这真是一个致命缺点。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1144166.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>连贯接口</title><link>http://blog.csdn.net/mfowler/archive/2006/08/28/1129414.aspx</link><pubDate>Mon, 28 Aug 2006 00:25:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/08/28/1129414.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1129414.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/08/28/1129414.aspx#Feedback</comments><slash:comments>4</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1129414.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1129414</trackback:ping><description>连贯接口是操着一种内部DSL连贯地说事。这就是为什么我们拿“连贯”这个词来形容它。这样的API第一设计目标就是连贯性强、可读性强。

打造一套连贯API会培养出一些不同寻常的API设计习惯，最明显的一条就是setter有返回值。

Eric曾提到，目前他接触到的连贯接口都是用来装配Value Object的，Value Object没有具有业务领域意义的实体与之对应，它们可以被随心创建随心抛掉。因此，实际上连贯性依靠的是能够用老Value Object创建出新Value Object。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1129414.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>Command与Query分离</title><link>http://blog.csdn.net/mfowler/archive/2006/08/26/1120724.aspx</link><pubDate>Sat, 26 Aug 2006 00:30:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/08/26/1120724.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1120724.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/08/26/1120724.aspx#Feedback</comments><slash:comments>2</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1120724.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1120724</trackback:ping><description>Command与Query分离原则的实际价值在于，把修改状态的方法和不修改的明确地区分开将会带来巨大的便利：在许多情况下你可以非常有把握地使用Query，不必在意是什么地方，还可以调整多个Query的调用顺序，只需在用modifier时再小心谨慎。

我对分离原则的态度是可以遵守时就遵守，但类似pop那样的方法我不惮以违规来实现。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1120724.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>懒初始化 与 可见状态</title><link>http://blog.csdn.net/mfowler/archive/2006/08/24/1111781.aspx</link><pubDate>Thu, 24 Aug 2006 12:12:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/08/24/1111781.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1111781.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/08/24/1111781.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1111781.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1111781</trackback:ping><description>若得到某个字段值的计算过程很耗时，你想推迟至真正用到它时再计算，这时适宜采用懒初始化。

人们说一个方法不修改一个object的可见状态，这是什么意思呢？这里的关键点并不是它们什么状态都不修改，而是不修改可见状态。一个object的可见状态是那些通过query方法可以得到的状态&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1111781.aspx" width = "1" height = "1" /&gt;</description></item><item><dc:creator>mfowler</dc:creator><title>Evans氏分类法</title><link>http://blog.csdn.net/mfowler/archive/2006/08/23/1108544.aspx</link><pubDate>Wed, 23 Aug 2006 12:41:00 GMT</pubDate><guid>http://blog.csdn.net/mfowler/archive/2006/08/23/1108544.aspx</guid><wfw:comment>http://blog.csdn.net/mfowler/comments/1108544.aspx</wfw:comment><comments>http://blog.csdn.net/mfowler/archive/2006/08/23/1108544.aspx#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://blog.csdn.net/mfowler/comments/commentRss/1108544.aspx</wfw:commentRss><trackback:ping>http://tb.blog.csdn.net/TrackBack.aspx?PostId=1108544</trackback:ping><description>Eric Evans在他的杰作《领域驱动设计（Domain Driven Design）》中开创的一套针对Domain Objects的分类法，Entity通常是Customer、Ship、Rental Agreement（租赁协议）这类大物件；Value通常是Date、Money、Database Query这种小东西；而需要访问Database Connection、Messaging Gateway、Repository或Product Factory这类外部资源的一般属于Service。&lt;img src ="http://blog.csdn.net/mfowler/aggbug/1108544.aspx" width = "1" height = "1" /&gt;</description></item></channel></rss>