﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>BlogJava-风之语-随笔分类-架构设计</title><link>http://www.blogjava.net/gf7/category/3536.html</link><description>&lt;script language="JavaScript" type="text/JavaScript" src="http://union.3721.com/v2/news.js?a=2073&amp;b=1005&amp;p=1007&amp;nt=10400&amp;m=404045" charset="gb2312"&gt; &lt;/script&gt;
</description><language>zh-cn</language><lastBuildDate>Tue, 27 Feb 2007 14:30:03 GMT</lastBuildDate><pubDate>Tue, 27 Feb 2007 14:30:03 GMT</pubDate><ttl>60</ttl><item><title>轻量级容器的比较</title><link>http://www.blogjava.net/gf7/archive/2005/10/21/16348.html</link><dc:creator>风</dc:creator><author>风</author><pubDate>Fri, 21 Oct 2005 14:08:00 GMT</pubDate><guid>http://www.blogjava.net/gf7/archive/2005/10/21/16348.html</guid><wfw:comment>http://www.blogjava.net/gf7/comments/16348.html</wfw:comment><comments>http://www.blogjava.net/gf7/archive/2005/10/21/16348.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.blogjava.net/gf7/comments/commentRss/16348.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/gf7/services/trackbacks/16348.html</trackback:ping><description><![CDATA[<BLOCKQUOTE><A href="http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight4/#author"><FONT color=#996699>Bruce Tate </FONT></A>, 总裁, J2Life, LLC<BR><BR>轻量级容器可以动态地使系统主要组件之间的耦合变松散。不同的容器包含相同的设计模式，但却具有根本不同的哲学。本文帮助您在下列三种轻量级容器之间作出最佳选择：Spring Framework、HiveMind 和 PicoContainer。<BR>
<P>2002 年在科罗拉多的一次旅行中，我完美地感受了阿肯色河。在三段不同的漂流中，这条河展示了令人惊异的多样性。柔美的布朗峡谷有着开阔的急流，翻滚着巨大的波浪。Royal Gorge 别具特色的悬崖峭壁引导着巨大而笔直的峡谷之下的水力，在这条直线上发生一点小闪失都会受到长途游泳的惩罚。Numbers 具有精密的落差，需要人们在范围狭窄的圆石花园里精确操纵。在一条河里，我有了三次极不相同的体验。</P>
<P>在我的上一篇文章“<A href="http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight3/"><FONT color=#5c81a7>轻量级开发的成功秘诀，第 3 部分：Spring 露出水面</FONT></A>”中，我们学习了轻量级容器的基本原理。本文将向您展示三种最流行的容器：</P>
<UL>
<LI><A href="http://www.springframework.org/"><B><FONT color=#5c81a7>Spring Framework</FONT></B></A> 具有功能齐全的容器、面向方面编程 (AOP) 模型和企业开发所需的所有集成代码。 
<LI><A href="http://jakarta.apache.org/hivemind"><B><FONT color=#996699>HiveMind</FONT></B></A> 出自 <A href="http://jakarta.apache.org/tapestry"><FONT color=#996699>Jakarta Tapestry</FONT></A> 的创建者之手，它允许您为 bean 或比较大的组件（称之为 <I>模块</I>）执行依赖注入。 
<LI><A href="http://picocontainer.org/"><B><FONT color=#5c81a7>PicoContainer</FONT></B></A> 是最小的轻量级容器，只支持 Java™ 技术风格配置，而不支持 XML 配置。</LI></UL>
<P>这三种容器都源于依赖注入，但每种容器都具有极不相同的特征。当我介绍每种容器的高级描述时，您将看到正在运行的每种框架，以及可以应用每种框架的环境。</P>
<P><A name=IDAFDUYB><SPAN class=atitle><FONT face=Arial size=4>核心哲学</FONT></SPAN></A></P>
<P>这三种容器都接受 POJO (plain old Java object)，都具有对象生命周期的钩子（所以它们可以在创建或销毁 bean 时调用您的代码），都执行依赖注入。您可能认为这些主旋律将导致相似的容器，但事实并非如此。尽管植入每种容器的代码可能相似，但容器本身反映了不同的能力、风格和整体哲学。总而言之，每种容器的作者都忠于他们的哲学。</P>
<P><A name=IDALDUYB><SPAN class=smalltitle><STRONG><FONT face=Arial>Spring Framework</FONT></STRONG></SPAN></A></P>
<P>作为开放源码框架的 Geneva，Spring Framework 为数百个 Java 2 Platform, Enterprise Edition (J2EE) API 和开放源码框架提供了轻量级容器和胶水代码 (glue code)。Spring 有一个最重要的前景：让 J2EE 更易使用。读完一些示例和书籍之后，您将看到一些常见的主题： </P>
<UL>
<LI>Spring 支持三种依赖注入——<I>setter</I>、<I>构造函数</I> 和 <I>方法</I> 注入——但总的来说，最流行的模型是 setter 注入。 
<LI>在灵活性和简单性之间，Spring 的 XML 风格配置更重视灵活性。您可以做任何事情，但对于初学者来说，配置文件是晦涩难懂的。 
<LI>Spring 的创始人认为，容器只是整体框架的一小部分。Spring 的大部分价值来源于支持该框架的数千行胶水代码。它易于插入任何系统中。 
<LI>Spring 框架是三种容器实现中最完美的。一般来说，优秀的文档都是完美编写的。 
<LI>Spring 具有自动连线 (autowire) 方式，但大多数示例都没有使用它。我并不十分了解这个决策，但有时候，能够看到明确列出的依赖关系是不错的。 
<LI>Spring 提供了完整的 AOP 框架，使得更容易附加服务。您可以使用 Spring 自己的框架或依赖丰富的 AspectJ 集成（参阅 <A href="http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight4/#resources"><FONT color=#996699>参考资料</FONT></A>）。</LI></UL>
<P>如果要用一个短语来形容 Spring，我会说<I>让企业更强</I>。</P>
<P><A name=IDAIEUYB><SPAN class=smalltitle><STRONG><FONT face=Arial>HiveMind</FONT></STRONG></SPAN></A></P>
<P>Howard Lewis Ship 是 Jakarta Tapestry Web 框架的创建者，他还创建了 HiveMind。作为一个容器，HiveMind 是灵巧、干净且易于使用的。与其他许多较好的开放源码框架一样，Ship 创建 HiveMind 是为了让它帮助解决现实问题。但是，HiveMind 向传统的轻量级容器添加了两个创新：</P>
<UL>
<LI>最重要的 HiveMind 创新是模块。据 Ship 所说，Eclipse 插件激发了他的 HiveMind 模块的灵感。 
<LI>HiveMind 强制您编写接口。（与所有轻量级容器一样，它不提供接口，而由您自己提供接口。） 
<LI>HiveMind 是用户友好的，它提供称为 HiveDoc 的文档工具，友好简明的 XML 配置，以及行准确的错误报告。 
<LI>HiveMind 用户通常优先选择 setter 注入，但该容器还支持构造函数注入。</LI></UL>
<P>如果用一个短语来形容 HiveMind 的话，我会说它是<I>概念正确</I> 的。</P>
<P><A name=IDAXEUYB><SPAN class=smalltitle><STRONG><FONT face=Arial>PicoContainer</FONT></STRONG></SPAN></A></P>
<P>到目前为止，PicoContainer 最重要的特征是它的尺寸。它没有提供许多附加物，但它具有完整的依赖注入容器。PicoContainer 还具有一些惟一特性：</P>
<UL>
<LI>PicoContainer 很小，所以它没有拦截器、AOP 或相似类型的服务，而选择了让其他框架创建这些服务。 
<LI>PicoContainer 支持 Java 配置技术，而不支持 XML 配置技术，这与其他容器一样。 
<LI>PicoContainer 流行的使用模型是构造函数注入，但它也支持 setter 注入。 
<LI>PicoContainer 没有提供许多文档，而且一些现有文档是不完整的，但您不会太需要。 
<LI>PicoContainer 具有一个自动连线方式，它很不错。 
<LI>PicoContainer 的发展似乎有点停滞。</LI></UL>
<P>如果用一个短语来形容 PicoContainer 的话，我会选择<I>理论完美，但不如 Spring 或 HiveMind 实用</I>。</P><BR>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
<TBODY>
<TR>
<TD><IMG height=1 alt="" src="http://www.ibm.com/i/v14/rules/blue_rule.gif" width="100%"></TD></TR></TBODY></TABLE>
<TABLE class=no-print cellSpacing=0 cellPadding=0 align=right>
<TBODY>
<TR align=right>
<TD>
<TABLE cellSpacing=0 cellPadding=0 border=0>
<TBODY>
<TR>
<TD vAlign=center><IMG height=16 alt="" src="http://www.ibm.com/i/v14/icons/u_bold.gif" width=16 border=0><BR></TD>
<TD vAlign=top align=right><A class=fbox href="http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight4/#main"><B><FONT color=#996699>回页首</FONT></B></A></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE><BR><BR>
<P><A name=IDAIFUYB><SPAN class=atitle><FONT face=Arial size=4>编程模型</FONT></SPAN></A></P>
<P>现在我将向您展示社区中流行的编程示例，以帮助您更好地理解容器的作者希望您如何使用它们。我使用 PicoContainer 中的 Kiss 示例来展示 autowiring 和 Java 技术风格的配置，使用 HiveMind 加法器示例来展示模块能力，使用 Spring PetClinic 应用程序来展示 Hibernate 集成。</P>
<P><A name=IDAOFUYB><SPAN class=smalltitle><STRONG><FONT face=Arial>Kiss 示例 (PicoContainer)</FONT></STRONG></SPAN></A></P>
<P>在这三个容器中，PicoContainer 具有最简单的编程模型。要查看 Kiss 示例，可从 <A href="http://picocontainer.org/"><FONT color=#5c81a7>PicoContainer.org</FONT></A> 下载它。安装该示例，浏览到 docs\Two+minute+tutorial.htm，然后您会看到两个组件：</P><BR><A name=IDA2FUYB><B>清单 1. 两个 Kiss 组件</B></A><BR>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console">public class Boy {
    public void kiss(Object kisser) {
        System.out.println("I was kissed by " + kisser);
    }
}
public class Girl {
    Boy boy;

    public Girl(Boy boy) {
        this.boy = boy;
    }

    public void kissSomeone() {
        boy.kiss(this);
    }
}
</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P>这两个类是自解释的。Girl 对 Boy 有依赖关系。该依赖关系将通过构造函数被注入。先实例化一个容器：</P>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console">MutablePicoContainer pico = new DefaultPicoContainer();
</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P>然后注册两个组件：</P>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console">pico.registerComponentImplementation(Boy.class);
pico.registerComponentImplementation(Girl.class);
</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P>稍后您可以向 PicoContainer 请求一个对象，然后操作它：</P>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console">Girl girl = (Girl) pico.getComponentInstance(Girl.class);
girl.kissSomeone();
</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P>这样就差不多了。编程模型是优雅的，基于构造函数的风格意味着您无需包括无参构造函数。对本例中的 Girl 调用这种函数将会使该对象处于不一致的状态，因为 <CODE>kiss</CODE> 方法将抛出异常。</P>
<P><A name=IDAXGUYB><SPAN class=smalltitle><STRONG><FONT face=Arial>加法器示例 (HiveMind)</FONT></STRONG></SPAN></A></P>
<P>现在，让我们看一下 HiveMind 的编程示例。从 <A href="http://jakarta.apache.org/hivemind/"><FONT color=#996699>Apache Jakarta Project</FONT></A> 下载 HiveMind，然后查看加法器示例。您会看到接口和实现。（记住：HiveMind 强制编写接口。）</P><BR><A name=IDAFHUYB><B>清单 2. 加法器示例接口和实现</B></A><BR>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console">public interface Adder
{
    public double add(double arg0, double arg1);
}

public class AdderImpl implements Adder
{
    public double add(double arg0, double arg1)
    {
        return arg0 + arg1;
    }
}
</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P>将该服务暴露在 XML 文件中，如下所示：</P><BR><A name=IDAPHUYB><B>清单 3. 将该服务暴露在 XML 文件中</B></A><BR>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console"><MODULE id=examples version="1.0.0">

  <SERVICE-POINT id=Adder interface="org.apache.hivemind.examples.Adder">

    <CREATE-INSTANCE class=org.apache.hivemind.examples.impl.AdderImpl />

  </SERVICE-POINT>
</MODULE>
</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P>然后，其他应用程序就可以使用该服务了，如下所示：</P><BR><A name=IDAZHUYB><B>清单 4. 其他应用程序可以使用该服务</B></A><BR>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console">Registry registry = RegistryBuilder.constructDefaultRegistry();
 
Adder adder = (Adder) registry.getService("examples.Adder",
  Adder.class);

... adder.add(arg0, arg1)
</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P>注意，HiveMind 的模块让您可以将多个服务组合到一起。如果您需要向容器中的服务添加功能，可以使用拦截器：</P><BR><A name=IDAGA4YB><B>清单 5. 使用拦截器添加功能</B></A><BR>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console"><MODULE id=examples version="1.0.0">
  <SERVICE-POINT id=Adder interface="org.apache.hivemind.examples.Adder">

    <CREATE-INSTANCE class=org.apache.hivemind.examples.impl.AdderImpl />

    <INTERCEPTOR service-id="hivemind.LoggingInterceptor" />
  </SERVICE-POINT>
</MODULE>
</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P><A name=IDAMA4YB><SPAN class=smalltitle><STRONG><FONT face=Arial>PetClinic 应用程序 (Spring)</FONT></STRONG></SPAN></A></P>
<P>Spring 处理事情的方法有些不同。因为 Spring 框架不带有简单的应用程序，我从我的书籍 <I>Spring: A Developer's Notebook</I> 中选择了一个。您可以从 <A href="http://www.oreilly.com/catalog/springadn"><FONT color=#5c81a7>O'Reilly Media</FONT></A> 获取该示例代码。解压示例 4，它展示了一个用于 RentaBike 商店的带有属性的 <CODE>CommandLineView</CODE> 对象，该对象最终成为该应用程序的数据访问对象。</P><BR><A name=IDAAB4YB><B>清单 6. CommandLineView 对象</B></A><BR>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console">public class CommandLineView {
   private RentABike rentaBike;
   public CommandLineView() {}
   public void setRentABike(RentABike rentaBike) {this.rentaBike = rentaBike;}
   public RentABike getRentaBike() { return this.rentaBike; }
...
}

</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P>RentaBike 是具有您希望在自行车商店对象中看到的各种方法的接口：</P><BR><A name=IDAOB4YB><B>清单 7. 接口方法</B></A><BR>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console">public interface RentABike {   
   List getBikes();   
   Bike getBike(String serialNo);   
   void setStoreName(String name);   
   String getStoreName();
}
</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P>没有显示 <CODE>ArrayListBikeStore</CODE>，它是 BikeStore 接口的存根实现。注意，Spring 允许编写接口，但不强制编写接口。下面是描述该应用程序中 bean 的 XML 配置文件：</P><BR><A name=IDA3B4YB><B>清单 8. 描述应用程序 bean 的 XML 配置文件</B></A><BR>
<TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#eeeeee border=1>
<TBODY>
<TR>
<TD><PRE><CODE class=section>
<FONT face="Lucida Console"><BEANS>
  <BEAN class=com.springbook.ArrayListRentABike id=rentaBike>
    <property name="storeName"><VALUE>Bruce's Bikes</VALUE></property>
  </BEAN>
  <BEAN class=com.springbook.CommandLineView id=commandLineView>
    <property name="rentaBike">
      <REF bean="rentaBike" /> 
    </property>
  </BEAN>
</BEANS>
</FONT></CODE></PRE></TD></TR></TBODY></TABLE><BR>
<P>该上下文中有两个 bean。<CODE>commandLineView</CODE> bean 依赖于 <CODE>rentaBike</CODE> bean。该应用程序通过为 <CODE>rentaBike</CODE> 属性指定 <CODE>rentaBike</CODE> 名称，显式解析该依赖关系。注意，PicoContainer 自动连接这种显式关系，Spring 也可以，但大多数用户不使用它的自动连线选项。Spring 还允许您通过拦截器或 AOP 向外观的任何方法添加服务。</P><BR>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
<TBODY>
<TR>
<TD><IMG height=1 alt="" src="http://www.ibm.com/i/v14/rules/blue_rule.gif" width="100%"></TD></TR></TBODY></TABLE>
<TABLE class=no-print cellSpacing=0 cellPadding=0 align=right>
<TBODY>
<TR align=right>
<TD>
<TABLE cellSpacing=0 cellPadding=0 border=0>
<TBODY>
<TR>
<TD vAlign=center><IMG height=16 alt="" src="http://www.ibm.com/i/v14/icons/u_bold.gif" width=16 border=0><BR></TD>
<TD vAlign=top align=right><A class=fbox href="http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight4/#main"><B><FONT color=#996699>回页首</FONT></B></A></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE><BR><BR>
<P><A name=IDAVC4YB><SPAN class=atitle><FONT face=Arial size=4>比较</FONT></SPAN></A></P>
<P>既然已经看到每种容器的哲学，下面是对每种环境的无形特性的详细比较，比如市场份额、整体质量（fit and finish）和整体特性列表。毕竟，即使编程模型是完美的，但如果没有文档，或者由于缺乏社区而您必须自己支持它，那么它也不会成为一个好容器。</P>
<P><A name=IDA1C4YB><SPAN class=smalltitle><STRONG><FONT face=Arial>活动社区</FONT></STRONG></SPAN></A></P>
<P>Spring 有一个充满活力的社区，和一个支持该框架的称为 <A href="http://www.springframework.com/"><FONT color=#5c81a7>Interface21</FONT></A> 的职业服务公司。这很重要，因为您知道您可以获得良好的支持，公司才有动力来支持 Spring 框架。我在社区的经历简直太美好了。Spring 贡献者、创始人和用户都以杰出的内容填满了留言板。</P>
<P>HiveMind 框架是一个 Apache Jakarta 项目，所以有着扎实的基础。它有一个正在成长的萌芽社区。该框架的创始人 Howard Lewis Ship 是独立顾问、优秀导师和不屈不挠的提倡者。但是，要利用 HiveMind 的质量帮助或者查找其 Web 站点之外的内容仍然十分困难。尽管如此，它的在线帮助似乎不错，而且社区似乎正在成长。Hibernate 获得了有趣的胜利，它被选中——或者更应该说，Ship 被选中——组成 TheServerSide.com 的新基础设施，TheServerSide.com 是最重要的 Java 技术社区之一。</P>
<P>PicoContainer 也是一个 Apache Jakarta 项目，它似乎发展缓慢。截止本文撰稿，PicoContainer 的最后一次主要代码发行是在 2004 年 11 月。您看不到太多有关 PicoContainer 的新文章，这有点惭愧，因为我喜欢 PicoContainer 的一些哲学。事实上，我不太确定有没有三种开放源码轻量级容器的空间，尤其是最近第四种轻量级容器项目 Avalon 关闭之后。</P>
<P>就每个社区生成的活动而言，Spring 无疑是优胜者。Interface21 的支持、奇思妙想的论坛、活跃的邮件列表以及社区的跟踪记录都是无与伦比的。</P>
<P><A name=IDAJD4YB><SPAN class=smalltitle><STRONG><FONT face=Arial>整体质量</FONT></STRONG></SPAN></A></P>
<P>社区的大小和实力通常驱动开放源码项目的整体质量。充满活力的社区需要更好的文档和示例，而且它们会参与完成结尾的详细信息。</P>
<P>Spring 团队编写了可与我见过的一些比较好的商业产品相媲美的文档。如果这还不够的话，您还可以找到至少五本主要 Spring 书籍和其他许多包含 Spring 内容的出版物。（我自己曾撰写过两本有关 Spring 的书籍，其中一本书中包括 Jolt-winning <I>Better, Faster, Lighter Java</I> 一章，另一本是快速入门书籍 <I>Spring: A Developer's Notebook</I>）。错误消息是专业性和描述性的。与第三方框架和 API 的集成是所有 Java 技术框架中最好的。包装是经过深思熟虑的，不过略有多余。（它帮助我开始把一些比较小的项目划分成模块。）示例是优秀且有指导意义的。</P>
<P>与 Tapestry 一样，HiveMind 也具有好的整体质量。Ship 自己以那些让 HiveMind 变得简单易用的特性而自豪，比如行准确的错误报告；友好简明的 XML 语法；良好的文档工具 HiveDoc。与用于低级详细信息的 JavaDoc 文档结合使用，您可以更好地描述您的应用程序（HiveMind 模块）的高级特性，从而完善它们之间的依赖关系。</P>
<P>PicoContainer 编程模型感觉自然，但文档不完整（许多方法标记看起来过时好几个月了），而且没有许多使用该容器的真实世界示例。有时候，我会觉得自己在独自穿过鬼魂出没的破屋。</P>
<P>但使用 PicoContainer 确实有一个主要优点。因为您配置现实世界的对象时，会得到一些编译时错误检查。实际上，该容器太小太轻了，以至于除了基本配置之外，没有什么能出错。PicoContainer 做了一项合理的工作。</P>
<P><A name=IDAYD4YB><SPAN class=smalltitle><STRONG><FONT face=Arial>特性</FONT></STRONG></SPAN></A></P>
<P>我不想过多地讨论特性。如果您正在寻找许多胶水代码来减少您的开放源码收藏夹的集成或某特定 J2EE API，Spring 无疑是最佳选择。HiveMind 不尝试参与竞争。相反，它与 Spring 的服务兼容。PicoContainer 不构建而且也不尝试构建附加物，而是选择让开放源码项目为其提供服务。到目前为止，它的效果不太好。</P><BR>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
<TBODY>
<TR>
<TD><IMG height=1 alt="" src="http://www.ibm.com/i/v14/rules/blue_rule.gif" width="100%"></TD></TR></TBODY></TABLE>
<TABLE class=no-print cellSpacing=0 cellPadding=0 align=right>
<TBODY>
<TR align=right>
<TD>
<TABLE cellSpacing=0 cellPadding=0 border=0>
<TBODY>
<TR>
<TD vAlign=center><IMG height=16 alt="" src="http://www.ibm.com/i/v14/icons/u_bold.gif" width=16 border=0><BR></TD>
<TD vAlign=top align=right><A class=fbox href="http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight4/#main"><B><FONT color=#996699>回页首</FONT></B></A></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE><BR><BR>
<P><A name=IDA4D4YB><SPAN class=atitle><FONT face=Arial size=4>哪一个最好？</FONT></SPAN></A></P>
<P>目前，只有一个真正的答案。HiveMind 具有有趣的创新，PicoContainer 具有易于使用的模型（理论上），但社区似乎已经投票选择了 Spring Framework。随着时间的推移，新的容器可能会成长，HiveMind 可能不断获得市场份额，但目前，Spring 是您的最佳选择。</P>
<P>如果您愿意冒一些险，而使用不太成熟或不太流行的容器，您可能决定实现 HiveMind（如果需要模块级别的配置）或 PicoContainer（如果想要微小的容器）。如果需要许多胶水代码来集成持久引擎、事务处理策略和安全性等方面，Spring 具有最完整的组件堆。但请记住：您可以在 HiveMind 容器中使用 Spring 组件。<BR><BR></P>
<P><A name=resources><SPAN class=atitle><FONT face=Arial size=4>参考资料 </FONT></SPAN></A></P>
<P><B>学习</B><BR></P>
<UL>
<LI>您可以参阅本文在 developerWorks 全球站点上的 <A href="http://www.ibm.com/developerworks/opensource/library/os-lightweight4/" target=_blank><FONT color=#5c81a7>英文原文</FONT></A> 。 <BR><BR>
<LI>“轻量级开发”是一个很大的主题，而开发人员经常提到这个说法，以至难以界定它到底是什么含义。“<A href="http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight1/"><FONT color=#5c81a7>轻量级开发的成功秘诀，第 1 部分：核心原则及原理</FONT></A>”开始了这个系列，向您介绍了该运动背后的核心原则及原理。<BR><BR>
<LI>重量级架构（如 Enterprise JavaBeans）用于日常问题可能有点大材小用。“<A href="http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight2/"><FONT color=#5c81a7>轻量级开发的成功秘诀，第 2 部分：减轻容器</FONT></A>”介绍了轻量级容器，并解释它们如何提供满足您业务需要的服务，而无需将您束缚在一个指定的编程模型之上。<BR><BR>
<LI>在本系列的第三篇文章“<A href="http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight3/"><FONT color=#5c81a7>轻量级开发的成功秘诀，第 3 部分：Spring 露出水面</FONT></A>”，学习轻量级容器的基本概念。<BR><BR>
<LI>在 <A href="http://www.pyrasun.com/mike/mt/archives/2004/11/06/15.46.14"><FONT color=#5c81a7>Inversion of Control Containers</FONT></A> 一文中，阅读 Mike Spille 对这三个容器所做的比较。<BR><BR>
<LI>访问 <A href="http://jakarta.apache.org/hivemind"><FONT color=#996699>HiveMind</FONT></A> 获得示例、blogs 和代码。<BR><BR>
<LI><A href="http://picocontainer.org/"><FONT color=#5c81a7>PicoContainer.org</FONT></A> 不太活跃，但是其中有很多关于基于构造函数的注入的思想。<BR><BR>
<LI>阅读 Bruce A. Tate 和 Justin Gehtland 编写的 <A href="http://www.oreilly.com/catalog/springadn/"><I><FONT color=#5c81a7>Spring: A Developer's Notebook</FONT></I></A> 一书（O'Reilly, 2005 年），快速入门 Spring。<BR><BR>
<LI>感谢 <A href="http://www.springframework.com/"><FONT color=#5c81a7>Interface21</FONT></A> 对撰写本文所提供的帮助。<BR><BR>
<LI>Martin Fowler 撰写的关于依赖注入的文章 <A href="http://www.martinfowler.com/articles/injection.html"><FONT color=#5c81a7>Inversion of Control Containers and the Dependency Injection pattern</FONT></A>，很好地描述了依赖注入和服务定位器。<BR><BR>
<LI>Bruce A. Tate 和 Justin Gehtland 编写的 <A href="http://www.oreilly.com/catalog/bfljava"><I><FONT color=#5c81a7>Better, Faster, Lighter Java</FONT></I></A> 一书（O'Reilly, 2004 年），很好地概述了轻量级开发。<BR><BR>
<LI>Rob Harrop 和 Jan Machacek 编写的 <A href="http://www.apress.com/book/bookDisplay.html?bID=405"><I><FONT color=#5c81a7>Pro Spring</FONT></I></A>（Apress, 2005 年）和 Craig Walls 和 Ryan Breidenbach 编写的 <A href="http://www.manning.com/books/walls2"><I><FONT color=#5c81a7>Spring in Action</FONT></I></A>（Manning, 2005 年）这两本书全面介绍了 Spring。<BR><BR>
<LI>developerWorks 文章“<A href="http://www-128.ibm.com/developerworks/cn/java/j-hibern/"><FONT color=#5c81a7>无需容器的对象关系映射</FONT></A>”介绍了如何与 Hibernate 一起使用 Spring 持久性。<BR><BR>
<LI>阅读 developerWorks 文章“<A href="http://www-128.ibm.com/developerworks/cn/java/j-aopwork1/"><FONT color=#5c81a7>AOP@Work: AOP 工具比较，第 1 部分</FONT></A>”，了解 AOP，这是一种有较好透明性的轻量级技术。<BR><BR>
<LI>文章“<A href="http://www-128.ibm.com/developerworks/cn/linux/opensource/os-ecov/"><FONT color=#5c81a7>Eclipse 平台入门</FONT></A>”（developerWorks, 2002 年 11 月）提供了 Eclipse 的历史和概述，以及关于如何安装 Eclipse 和插件的详细信息。<BR><BR>
<LI>访问 developerWorks <A href="http://www-128.ibm.com/developerworks/cn/opensource"><FONT color=#5c81a7>开放源码专区</FONT></A>，获得广泛的 how-to 信息、工具和项目更新，以帮助您利用开放源码技术进行开发，并与 IBM 产品结合使用。<BR><BR>
<P><A name=author><SPAN class=atitle><FONT face=Arial size=4>关于作者</FONT></SPAN></A></P>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
<TBODY>
<TR>
<TD colSpan=2><FONT face=Arial size=4><IMG height=5 alt="" src="http://www.ibm.com/i/c.gif" width="100%"></FONT></TD></TR>
<TR vAlign=top align=left>
<TD>
<P><FONT face=Arial size=4></FONT></P></TD>
<TD>
<P>Bruce Tate 居住在德克萨斯州的首府奥斯汀，他是一位父亲，同时也是山地车手和皮艇手。他是 3 本最畅销 Java 书籍的作者，其中包括荣获 Jolt 大奖的 <I>Better, Faster, Lighter Java</I> 一书，最近又出版了 <I>Spring: A Developer's Notebook</I> 一书。他在 IBM 工作了 13 年，现在是 J2Life、LLC 的创始人兼顾问。他潜心研究基于 Java 和 Ruby 的轻量级开发策略和架构。</P></TD></TR></TBODY></TABLE></LI></UL></BLOCKQUOTE><BR>原文：<BR><A href="http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight4/">http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight4/</A><img src ="http://www.blogjava.net/gf7/aggbug/16348.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/gf7/" target="_blank">风</a> 2005-10-21 22:08 <a href="http://www.blogjava.net/gf7/archive/2005/10/21/16348.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>架构设计速成</title><link>http://www.blogjava.net/gf7/archive/2005/10/11/15280.html</link><dc:creator>风</dc:creator><author>风</author><pubDate>Tue, 11 Oct 2005 12:24:00 GMT</pubDate><guid>http://www.blogjava.net/gf7/archive/2005/10/11/15280.html</guid><wfw:comment>http://www.blogjava.net/gf7/comments/15280.html</wfw:comment><comments>http://www.blogjava.net/gf7/archive/2005/10/11/15280.html#Feedback</comments><slash:comments>3</slash:comments><wfw:commentRss>http://www.blogjava.net/gf7/comments/commentRss/15280.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/gf7/services/trackbacks/15280.html</trackback:ping><description><![CDATA[<P>//组件,容器,引擎,框架,平台<BR>设计，无外乎抽象<BR>先看一段接口的使用代码<BR>public class container{<BR>public void excute(Comp c){<BR>c.metod1();<BR>c. metod2 ();<BR>}<BR>} </P>
<P>interface Comp{<BR>public void method1 ();<BR>public void method2 ();<BR>}<BR>class CompImpt{<BR>public void method1 (){<BR>System.out.println(“method1”);<BR>}<BR>public void method2 (){<BR>System.out.println(“method2”);<BR>}<BR>}</P>
<P>这个就是接口的使用，当你把调用接口的类当作是容器，当作是引擎时，当作是框架时，CompImpt就是组件，你就成为了设计师，把调用接口的类当作是平台时,CompImpt就是插件，你就成了架构师<BR><BR>开个玩笑，呵呵！！</P><img src ="http://www.blogjava.net/gf7/aggbug/15280.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/gf7/" target="_blank">风</a> 2005-10-11 20:24 <a href="http://www.blogjava.net/gf7/archive/2005/10/11/15280.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>怎样成为优秀的软件模型设计者</title><link>http://www.blogjava.net/gf7/archive/2005/10/04/14795.html</link><dc:creator>风</dc:creator><author>风</author><pubDate>Tue, 04 Oct 2005 15:36:00 GMT</pubDate><guid>http://www.blogjava.net/gf7/archive/2005/10/04/14795.html</guid><wfw:comment>http://www.blogjava.net/gf7/comments/14795.html</wfw:comment><comments>http://www.blogjava.net/gf7/archive/2005/10/04/14795.html#Feedback</comments><slash:comments>2</slash:comments><wfw:commentRss>http://www.blogjava.net/gf7/comments/commentRss/14795.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/gf7/services/trackbacks/14795.html</trackback:ping><description><![CDATA[&nbsp;&nbsp;&nbsp;&nbsp;做一个好的架构师一直是我的一个目标。但是，做过这么多项目后发现自己在设计上仍存在很多不足。下文是一篇不错的文章。希望大家能够得到一些启示或共鸣。欢迎大家发表自己在架构设计方面的观点。<BR><BR>&nbsp;&nbsp;&nbsp; 我们期待自己成为一个优秀的软件模型设计者，但是，要怎样做，又从哪里开始呢？将下列原则应用到你的软件工程中，你会获得立杆见影的成果。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;1. 人远比技术重要 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时侯将主要精力都集中在技术上。显然，构件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的东西。但是对于用户来说，如果你设计的软件很难使用或者不能满足他们的需求，后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;2. 理解你要实现的东西 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;3. 谦虚是必须的品格 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你不可能知道一切，你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作，因为软件开发所用到的工具和技术是在不断更新的。而且，一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说，每天可以学习很多新东西（如果愿意的话）。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;4. 需求就是需求 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;如果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么，或者软件的需求定义，那么你的工程注定会失败。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;5. 需求其实很少改变，改变的是你对需求的理解 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;Object ToolSmiths公司（www.objecttoolsmiths.com）的Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要（我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注）。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你工作。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你可以说是新来的开发人员把事情搞得一团糟，但是，你应该确定在工程的第一天就告诉他们应该做什么和怎样去做。 如果你觉得公司不让你与用户充分接触，那只能说明公司的管理层并不是真正支持你的项目。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你可以抱怨公司有关软件工程的管理制度不合理，但你必须了解大多同行公司是怎么做的。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你可以借口说你们的竞争对手的成功是因为他们有了一个新的理念，但是为什么你没先想到呢？ <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;6. 经常阅读 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉太久。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱，但会使你成为一个很有实力的竞争者。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;7. 降低软件模块间的耦合度 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库（我的经验法则是：当应用程序员在写SQL代码的时候，你的程序的耦合度就已经很高了）。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;耦合度低的软件可以很容易被重用、维护和扩充。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;8. 提高软件的内聚性 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;只有高内聚性的模块才可能被重用。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;9. 考虑软件的移植性 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（比如java 的宣传口号write once run many 译者注）。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;记得从16位Windows移植到32位windows的“乐趣”吗 ？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性该变的时候，你的仅仅需要更新那个包就可以了。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;10. 接受变化 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;这是一句老话了：惟一不变的只有变化。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你应该将所有系统将可能发生的变化以及潜在需求记录下来,以便将来能够实现。 通过在建模期间考虑这些假设的情况，你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;11. 不要低估对软件规模的需求 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;Internet 带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;12. 性能仅仅是很多设计因素之一 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级最高的因素，我的观点是，给每个设计因素应有的考虑。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;13. 管理接口 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你应该在开发阶段的早期就定义软件模块之间的接口。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;这有助于你的开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工作。一旦模块的接口确定之后，模块怎样实现就不是很重要了。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;14. 走近路需要更长的时间 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;在软件开发中没有捷径可以走。 缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;避免走捷径，只做一次但要做对（do it once by doing it right）。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;15. 别信赖任何人 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;产品和服务销售公司不是你的朋友，你的大部分员工和高层管理人员也不是。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;大部分产品供应商希望把你牢牢绑在他们的产品上，可能是操作系统，数据库或者某个开发工具。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;大部分的顾问和承包商只关心你的钱并不是你的工程（停止向他们付款，看一看他们会在周围呆多长时间）。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;大部分程序员认为他们自己比其他人更优秀，他们可能抛弃你设计的模型而用自己认为更好的。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;只有良好的沟通才能解决这些问题。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;要明确的是，不要只依靠一家产品或服务提供商，即使你的公司（或组织）已经在建模、文档和过程等方面向那个公司投入了很多钱。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;<STRONG>16. 证明你的设计在实践中可行</STRONG> <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;在设计的时候应当先建立一个技术原型， 或者称为“端到端”原型。以证明你的设计是能够工作的。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;17. 应用已知的模式 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;一般来说，好的模型设计和开发人员，都会避免重新设计已经成熟的并被广泛应用的东西。 http://www.ambysoft.com/processPatternsPage.html 收藏了许多开发模式的信息。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;18. 研究每个模型的长处和弱点 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;目前有很多种类的模型可以使用,用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;19. 在现有任务中应用多个模型 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;20. 教育你的听众 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。 教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;另外， 你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候（比如UML-译者注），你的团队才能实现真正的合作。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;21. 带工具的傻瓜还是傻瓜 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;你给我CAD/CAM工具，请我设计一座桥。但是，如果那座桥建成的话，我肯定不想当第一个从桥上过的人，因为我对建筑一窍不通。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;使用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。成为一个优秀的建模专家需要多年的积累，不会是一周针对某个价值几千美元工具的培训。一个优秀的CASE工具是很重要，但你必须学习使用它，并能够使用它设计它支持的模型。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;22. 理解完整的过程 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。软件开发是一个很复杂的过程，除了编程、建模、测试等你擅长工作外，还有很多工作要做。好的设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;23. 常做测试，早做测试 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;如果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。建立一个技术原型供技术评审使用，以检验你的软件模型。在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;24. 把你的工作归档 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定；归档软件模型中很重要但不很明显的部分。给每个模型一些概要描述以使别人很快明白模型所表达的内容。 <BR><BR><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;25. 技术会变，基本原理不会 </STRONG><BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;如果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和人的因素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工作人员等等。 <BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;软件建模技术是需要多年的实际工作才能完全掌握的。好在你可以从我的建议开始，完善你们自己的软件开发经验。以鸡汤开始，加入自己的蔬菜。然后，开始享受你自己的丰盛晚餐吧。<BR>&nbsp;&nbsp;&nbsp; 作者： Scott Ambler著 乐林峰 译 　来源： umlchina 　&nbsp;&nbsp;风之语 转载<img src ="http://www.blogjava.net/gf7/aggbug/14795.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/gf7/" target="_blank">风</a> 2005-10-04 23:36 <a href="http://www.blogjava.net/gf7/archive/2005/10/04/14795.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>