chelsea
- 浏览: 118216 次
- 来自: ...
-
最新评论
文章列表
See alsoLightening Talk: 简单设计
经常碰到的一段对话是：“这里为什么要引入一个类？字符串就好了，简单设计嘛” 或者 “一个switch/case就搞定的，弄个子类干嘛？”
事实通常是反过来的，引入新的类型或子类比使用字符串或switch/case更简单. 我来解释一下
设计是否简单的一个判断标准是它是否更容易理解. 而我们对事物的理解建立在概念或模型之上. 比如做一个最简单的超市存包系统，能存包能取包，没有进一步的需求.牵扯到的概念可能有包裹，储物柜，存完包有个凭证用于取包. 这时我的设计中引入一个空类public class Package {}来代表包裹，另外一 ...
- 2012-05-22 22:18
- 浏览 547
- 评论(0)
信息, 知识, 和智慧
说一下在看到徐昊介绍的知识漏斗(Mystery, Heuristic, Algorithm)之前我对知识的理解.
我也分了三类: 信息, 知识和智慧
信息: 信息就是我们能直接感知到的东西, 包括看到的听到的嗅到的尝到的摸到的.
知识: 知识 ...
- 2012-05-19 11:51
- 浏览 508
- 评论(0)
---专家系统给测试和测试人员带来了不同的挑战.
我们日常接触到的软件大多为通用软件或者企业应用, 使用起来比较简单, 易于理解.与之对应的, 有一类软件我们称之为专家系统, 它们协助某个领域的专家来做出判断和决策. 比如 ...
- 2012-04-09 18:10
- 浏览 598
- 评论(0)
性能受到系统架构的巨大影响, 而本书并没有涉及在高性能做为一个必需的设计约束时有哪些典型的场景以及可选的架构方案. 本书将内容限定在具体的产品和调优技术上, 或者, 技巧上. 架构决定性能的级别, 需要尽早确定必需 ...
- 2012-03-11 20:24
- 浏览 626
- 评论(0)
性能差是一种美德
ReSharper已经成为.Net开发必备工具. 其贴心的功能和快捷键设计让coding过程可以行云流水般随心而动. 可最近在客户这边写代码时却总是磕磕绊绊, 只因ReSharper变得奇慢无比, 之前从来没感觉ReSharper这么慢. 原因很 ...
- 2012-03-04 22:03
- 浏览 645
- 评论(0)
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI). 关于GUI应用的架构设计, 已经有了很多模式, 比如Martin Fowler的blog中有一篇"GUI Architectures", 里面介绍了Form & Control, MVC, MVP, Passive View, Presentation Model, Supervising Controller, Event Aggregator, Observer Synchronization等多种模式. 模式可以帮助我们建立优雅的架构, 但前提是弄清楚模式的应用场景. 这些模式自然不是凭空产生的 ...
- 2012-02-27 13:15
- 浏览 484
- 评论(0)
高内聚是有极限的. 当代码在一个维度上高度内聚的时候, 在其它维度上是发散的. -- 代码内聚设计的不确定性原理
大家都知道量子力学的不确定性原理: 在微观世界里, 有几对物理量不能同时精确的测定, 包括速度与位置, 以及能量与时间. 比如当我们精确的测定一个粒子的速度使其误差很小的时候, 我们对其位置的测量误差从0到正无穷都有可能, 换句话说, 此时粒子可能位于宇宙的任何地方, 这里的极限就是二者误差的乘积总是大于一个被称为普朗克常数的数.
代码的设计有时会感到同样的张力: 无法做到完全的内聚. 当代码在一个维度上高度内聚的时候, 在其它维度上是发散的或耦合的. 无论是逻辑设计还是物理设 ...
- 2012-02-06 22:57
- 浏览 266
- 评论(0)
估算是软件开发中还没有很好的解决的一个问题, 因此争论也很多, 水平也参差不齐. 我无法给出更好的估算技术, 只是想抛出几个问题和观点
1. 单一职责和问题优先
让我们从几个常见的问题开始:
估实际工作量(人天)还是相对 ...
- 2012-02-01 21:41
- 浏览 582
- 评论(0)
Herb Sutter 曾经有一个观点, 就是一个组件的接口, 不只包括这个组件本身定义的方法, 还包括使用这个组件的客户代码, 比如以这个组件为参数的那些方法. 扩展方法是对Herb Sutter这个观点所做的语法上的支持: 把以这个组件为参数 ...
- 2012-01-30 14:45
- 浏览 528
- 评论(0)
全量测试又慢又难以定位错误, 其所需的测试环境的维护成本也很高. 解决方案就是化整为零分别测试. 然而引入新的问题: 测某个"部分"时所需的依赖如何满足. 解决方案是一组被称为"测试替身(Test Double)"的技术. 我们来看一下这里面具体的问题
为了能编译通过, 我需要依赖被满足
为了能正常运行, 我希望依赖的实现不要出错
为了覆盖到真实场景下的用例, 我需要依赖能够模拟真实场景下的行为, 并且我可以在不同的测试用例下指定不同的行为
在无法方便的观测系统状态变化而做出断言时, 我希望可以退而求其次, 能够得知SUT(System Under Te ...
- 2012-01-04 21:43
- 浏览 402
- 评论(0)
接上篇: <<DCI: 代码的可理解性>>
与领域驱动设计的关系
Domain Driven Design是一种分析和设计方法, 它的目的也是使软件更简单更稳定更易于理解. 但它的出发点或角度是分离业务和技术细节. 业务相对技术实现细节来说是更稳定的, 也更贴近问题域.
DDD实际上有两部分的内容, 领域模型和如何建造领域模型. 但有趣的是事实上DDD对最终的领域模型看起来是什么样子并没有过多刻画, 只有Ubiquitous Language, 技术实现细节无关, Bounded Context等一些基本的属性. 那些构造块比如Entity, Value Obje ...
DCI: 代码的可理解性
- 博客分类：
- 道
可理解性: 为什么几十万字的小说看一遍我们就可以理解, 而几千行code却要一读再读?
--Objects are principally about people and their mental models, not polymorphism, coupling and cohesion
代码难以理解是软件行业的痼疾. 众多方法和方法论致力于解决这个问题, 不管主观还是客观. 造成理解困难的原因有很多, 我们今天讨论其中一种: 业务流程被分解在代码中, 支离破碎.
而这个原因的引申问题就是: 业务流程在代码中如何组织? 对于这个问题, 争论从未停止:
Transa ...
Service
Service历来是争论的焦点. 批评者认为Service的存在表明了职责的不清晰, 认为Service里的代码是没放对位置的代码, 都应该放到相关的Domain对象如Entity中. 总而言之Service不够OO. Service是Transaction Script. 事实上这未必是Service这个bu ...
Bounded Context
人们总是试图建立一个统一的模型, 某种一致的描述. 物理定律表现出来的一致性震撼人心, 是相对成功的例子. 绝大多数人都相信自然界存在一个终极的理论来描述宇宙的本质. 物理学的历史也就是不断趋近这个终极 ...
领域驱动设计: More Practice
- 博客分类：
- 道
DDD的关键问题是如何识别缺失的领域概念. Eric的书里提供了一些方法, 比如倾听表达用语, 检查不协调之处, 研究矛盾之处等等. 我们需要更多的实践来捕捉缺失的概念.
新实践: 检查更换编程框架对代码带来的影响.
这个实践基于以下的理念: 业务逻辑没有发生变化则领域模型也不应该变化. 因此如果更换编程框架造成了大量业务代码的变动, 则意味着有概念没有被封装在领域层.
这里并非鼓吹要应用程序可以支持动态的切换编程框架, 比如从一种ORM工具切到另一种, 或者从一种MVC框架切到另一种. 这里强调的是领域模型及领域概念应该独立于编程框架来表达, 虽然最终模型需要通过某种关联或适配被框 ...