| 商家名称 | 信用等级 | 购买信息 | 订购本书 |
 |
 |
元素模式 |  |
 |
|
元素模式 | |
网友对元素模式的评论
我其实是为了凑单而买此书， 事实上对于一个像我这样写了超过26年代码的人， “设计模式” 这个话题是没什么太大吸引力的， 因为对于如何更好地解决那些问题，我们有更深入地看法（比GOF带来的，被全世界捧上天并劣质模仿的方案）
但是翻看此书，可以深切感受到作者比GOF四人高得多的代码功底， 虽然他的一些想法与提法，跟我的认识有些不同，但是他自圆其说并且非常有说服力，从另外一个角度，让我对代码的组织和问题模型的理解有了一个新的角度。 很棒！！
书译完至今已经有大半年了，电子工业出版社也在去年的六月正式出版了它。在此之后，我从审稿者以及读者手里得到的大部分反馈无非就是三个问题：为什么书名翻译成“元素模式”？这本书与《设计模式》这本书的关系是什么？这些模式有什么用？所以，我打算写一篇文章，谈谈我的看法。
首先，这本《Elemental Design Patterns》的书名，如果按照中规中矩的译法应该翻译成“设计模式要素”，但看完全书，你会遇到一个问题，就是这本书讲的是16种可用各种编程语言实现的模式。换句话说，它是有实体的“模式”，而不是抽象的“要素”。所以似乎改成“元素级设计模式”更为合适。但作为一个学术性的，得了Jolt大奖的作品，用如此之长的书名有点不太合适。因此本书的第一译者高博兄与我反复讨论，最终定了这四个字的书名。我们希望它能激发起读者好奇心，并且让读者读完之后才能理解“元素”这两个字的精妙所在。
接下来，我来说说它与GoF模式之间的关系。其实，关系就在“元素”这两个字上，元素在化学上对应的是原子，原子通常意味着不可再分性（当然，实际上还可以再分的，这里只是一个比喻）。作者在书中构建了一个设计空间，按照OOP中最简单的设计概念分成了几个不同的设计空间。然后用这种空间维度对现有的设计模式，主要就是GoF模式进行了分解。所以从粒度上来看，元素模式最重要的是其原子性，它被作"rest":"者认为是不可再分的模式，而后者则是由元素模式组成的分子模式或者更大粒度的模式。这种思想在这本书中是至关重要的。<br /><br />最后再来谈谈“有什么用”的问题。通常我们提到单件、工厂这些模式的时候，很容易有意无意的把模式认识成模版，来生搬硬套，但如果我们把这些模式分解成元素模式，就很容易理解到它不过是一些设计套路的组合而已，而这种套路才是“模式”，它们是可以变化的，根据实际情况重新组合的，甚至还是可以作为反例的。它们并不是设计社区所流传的神话，后来者只能把它们供起来，生搬硬套。因此。模式的粒度越小，我们组合起来的灵活度就越高。当然了，和这个现实世界一样，你不知道原子的存在，物质也是这样组成的，这些模式你其实天天在用，只不过你是不是“有意识”的在用而已。这是一个设计经验的问题，比如java里面本身就用了很多工厂模式，但如果你没有意识到他是工厂模式，他可能就只是用来创建标准库的对象，一旦你自定义对象就不会追求这种创建方式的一致性，这样一来，后期维护的时候，由于你自己的库，和标准库之间有明显的设计差异，这会带来各种各样的问题。比如C++中，几乎一个库一种string类型就是一个典型的例子。元素模式的作用也是如此。"
理论内容多，作者主要工于理论上的自洽，似乎并无大量项目经验做支撑，所提出的元素拆解法更像是一种对设计模式零件化的尝试，且未必是成功的尝试。感觉编程不能预做可公式化的假设，编程用到数学，编程用到模块化，但是编程有自己的特点，大范围上可能不是精确可控的。
所以才会有面向测试的软件设计。
看了一般就没看下去了
只看了前五章，内容含金量十足，体现了数学的严谨之美；这本书依旧是欧美书籍那种行云流水但是每句话干货十足，每句话平均信息量感觉超过代码大全。 但这本书不是技术快餐书，不太能教你如何使用，它更是一本智慧丛书，读它会让你有种回到大学学习理论知识的感觉。另外个角度也能感受翻译的水平和用心。
本书是划时代的作品，深入设计模式的本质，将现有的GoF设计模式彻底拆解，建立模式间的直观联系，摆脱死记硬背并彻底掌握设计模式的来龙去脉。
喜欢元素模式请与您的朋友分享,由于版权原因，读书人网不提供图书下载服务
