On the Open Way

JDK1.4中关于String的几个实现方法：

public String(String original) {
  this.count = original.count;
  if (original.value.length > this.count) {
      // The array representing the String is bigger than the new
      // String itself.  Perhaps this constructor is being called
      // in order to trim the baggage, so make a copy of the array.
      this.value = new char[this.count];
      System.arraycopy(original.value, original.offset,
         this.value, 0, this.count);
  } else {
      // The array representing the String is the same
      // size as the String, so no point in making a copy.
      this.value = original.value;
  }
}

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
 
    if (anObject instanceof String) {
 String anotherString = (String)anObject;
 int n = count;
 
 if (n == anotherString.count) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = offset;
            int j = anotherString.offset;
            while (n-- != 0) {
                if (v1[i++] != v2[j++])
                return false;
            }
            return true;
        }
    }
    return false;
}

 

1.程序run起来。
2.程序能够被单元测试。
3.考虑引起变化的因素。
4.面对引起变化的因素，重构。
5.如何对变化进行单元测试，即面对了变化，如何进行单元测试。
6.如何做准确性的单元测试，如何做边界的单元测试。
7.如何保证代码在引起变化的时候仍然具有很好的可维护性（维护中需要好的单元测试做为支持的）。

“We often blame managers for schedule pressure. We often complain that our companies set unreasonable deadlines and have unrealistic expectations. This might be true, but it's only half the problem. The other half, the most important half, is within us. We consider our worth as programmers to be more associated with speed than with quality. And that's a tragedy; because it leads us to create messes. It leads us down the slower path. By rushing we ruin our chance to truly go fast.”

Today's Links:

http://www.artima.com/weblogs/viewpost.jsp?thread=51769

1．   模式

2．   重构

3．   测试

4．   增量交付

5．   频繁构建

今天去听课，老师讲到persistence layer的时候，提到dao的出现主要应付数据库的移植，可能他出现的最初的原型确实如此，仔细想一下，真实的enterprise application的数据源有多少在移植呢，就我们一般而言，一般相对都是很固定，在软件的最初设计阶段就已经选型了。（在OO中讲，如果一个变化可能要等三五年，那么你就得去考虑现在考虑这个变化是不是有意义？）

现在在设计模式的基础上，提出了企业架构应用的诸多模式，这么多模式都是在依赖于设计模式来实现的。那么企业架构应用的诸多模式的价值何在？就persistence layer而言，抽象出数据持久化的一般问题解决方案，看下面的图：

 

在与数据源(一般都是大型数据库)交互的时候，对于网络的依赖是必不可少的。基本的原则：minimize distributed communication(今天老师刚讲的)。在持久层，既是DAO还需要做一定的数据缓冲，减少网络访问，对于本地persistence object的管理才是比较重要的。对于我们的工作中，不一定要做数据缓冲，但是应该考虑对于网络访问是否最小化了。

为什么要分层?

1.       can understand a single layer as a coherent whole without knowing much about the other layers。就如现在我们在设计dao的时候，很少去考虑什么business logic，单纯的去研究数据的访问。

2.       can substitute layers with alternative implementations of the same basic services.这个问题就跟接口有关了，还要讨论的。很好的满足了DIP(依赖倒置原则);

3.       minimize dependencies between the layers.对象之间的应用不再是杂乱五章的，大家都依赖于抽象。

4.       Layers make good places for standardization.现在datasource layer(persistence layer),domain layer,presentation lay.经过大家的群策群力，每一个层次都有了模式，加快了解决问题的速度，使得开发人员集中于一些必要的挑战。最近有提出了service layer.(今天老师讲了The Business Delegate Design Pattern,但是老师却讲到了field和object的对比，这个方式我们早已讲过了，这次SUN单独提出来，它的意义远不再这里，我理解和service layer有一定的关系。)

5.       Once you have a layer built you can use it for many higher level services.这也是分离出层的原型吧。

 

我觉得Pattern of Enterprise Application Architecture讲分层的第一句话特别好：

Layering is one of the most common techniques that software designers use to break apart a complicated software system.

 

依然有了分层，就产生了层，有了层，就有了层与层之间的关系，那么就面对这些 层关系的设计和实现问题。

在企业应用架构有三层（也有四层的分法），这些层之间必然会有一些依赖，我们都知道依赖有一个原则：依赖倒置原则（DIP）

1.       高层模块不应该依赖于底层模块。二者都应该依赖于抽象。

2.       抽象不应该依赖于细节。细节应该以来于抽象。

对应于分层，较“高”层包含了什么，包含了策略选择和业务模型，而这些真是应用程序的价值所在，如果“高”层以来于“低”层，那么“低”层的变化就会影响到“高”层。

更不可能去让“低”层依赖于“高”层。

现在只有一种可能，“高”层和“低”层是独立的。这不也正是我们使用framework的价值所在吗？

这样层与层之间的依赖就必须是抽象，而不是实现和细节。

 

Service layer的出现，是为了面对客户层接入集成了一系列高效的操作集。主要目的提高数据存取和业务逻辑的利用率，减少重复调用。

 

 

Serverice layer是一个边缘层（boundary）。