在前面，我们花了六篇文章的篇幅去讨论需求分析之前发生的事情，这些内容看起来枯燥或飘渺，但实际是为真正开始系统的分析、设计和实现进行的必要准备。从这篇开始，将正式进入系统的开发阶段。这一篇文章，将讨论第一轮迭代过程中的需求分析和领域分析环节。 阅读全文
在前五章中，我们从世界观的这话题开始，逐步引出了抽象、层次、继承和耦合。这些内容，形成了对象论中关于世界的结构体系。然而，要想真正描述一个世界，仅有结构式不行的。开始我们说过，世界观主要关注两个方面：一是世界是什么样子的（结构），另一个就是世界时如何演进的（运作）。现在，我们来讨论对象论中关于世界运作的理论。这里首先要指出一点，“对象论”是关于程序世界（即将一个软件系统看成一个世界）的世界观，而非关于现实世界的，所以，将对象论应用于现实世界时，往往会有所偏颇。其实前面的某些地方已经体现出这一点，而在运作理论这里，会体现的尤其明显。但是为了直观起见，我依然会将对象论应用于现实世界去举例子，当然我会非常谨慎和小心，并且会明确指出对象论应用于现实世界的偏颇在哪里。 阅读全文
这篇文章首先明确了系统开发过程，帮大家解开前几篇文章造成的疑惑。然后，陈述了系统开发阶段的两大法宝：迭代开发与用例驱动。 阅读全文
对于这个问题，也许很多人会说，是灵活的、是易于修改和扩展的、是可维护性高的、是用户体验好的、是文档完整的、是代码规范的、是性能处理优秀的……好吧，我承认，这些都是高质量软件必不可少的元素，但是，还有一个更重要的要素，就是：软件必须做客户希望它做的事。你的软件再灵活、编码再规范，客户不关心，客户最关心的是软件是不是完成了他期待的功能，可以做他希望软件做的事。所有，高质量软件的第一要素就是：让软件做客户希望它做的事。 阅读全文
应该说，从“特性列表”直接到“用例分析”不是一个好注意，因为特性列表关注于功能（Function），而用例关注于系统的业务流（Business Flow），我们从功能直接开始分析系统的细节业务流，这个跨越太大，不利于软件质量的保证。特性是相对分散独立的功能描述，而用例是系统细节，很明显，在这之间应该有一个过渡，而这个过渡，就是一个高层次的，从全局角度对系统的一个概观认识。这个概观认识起到承上启下的作用，既将特性列表映射为一个系统的大概模型，又给系统细节的分析奠定了基础。所以，在系统特性基本确定后，我们首先要从全局给出一个系统的概览，避免落入用例分析这样细节的泥沼。 阅读全文
在上一篇文章中，我们写出了一张特性列表。然后是不是就可以做需求分析了？很遗憾，还不可以，我们仍有许多工作要做。拿到特性列表后第一件事，就是要尽量降低风险。这里先不长篇大论风险如何如何，我们先做，从做的过程中体会降低风险的涵义。 阅读全文
当这个项目开始时，我们得到的关于我们要做的系统的唯一说明是一页Word文档，这是一份简单的不能再简单的说明。文档里只有一行字：我们需要一个系统，使得全国各地的代理加盟商和连锁店能够通过网络订购原料。另外，我们还知道这是一个食品公司，主营面包、麻花、肉夹馍等食品，在全国各地有多家连锁机构。除此之外，我们一无所知。 阅读全文
“OO都是一个已经被讨论烂的话题了，还有什么可写的！”不知当你看到文章标题时，是不是有这种疑问，或者鄙夷。不错，OO从诞生到现在经历了不短的岁月，与其相关的理论、技术、原则、实践、模式、语言已经出了一大堆。可是，你真的了解OO的本质吗？真的能挥洒自如的将OO应用于软件开发中吗？真的能发挥OO的能量，从而提高软件质量吗？如果对这三个问题，你不能很干脆的点头说：“是的，当然！”那么也许你可以抽一点时间，往下看一看。 阅读全文
通过前面两篇，我想各位朋友对“面向接口编程”的思想有了一定认识，并通过第二篇的例子，获得了一定的直观印象。但是，第二篇中的例子旨在展示面向接口编程的实现方法，比较简单，不能体现出面向接口编程的优势和这种思想的内涵。那么，这一篇作为本系列的终结篇，将通过分析几个比较有深度的模式或架构，解析隐藏其背后的面向接口思想。这篇我将要分析的分别是MVC模式和.NET平台的分层架构。 阅读全文
通过上一篇文章的讨论，我想各位朋友对“面接接口编程”有了一个大致的了解。那么在这一篇里，我们用一个例子，让各位对这个重要的编程思想有个直观的印象。为充分考虑到初学者，所以这个例子非常简单，望各位高手见谅。 阅读全文
我想，对于各位使用面向对象编程语言的程序员来说，“接口”这个名词一定不陌生，但是不知各位有没有这样的疑惑：接口有什么用途？它和抽象类有什么区别？能不能用抽象类代替接口呢？而且，作为程序员，一定经常听到“面向接口编程”这个短语，那么它是什么意思？有什么思想内涵？和面向对象编程是什么关系？本文将一一解答这些疑问。 阅读全文
