Angelo Lee's Blog

<br />Why DDD？<br />1. 业务领域是一个应用程序的核心，使用DDD，直接面对核心业务，可增强业务需求确认速度，可以尽快暴露业务上的缺陷、风险。<br />2. 使用OO对核心业务进行建模，增强可扩展性、可维护性。domain model是核心业务，由POJO实现，不依赖于任何框架、数据库，不管想使用WEB方式或是Swing，或者移植到任何平台，domain model都不需要改变。<br />3. 解除了业务领域代码与非业务领域代码（如UI代码或持久层代码）的耦合，产

最近多次看到系统设计与实现的文章与讨论，再加上以前读过的其他资料以及自己的一些实践教训，让我觉得应该把这些资料汇总整理一下。如果要从讨论不同系统的众多资料中总结一条黄金法则的话，那只有一个词——“简单”；如果用一个英语单词来表达的话，那就是——KISS (Keep It Simple, Stupid!)。麻省理工方法与新泽西方法(MIT Approach vs. New Jersey Ap

Context Two of the main techniques for re-using code are Class Inheritance and Object Composition.Class Inheritance defines a new class in terms of an existing class. A subclass inherits both data a

Principles Of Object Oriented DesignLink：http://www.surfscranton.com/architecture/ObjectOrientedDesignPrinciples.htmDon’t Repeat Yourself (DRY)DRY 是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要

"你不必严格遵守这些原则,违背它们也不会被处以宗教刑罚.但你应当把这些原则看成警铃,若违背了其中的一条,那么警铃就会响起."1.SRP单一职责原则[适用于类功能]  (就一个类而言,应该仅有一个引起它变化的原因.)  详细说明:  如果一个类承担的职责过多,就等于把这些职责耦合在一起.  一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力.  这种耦合会导

(1)所有数据都应该隐藏在所在的类的内部。 (2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。  (3)尽量减少类的协议中的消息。   (4)实现所有类都理解的最基本公有接口[例如，拷贝*作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。    (5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。 如果类的两个方法有一段公

Do FactoryOO DesignJava Camp

<br />概述<br />Singleton模式要求一个类有且仅有一个实例，并且提供了一个全局的访问点。这就提出了一个问题：如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？客户程序在调用某一个类时，它是不会考虑这个类是否只能有一个实例等问题的，所以，这应该是类设计者的责任，而不是类使用者的责任。<br />从另一个角度来说，Singleton模式其实也是一种职责型模式。因为我们创建了一个对象，这个对象扮演了独一无二的角色，在这个单独的对象实例中，它集中了它所属类的所有权力，同时它也

<br />Mutex是一把钥匙，一个人拿了就可进入一个房间，出来的时候把钥匙交给队列的第一个。一般的用法是用于串行化对critical section代码的访问，保证这段代码不会被并行的运行。<br /> <br />Semaphore是一件可以容纳N人的房间，如果人不满就可以进去，如果人满了，就要等待有人出来。对于N=1的情况，称为binary semaphore。一般的用法是，用于限制对于某一资源的同时访问。<br /> <br />Binary semaphore与Mutex的差异：<br />在有

注意本节的标题是“面向服务和面向对象”，而不是“面向服务对面向对象”。这种区别是要强调这两种思想之间的关系不是竞争关系这一事实。 事实上，面向对象编程通常用于构建Web Services中应用逻辑的封装。然而，面向对象编程方法到底与面向服务方法有何根本的不同是值得去探索的，理解它们的不同有助于你将它们放在一起工作。 下面列出两种方法在设计方面的比较。（尽管使用“逻辑处理单元”术语在比较服务和对象会引起的混淆，然而面向服务是基于服务来设计，面向对象是以对象创建为中心。）          面向

The Broken Window TheoryIn a previous entry, I touched on the broken window theory. You might be familiar with the Pragmatic Progammers' take on this:Don't leave "broken windows" (bad