http://blog.csdn.net/mfowler/category/223034.aspxzh-CNThu, 19 Oct 2006 19:18:00 GMT60mfowlerhttp://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspxThu, 19 Oct 2006 08:03:00 GMThttp://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspxhttp://blog.csdn.net/mfowler/comments/1340364.aspxhttp://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx#Feedback6http://blog.csdn.net/mfowler/comments/commentRss/1340364.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1340364所谓最小接口，其设计风格与人本接口形成鲜明对照，它背后的主旨是设计一套API不仅能满足用户完成所有操作的需求，还要把这种能力积聚到一个最精简的方法集合上。 如果你是在编写一个库，一旦发布，就很难再从中去掉什么东西了。因此，最好是先天不足，后天逐渐丰富，这样要强于先天营养过剩成了胖子，之后想减肥也减不下来。<img src ="http://blog.csdn.net/mfowler/aggbug/1340364.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/10/19/1340358.aspxThu, 19 Oct 2006 07:57:00 GMThttp://blog.csdn.net/mfowler/archive/2006/10/19/1340358.aspxhttp://blog.csdn.net/mfowler/comments/1340358.aspxhttp://blog.csdn.net/mfowler/archive/2006/10/19/1340358.aspx#Feedback3http://blog.csdn.net/mfowler/comments/commentRss/1340358.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1340358人本接口的本质思想是找出人们想要的操作并设计出接口，之后所有常见的操作都可以轻松搞定了。 以什么标准来判断一个方法该不该添到一个人本接口里呢？要是把所有人可能用得到的所有方法全都添上，最后会造出一个极其复杂的class。人本接口设计者的处理原则是努力甄别哪些方法是一个class最常用的，再加以设计以方便大家使用。<img src ="http://blog.csdn.net/mfowler/aggbug/1340358.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/09/11/1206800.aspxMon, 11 Sep 2006 10:22:00 GMThttp://blog.csdn.net/mfowler/archive/2006/09/11/1206800.aspxhttp://blog.csdn.net/mfowler/comments/1206800.aspxhttp://blog.csdn.net/mfowler/archive/2006/09/11/1206800.aspx#Feedback1http://blog.csdn.net/mfowler/comments/commentRss/1206800.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1206800如果diff有了语义，它就不单单知道改变的效果，还能理解做这个修改的目的了， 举个例子，想一下我用工具对一个class做了一个提炼函数（Extract Method）重构，两个版本之间只有这个修改。现在的diff工具只能看到代码文本变了，但它们不知道我刚才做的是一个重构，因此查看diff结果只能告诉我哪儿修改了，无法以某种方式凸显这是个提炼函数重构。如果真能知道我做了什么，merge功能也会更好用。<img src ="http://blog.csdn.net/mfowler/aggbug/1206800.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/08/28/1129414.aspxMon, 28 Aug 2006 00:25:00 GMThttp://blog.csdn.net/mfowler/archive/2006/08/28/1129414.aspxhttp://blog.csdn.net/mfowler/comments/1129414.aspxhttp://blog.csdn.net/mfowler/archive/2006/08/28/1129414.aspx#Feedback4http://blog.csdn.net/mfowler/comments/commentRss/1129414.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1129414连贯接口是操着一种内部DSL连贯地说事。这就是为什么我们拿“连贯”这个词来形容它。这样的API第一设计目标就是连贯性强、可读性强。 打造一套连贯API会培养出一些不同寻常的API设计习惯，最明显的一条就是setter有返回值。 Eric曾提到，目前他接触到的连贯接口都是用来装配Value Object的，Value Object没有具有业务领域意义的实体与之对应，它们可以被随心创建随心抛掉。因此，实际上连贯性依靠的是能够用老Value Object创建出新Value Object。<img src ="http://blog.csdn.net/mfowler/aggbug/1129414.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/08/26/1120724.aspxSat, 26 Aug 2006 00:30:00 GMThttp://blog.csdn.net/mfowler/archive/2006/08/26/1120724.aspxhttp://blog.csdn.net/mfowler/comments/1120724.aspxhttp://blog.csdn.net/mfowler/archive/2006/08/26/1120724.aspx#Feedback2http://blog.csdn.net/mfowler/comments/commentRss/1120724.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1120724Command与Query分离原则的实际价值在于，把修改状态的方法和不修改的明确地区分开将会带来巨大的便利：在许多情况下你可以非常有把握地使用Query，不必在意是什么地方，还可以调整多个Query的调用顺序，只需在用modifier时再小心谨慎。 我对分离原则的态度是可以遵守时就遵守，但类似pop那样的方法我不惮以违规来实现。<img src ="http://blog.csdn.net/mfowler/aggbug/1120724.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/08/24/1111781.aspxThu, 24 Aug 2006 12:12:00 GMThttp://blog.csdn.net/mfowler/archive/2006/08/24/1111781.aspxhttp://blog.csdn.net/mfowler/comments/1111781.aspxhttp://blog.csdn.net/mfowler/archive/2006/08/24/1111781.aspx#Feedback1http://blog.csdn.net/mfowler/comments/commentRss/1111781.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1111781若得到某个字段值的计算过程很耗时，你想推迟至真正用到它时再计算，这时适宜采用懒初始化。 人们说一个方法不修改一个object的可见状态，这是什么意思呢？这里的关键点并不是它们什么状态都不修改，而是不修改可见状态。一个object的可见状态是那些通过query方法可以得到的状态<img src ="http://blog.csdn.net/mfowler/aggbug/1111781.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/08/23/1108544.aspxWed, 23 Aug 2006 12:41:00 GMThttp://blog.csdn.net/mfowler/archive/2006/08/23/1108544.aspxhttp://blog.csdn.net/mfowler/comments/1108544.aspxhttp://blog.csdn.net/mfowler/archive/2006/08/23/1108544.aspx#Feedback1http://blog.csdn.net/mfowler/comments/commentRss/1108544.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1108544Eric Evans在他的杰作《领域驱动设计（Domain Driven Design）》中开创的一套针对Domain Objects的分类法，Entity通常是Customer、Ship、Rental Agreement（租赁协议）这类大物件；Value通常是Date、Money、Database Query这种小东西；而需要访问Database Connection、Messaging Gateway、Repository或Product Factory这类外部资源的一般属于Service。<img src ="http://blog.csdn.net/mfowler/aggbug/1108544.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/08/21/1102100.aspxMon, 21 Aug 2006 11:47:00 GMThttp://blog.csdn.net/mfowler/archive/2006/08/21/1102100.aspxhttp://blog.csdn.net/mfowler/comments/1102100.aspxhttp://blog.csdn.net/mfowler/archive/2006/08/21/1102100.aspx#Feedback0http://blog.csdn.net/mfowler/comments/commentRss/1102100.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1102100界定一种语言是不是DSL关键是看它在范围和能力这两方面是不是受限，DSL都有自己专门适用的领域，并且缺乏通用目的语言的某些基本特性。 先说内部DSL，和API之间的界线很模糊，两者没有本质区别，一种内部DSL其实就是一套有个漂亮名字的API（正如老贝尔实验室流传的一句名言："库设计就是语言设计"）。再说外部DSL，问题就成了它与GPL有哪些不同。一般而言，DSL无图灵完备性，且缺乏抽象机制，这是它区别于GPL的最明显的特征。 一门语言如果图灵完备还可以划为DSL吗？界定的关键在于目的——既包括语言设计者的目的，也包括语言使用者的目的。<img src ="http://blog.csdn.net/mfowler/aggbug/1102100.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/08/16/1069927.aspxWed, 16 Aug 2006 12:50:00 GMThttp://blog.csdn.net/mfowler/archive/2006/08/16/1069927.aspxhttp://blog.csdn.net/mfowler/comments/1069927.aspxhttp://blog.csdn.net/mfowler/archive/2006/08/16/1069927.aspx#Feedback2http://blog.csdn.net/mfowler/comments/commentRss/1069927.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1069927所谓领域专用语言（domain specific language / DSL），其基本思想是“求专不求全”，不像通用目的语言那样目标范围涵盖一切软件问题，而是专门针对某一特定问题的计算机语言。 先定义语法，然后通过代码生成技术把DSL代码转成一种通用语言代码，或者写一个这种DSL的解释器。我为这类DSL定了一个术语：“外部DSL”。利用编程语言自带的语法结构定义出来的DSL，我称之为“内部DSL”，也叫做“内嵌DSL”。 我喜欢用Smalltalk和Ruby的程度比喜欢用Java或C#的程度高那么多，更接近两者区别本质的是它们对构建内部DSL友好程度的差异。 <img src ="http://blog.csdn.net/mfowler/aggbug/1069927.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/08/11/1051401.aspxFri, 11 Aug 2006 17:30:00 GMThttp://blog.csdn.net/mfowler/archive/2006/08/11/1051401.aspxhttp://blog.csdn.net/mfowler/comments/1051401.aspxhttp://blog.csdn.net/mfowler/archive/2006/08/11/1051401.aspx#Feedback2http://blog.csdn.net/mfowler/comments/commentRss/1051401.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1051401一种由James Noble和Robert Biddle两人提出的编程思想。其精髓（仅代表个人理解）如下：长久以来，软件开发的现代派观点认为，优秀的软件系统以统一而简单的方式由统一的组件构成（Smalltalk和Lisp就是这种思想的好例子）；而后现代主义观认为，软件是由各种各样风格迥异的东西用五花八门的方法粘合而成的（联想一下 Perl和Unix），这是种不错的软件风格（像个由各种胶着物粘成的大桶）。<img src ="http://blog.csdn.net/mfowler/aggbug/1051401.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/08/09/1039878.aspxWed, 09 Aug 2006 03:45:00 GMThttp://blog.csdn.net/mfowler/archive/2006/08/09/1039878.aspxhttp://blog.csdn.net/mfowler/comments/1039878.aspxhttp://blog.csdn.net/mfowler/archive/2006/08/09/1039878.aspx#Feedback2http://blog.csdn.net/mfowler/comments/commentRss/1039878.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1039878我用“应用式数据库”这个术语来描述一个由单一应用系统控制和访问的数据库，与之对应的概念是“集成式数据库”。因为只有一个应用访问这个数据库，所以可以量体裁衣，数据库设计越能方便地满足应用的需求也就越“合身”，这使得表结构非常具体化，通常比集成式数据库的设计更简单，更容易理解。 为多个应用存储数据的数据库叫做“集成式数据库”，它把多个应用的数据集成整合在一个库中（与应用式数据库形成对比）。 设计一个集成式数据库的表结构，要通盘考虑所有客户应用系统的需求，因此导致表结构很通用（欠缺针对性），或非常复杂，抑或即通用又复杂。数据库设计团队与应用开发团队通常是分开的，这使数据库设计修改起来非常麻烦，因为提出修改的一方不得不与数据库设计团队还有其他应用开发团队协商。<img src ="http://blog.csdn.net/mfowler/aggbug/1039878.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/08/07/1034635.aspxMon, 07 Aug 2006 22:15:00 GMThttp://blog.csdn.net/mfowler/archive/2006/08/07/1034635.aspxhttp://blog.csdn.net/mfowler/comments/1034635.aspxhttp://blog.csdn.net/mfowler/archive/2006/08/07/1034635.aspx#Feedback1http://blog.csdn.net/mfowler/comments/commentRss/1034635.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1034635有一些厉害的用户偏偏喜欢直接用基于SQL的报表工具。这种情况的一个好对策就是生成一个“报表数据库”。所谓报表数据库，是存储实际操作数据的数据库外的另一个数据库，基于领域模型编写代码给它填充数据，因此从领域模型衍生出的数据也能填进去。 虽然我是通过一个领域模型的例子引出报表数据库的，但这种方法适用于任何需要封装数据库的情况，许多人认为这类情况是面向服务构架（SOA）的目的之一。<img src ="http://blog.csdn.net/mfowler/aggbug/1034635.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/07/29/997103.aspxSat, 29 Jul 2006 09:54:00 GMThttp://blog.csdn.net/mfowler/archive/2006/07/29/997103.aspxhttp://blog.csdn.net/mfowler/comments/997103.aspxhttp://blog.csdn.net/mfowler/archive/2006/07/29/997103.aspx#Feedback3http://blog.csdn.net/mfowler/comments/commentRss/997103.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=997103许多关于软件开发的论战都是以参战者是持督导态度还是持授权态度为背景根基展开的。这两种不同的态度至关重要，影响到对语言、设计、工具、过程等诸多方面的选择。<img src ="http://blog.csdn.net/mfowler/aggbug/997103.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/07/25/974204.aspxTue, 25 Jul 2006 11:31:00 GMThttp://blog.csdn.net/mfowler/archive/2006/07/25/974204.aspxhttp://blog.csdn.net/mfowler/comments/974204.aspxhttp://blog.csdn.net/mfowler/archive/2006/07/25/974204.aspx#Feedback1http://blog.csdn.net/mfowler/comments/commentRss/974204.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=974204我是在《重构》里第一次使用“发布接口（Published Interface）”这个术语的，如果一个class接口在定义它的代码库（code base）以外也被用到了，那它就成了一个发布接口。它比Java的public公开的意味更足，也远甚于C#的非内部public（non- internal public）。我曾撰文论说过发布（published）与公有（public）之间的区别比public与private的区别更重要。 其原因在于，一个非发布接口，对它的使用限制在了唯一一个代码库里边，因此，你可以修改它——只要在调用它的地方也做好相应的修改。例如改改名字什么的，现代化的重构工具能帮你轻松搞定。然而，一个接口一旦发布出去，你就鞭长莫及了，你没办法修改外界调用它的代码。<img src ="http://blog.csdn.net/mfowler/aggbug/974204.aspx" width = "1" height = "1" />mfowlerhttp://blog.csdn.net/mfowler/archive/2006/07/23/965022.aspxSun, 23 Jul 2006 17:53:00 GMThttp://blog.csdn.net/mfowler/archive/2006/07/23/965022.aspxhttp://blog.csdn.net/mfowler/comments/965022.aspxhttp://blog.csdn.net/mfowler/archive/2006/07/23/965022.aspx#Feedback3http://blog.csdn.net/mfowler/comments/commentRss/965022.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=965022运行时完全在内存里无需访问硬盘的数据库叫做“内存数据库”。内存数据库常作为嵌入式数据库：当一个进程启动时被创建，嵌入到这个进程中运行，当进程终止时被销毁。 尽管大家一般都认为数据库应该是个以硬盘为中心的庞大部件，实际上还存在一个狭小而热闹的内存数据库世界。有些应用系统要求数据访问速度要快，这些数据被管理但无需被持久化，因为它们不会改变，或者因为这些数据可被重新生成（联想一下路由器的路由表，还有事件张贴板）。 <img src ="http://blog.csdn.net/mfowler/aggbug/965022.aspx" width = "1" height = "1" />