BlogJava-向左走，向右走。。。-随笔分类-软件工程http://www.blogjava.net/tower/category/846.html永远不回头zh-cnTue, 27 Feb 2007 09:00:31 GMTTue, 27 Feb 2007 09:00:31 GMT60设计模式精解 [读书笔记]http://www.blogjava.net/Tower/archive/2005/03/13/2047.html非飞非飞Sun, 13 Mar 2005 15:41:00 GMThttp://www.blogjava.net/Tower/archive/2005/03/13/2047.htmlhttp://www.blogjava.net/Tower/comments/2047.htmlhttp://www.blogjava.net/Tower/archive/2005/03/13/2047.html#Feedback0http://www.blogjava.net/Tower/comments/commentRss/2047.htmlhttp://www.blogjava.net/Tower/services/trackbacks/2047.html做了这么久的软件，从来就没有好好的学习过设计模式。写代码，做设计的时候都是稀里糊涂。做出来的设计，都会不同程度的让自己感觉到不安。这可能就是《设计模式精解》书中所说那种直觉吧。

引用：

留意你的知觉

出自本能的直觉能对设计质量做出令人惊讶的预测。所谓“出自本能的直觉”，是指当你看到某些不喜欢的东西时，你胃部的感觉。我知道这听起来并不科学（而且它的确不科学），但我的经验总是向我证明：当我从直觉上不喜欢一个设计时，一个更好的设计一定就躺在角落里。

Facade模式：关键特征

意图：希望简化现有系统的使用方法。你需要定义自己的接口。
问题：只需要使用一个复杂系统的一个子集。或者，需要用一种特殊的方式与系统交互。
解决方案：Facade向客户展现使用现有系统的一个新的接口。
参与者与协作者：向客户展现一个定制的接口，让客户更容易地使用现有系统。
效果：Facade模式简化了对所需子系统的使用。但是，由于Facade并不完整，因此某些功能对于客户可能是可用的。
现实：1）定义一个（或一组）新的类来提供所需要的接口。
             2）让新的类使用现有的系统。

Facade模式使用于以下情况：

  • 不需要使用一个复杂系统的所有功能，并且可以创建一个新的类来包容访问原有系统的接口的一个子集（通常它就是）比原始系统AP简单得多。
  • 希望包装或隐藏原有系统。
  • 希望使用原有系统的功能，并且希望增加一些新的功能。
  • “编写一个新的类”的代价小于“让所有人学会使用原有系统”或“在未来维护整个系统”所需的代价

 



非飞 2005-03-13 23:41 发表评论
]]>组织团队开发项目的方式http://www.blogjava.net/Tower/archive/2005/03/03/1667.html非飞非飞Thu, 03 Mar 2005 13:06:00 GMThttp://www.blogjava.net/Tower/archive/2005/03/03/1667.htmlhttp://www.blogjava.net/Tower/comments/1667.htmlhttp://www.blogjava.net/Tower/archive/2005/03/03/1667.html#Feedback0http://www.blogjava.net/Tower/comments/commentRss/1667.htmlhttp://www.blogjava.net/Tower/services/trackbacks/1667.html
    一个项目通常分为表示层、业务逻辑层和持久层，这是最为常见的三层结构。在组织团队进行项目开发的时候，选择如何分工对版本控制有很大的影响。团队在做开发的时候一般有两种模式：按层开发和按功能开发。

按层开发（本人赞同的模式）

    在这种开发模式下，每个开发人员的目录结构相对固定和独立。对于CVS这类按文件夹来控制权限的版本控制服务器来说，比较容易实现对开发人员权限的划分，不易出现文件不同步而导致的版本混乱。

    另外，这种开发模式下，更能集中开发人员的注意力，不需要了解太多与本层无关的其他技术。将精神全部集中在如何实现本层的功能上，更有利于写出功能强大，运行稳定的代码。例如：开发业务逻辑层的开发人员，他不可避免的会写很多逻辑上基本上一致的代码，在写代码的过程中，就能从中找出一些相对的共性，将公共的代码进行抽象，从而避免了出现大量的重复代码。由于工作范围相对较小，能有更多的时间去学习相关方面的最新技术和解决方案，并应用到程序中，能使程序在实现方式上较为先进、优越。

    老天是公平的，万物有其好的一面也必然有其不好的一面，这种开发模式也不能例外。对于需求不明确，无法定义相对固定的对外接口时，这中按层开发的模式就有其无法避免的一个问题。各层开发人员需要在开发的过程中，反覆的修改接口，以便适应于变化了的需求。这必然就导致逻辑处理部分代码要做相应的修改。

按功能开发（本人持保留态度）

    这种开发模式下，开发人员的目录结构基本是项目的完整目录接口，他们需要到各层去编写对应他们所开发的模块的所有代码。对于CVS这类版本控制服务器来说，基本上是无法做到对开发人员权限的界定。很容易造成版本控制混乱，导致文件版本不同步，是在开发过程中使用了公共文件的开发人员不能保证同步。例如：一个文件为多个开发人员所共同维护，开发人员各自都需要在其中添加自己功能所需要部分的代码。这样很容易出现多个人同时修改一个文件的情况，导致文件不同步而造成的版本混乱。

    另外，这种开发模式对开发人员的技术要求相对较高，它要求开发人员掌握各层中所需要的技术。从界面显示到数据持久化，甚至到网络通信都需要一个开发人员去实现。在功能实现架构不是很确定的情况下，程序代码中将会出现大量的重复代码，因为每个人都有自己的实现机制，而逻辑处理相同或相近的情况在同一层中出现频率又比较高。导致程序的整体结构不统一，尽管层次结构相同。使得程序日后维护极度困难，大大的提高了维护成本。由于开发人员牵涉使用的技术过多，也很难保证程序实现方式的先进性和优越性。





非飞 2005-03-03 21:06 发表评论
]]>