`
庄表伟
  • 浏览: 1150423 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

Martin Fowler最近的两篇Blog,推荐阅读

阅读更多
《人本接口》与《最小接口》
http://blog.csdn.net/mfowler/archive/2006/10/19/1340358.aspx

http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx

一个类的接口如何设计?这个问题很值得探讨。

我在设计DJ的时候,也考虑过这个问题,按照Channel的思想,简单的Channel可以组合起来,成为复杂的Channel,这样既能够满足最小接口的精简原则,又能够满足人本接口的方便原则。

欢迎大家讨论
分享到:
评论
10 楼 ozzzzzz 2006-10-26  
charon 写道
网上有个评论很经典,老马不应该拿一个具体类和一个接口去比较。
要比较,就去和LinkedList比,这个实现了6/7个接口,实现的方法数目不比ruby的那个少,所谓的first/last也都有。
学了ruby之后,看java代码的时候不带有色眼镜,也把ducking type的那一套套到java代码上去,比如一个LinkedList就提供了一个隐含的ILinkedList接口,那就一切ok乐。
记得有个C#大佬死命的推荐具体类,建议除非特殊情况,只要能够用具体类的地方,都不要搞出一个接口来. 其实也非常贴合ducking type的思想精髓,在java/C#中,interface实际上是显式的接口,看着不顺眼就不用,直接使用依着于具体类的隐式接口吧。好处是,显式接口一旦发布,修改是很忌讳的,而具体类的公共方法就没有这个心理负担,虽然实质上是一回事情。
不过这些都是TDD/测试先行带来的间接效果,没有这个前提,别的都是白扯.

切中要害。我觉得老马是忽略了接口也有语义这个背景,所以才自己忽悠了自己。
9 楼 intolong 2006-10-26  
感觉是两个角度看问题:人本接口倾向于client (Assembler),最小接口倾向于supplier (Implementation)。

Martin Fowler倾向于人本接口,个人倾向于最小接口。

人本接口容易把类搞成巨大,最精华的算法反而容易被忽视掉,trouble shooting也就更难。而且人本接口违反了OO的基本原则OCP。

其实可以这样做:搞两个接口,一个是给client用的,搞成人本接口,内部实际操作dispatch到另一个给supplier用的最小接口上。这样supplier可以把自己的最小接口完全搞成一个内部实现接口,对用户来说是透明的。而client接口负责组装那些功能逻辑。这样指责更分明,不会造成接口污染。
8 楼 runes 2006-10-23  
femto 写道
老马是在犯迷糊,java中,有些东西不直接在自己的类实现,无非是
把负担转嫁到另外的地方去,比如放到Collections,难道就不是放了?
还有象oscore的项目,我们在项目中写代码,也常常有重复一些小功能,虽然这些小功能只需要几行代码就能搞定,但是每次在很多地方
重复这几行也不好。所以象判空isEmpty(String str) ==>
if(str == null || str.trim.equals("") ) {
  return true;
}
isEmpty(Collection c) ==>
if(c == null || c.size == 0) {
  return true;
}
这样的一些封装就很有必要。


哈,碰到一个同好阿,不过我是在cpp中。
7 楼 ddd 2006-10-22  
从艺术上讲自然是最小接口。
从实际上讲就说不清了,似乎得从为什么要用接口出发了。

倾向于人本,并且认为接口的不变性有点过于理想化,当认为某个接口项不用再维护的话,砍掉它!接口的意义应该是比较长的一段时间不变,而不是终生不变。

唯一不变的就是变化。
6 楼 femto 2006-10-22  
老马是在犯迷糊,java中,有些东西不直接在自己的类实现,无非是
把负担转嫁到另外的地方去,比如放到Collections,难道就不是放了?
还有象oscore的项目,我们在项目中写代码,也常常有重复一些小功能,虽然这些小功能只需要几行代码就能搞定,但是每次在很多地方
重复这几行也不好。所以象判空isEmpty(String str) ==>
if(str == null || str.trim.equals("") ) {
  return true;
}
isEmpty(Collection c) ==>
if(c == null || c.size == 0) {
  return true;
}
这样的一些封装就很有必要。
5 楼 charon 2006-10-21  
网上有个评论很经典,老马不应该拿一个具体类和一个接口去比较。
要比较,就去和LinkedList比,这个实现了6/7个接口,实现的方法数目不比ruby的那个少,所谓的first/last也都有。
学了ruby之后,看java代码的时候不带有色眼镜,也把ducking type的那一套套到java代码上去,比如一个LinkedList就提供了一个隐含的ILinkedList接口,那就一切ok乐。
记得有个C#大佬死命的推荐具体类,建议除非特殊情况,只要能够用具体类的地方,都不要搞出一个接口来. 其实也非常贴合ducking type的思想精髓,在java/C#中,interface实际上是显式的接口,看着不顺眼就不用,直接使用依着于具体类的隐式接口吧。好处是,显式接口一旦发布,修改是很忌讳的,而具体类的公共方法就没有这个心理负担,虽然实质上是一回事情。
不过这些都是TDD/测试先行带来的间接效果,没有这个前提,别的都是白扯.
4 楼 cookoo 2006-10-19  
这可能和设计哲学有关。 Ruby秉承自Perl的仿自然语言多样性和所谓最小惊讶原则,所以喜欢搞很多方法别名。这个东西有利有弊,好处是减少记忆负担,不用老去查API了,很多用法有个大约印象再猜一下就出来了。坏处是命名空间更加拥挤,名字冲突风险有所提高。
3 楼 runes 2006-10-19  
估计 老马 也犯晕了 :“正反双方都不乏闪亮论点。就我个人而言,我倾向于人本接口一方,尽管我觉得它的难度确实更高。”

那个难度高,不是很显然吗?
2 楼 jack 2006-10-19  
runes 写道
感觉这个问题,关键是用在那里?


问的好!拓宽点说  很多技术看上去都不错。问题用在那里?什么样情况能够用?什么情况下不能用。这个方面的资讯实在是少的可怜。
1 楼 runes 2006-10-19  
感觉这个问题,关键是用在那里?

如果是 准备 标准化的 核心的基础库(这个在这里好像没有什莫讨论的必要,我看不出坛子里谁有从事这方面的斤两),
我倾向最小接口,通过概念泛化 进行 胶合,与STL的iterator比较类似。

如果及用及扔的库,或者说,准备不断演进的框架,开源lib,接口肥大点也无所谓,物竞天择,最后可以淘汰一批接口。

相关推荐

    Martin Fowler《重构——改善既有代码设计》(中文版)

    《重构——改善既有代码设计》是软件工程领域的一部经典著作,作者Martin Fowler,该书与《设计模式》被并称为软件工程的双雄。《重构》一书的主旨在于向读者展示重构的过程与方法,即通过一系列小的、有步骤的改变...

    Domain Specific Languages(martin fowler)

    马丁·福勒(Martin Fowler)在其著作《Domain Specific Languages》中深入探讨了这一主题,该书由Addison-Wesley Professional出版社于2010年9月24日出版。本书提供了关于如何设计、实现和使用DSLs的全面指南,并...

    Martin Fowler名箸 Patterns of Enterprise Application Architec

    Martin Fowler名箸 Patterns of Enterprise Application Architec

    重构----改善既有代码的设计(By Martin Fowler)

    Martin Fowler是重构领域中极具影响力的专家之一,他的著作《重构——改善既有代码的设计》被广泛认为是该领域的经典之作。这本书不仅传授重构的理论知识,还提供了丰富的实际案例和步骤指导,让读者可以将理论应用...

    Java8采用Martin Fowler的方法创建内部DSL

    Java 8采用Martin Fowler的方法创建内部DSL(领域特定语言)是一种强大的编程技术,它允许我们构建高度定制且易于理解的代码。内部DSL是通过在已有的编程语言内部构造一种专用的语言来实现的,使得代码更贴近所要...

    Martin Fowler - 分析模式

    Martin Fowler的《分析模式》是一本在软件工程领域具有深远影响的书籍,尤其是对面向对象分析和设计的实践者。本书首次出版于1996年,是分析模式理论的奠基之作,作者马丁·福勒(Martin Fowler)是国际知名的软件...

    重构 -改善既有代码的设计 [美] Martin Fowler-著 熊节-译

    《重构 -改善既有代码的设计》是由美国著名软件开发专家Martin Fowler所著,由熊节翻译的一本经典IT著作。这本书深入探讨了重构这一关键的软件工程实践,旨在帮助开发者提升既有代码的质量和可维护性。重构是软件...

    分析模式-Martin Fowler

    ### 分析模式-Martin Fowler #### 一、引言与概念模型 《分析模式》是IT界大师Martin Fowler的一部经典著作。本书旨在为复杂的业务分析领域提供一系列实用且易于理解的设计模式,帮助读者更好地理解和解决实际问题...

    重构,改善既有代码的设计(中文版,Martin Fowler 著).part03

    重构,改善既有代码的设计(中文版,Martin Fowler 著).part03

    《重构改善既有代码的设计(中文版)》(Martin Fowler[美] 著,候捷、熊节 译)

    Martin Fowler和《重构:改善既有代码的设计》(中文版)另几位作者清楚揭示了重构过程,他们为面向对象软件开发所做的贡献,难以衡量。《重构:改善既有代码的设计》(中文版)解释重构的原理(principles)和最佳实践...

    UML2初学好书-(“UML Distilled”:Martin Fowler)-中英文合辑

    UML2初学好书-(“UML Distilled”:Martin Fowler)-中英文合辑 EN::(UML Distilled) Third Edition(2003)--CHM格式 , zhTW:(UML 精华第三版) /物件模型语言标准简介---PDF格式 [物件模型语言标准简介初学好书-UML-2...

    设计已死-Martin Fowler

    《设计已死——Martin Fowler》这篇文章探讨了软件开发中的设计理念,特别是对演进式设计的深入剖析。在软件工程领域,设计是构建高质量系统的关键环节,而Martin Fowler的观点引发了业界对于传统设计方法与演进式...

    IOC容器和DI模式.Martin Fowler

    Martin Fowler的Inversion of Control Containers and the Dependency Injection pattern。中文版。 本文中,作者深入探索IOC模式的工作原理,给它一个更能描述其特点的名字——“依赖注入”(Dependency Injection...

    Martin Fowler 控制反转与依赖注入

    ### Martin Fowler 控制反转与依赖注入 #### 重要概念与背景 Martin Fowler的文章探讨了Java社区近期关注的一个热点话题:轻量级容器及其背后的模式。这些容器的主要目标是帮助开发者将来自不同项目的组件组装成一...

    重构,改善既有代码的设计(中文版,Martin Fowler 著)

    这本书第一章讲得实例在现实中经常碰到,至于后续章节需要慢慢品味,除非你只想做个平庸的程序员!

    [电子书] Martin Fowler 经典软件著作合集

    [作者信息] Martin Fowler [出版机构] Addison-Wesley Professional [出版日期] 1996年10月19日 [图书页数] 384页 [图书语言] 英语 [图书格式] PDF格式 ======================================================= ...

    《重构改善既有代码的设计(2010年版)》(Martin Fowler[美] 著,熊节 译)

    重构,一言以蔽之,就是在不改变外部行为的前提下,有条不紊地改善代码。多年前,正是本书原版的出版,使重构终于从编程高手们的小圈子走出,成为众多普通程序员日常开发工作中不可或缺的一部分。...

    重构_改善既有代码的设计(中文版) Martin Fowler

    Martin Fowler和《重构:改善既有代码的设计》(中文版)另几位作者清楚揭示了重构过程,他们为面向对象软件开发所做的贡献,难以衡量。《重构:改善既有代码的设计》(中文版)解释重构的原理(principles)和最佳实践...

Global site tag (gtag.js) - Google Analytics