一个团队中，界面程序员是个尴尬的角色。一般情况下，他们只是排列不同的控件，然后将美工提交的图片放置于窗体的某个位置…… 真的这么简单吗？我们在强调代码重用和组件化的时候，似乎有意无意忽略了界面的重用型和可维护性，一不小心这个原本看似简单的工作就有可能对项目组造成损害。我们来看看界面开发中常见的问题，并试图以我个人的经验给出一个可能是“合适”的解答。1. 稍微复杂的窗体上被密密麻麻放置了一堆控件，我

我们已经很习惯于使用工厂模式来创建对象，作为最常用的设计模式，可以让客户端非常容易地在多个产品类型中切换。尽管客户端使用接口或者抽象类来调用产品方法，但是我们依然无法摆脱具体的产品类，我们必须引用最终产品类库来创建目标产品对象，这是工厂模式的弊端。如果使用模板方法，我们就必须将产品接口和抽象类作为单独的类库打包，否则模板方法所在类库和最终产品类库间就会形成循环引用(见系统架构设计 & 避免循环引用

最近接触了几个程序员朋友，发现对设计模式(Design Patterns)很感兴趣，这是好事。因为学习编码和面向对象一段时间以后，适当掌握和应用设计模式可以提高编码的质量，并逐步提高自己的能力，往架构方面发展。但是他们和很多人一样，其中包括我，重复走着弯路。设计模式更多的是一种思想的实际体现，在应用的时候没必要生搬硬套，更没必要非得把二十多个设计模式强背下来。我们需要的是去理解，在设计的时候我们会

今天有同事问这个问题，记得以前也曾遇到过类似问题，特记录下来，免得再次忘记。下面这个系统结构图，恐怕大家都很熟悉。这种结构非常简单，而且其好处十分明显：1. 架构设计师完成设计后，使用工具直接生成Facade Library框架，将界面和类库开发进行分离。由于完全基于接口和外观模式，使得界面和类库之间的耦合降到最低。2. 界面程序员可以直接使用数据模拟类来进行开发，而无需等待类库(Conc

使用多层架构进行系统开发是现今系统设计的流行趋势。通过分解业务细节，将不同的功能代码分散开来，更利于系统的设计和开发，同时为可能的变更提供了更小的单元。以下就是一个典型的多层体系结构图。首先我们以“订单(Order)”为例，进行一个简单的业务分解。1. 订单自然包括订单的内容(OrderInfo)，其中有诸如订单编号、商品名称、数量，以及金额等信息。2. 有了订单信息，我们还需要一个存储订