但是在设计过程中，心里却往往在担心，如果我完全不去考虑程序代码的实现的话，那么我怎么知道我的设计一定合理呢？我怎么知道我设计的类、接口一定可以实现呢？所以经常可以看到的现象就是：
在设计过程中，虽然知道不能过早考虑代码实现，但是每设计一个类，一个接口，心里都要不知不觉的用自己熟悉的编程语言大概的评估一下，看看能否编出来，因此，一不小心，就会又回到按照程序功能实现的思路进行设计的老路上去了。
举个例子来说明，在做Web程序设计的时候，经常要遇到分页显示数据的情况。比如说需要把 系统中所有的用户都列出来这样的功能。假设使用User类来表示用户，增加用户addUser()，删除用户deleteUser()，查询所有用户listUsers()方法。而数据库中有一个user表，一条记录是一个用户的信息。下面考虑一下User类的方法的实现：
addUser()和deleteUser()方法都好实现，就是对数据库增加记录和删除记录。对于listUsers()方法，其实就是对user表的select，取出一个记录集。但是该怎么从listUsers()方法中得到所有用户的列表呢？
一个方法调用的返回值只有一个，没有多个，所以很多情况下采用的办法就是返回值定义为集合类型，比如Vector。这样就可以在listUsers()方法的具体代码实现的时候，从数据库依次取出一个个记录，插入到Vector里面来。在主程序里面，调用listUsers()方法可以返回一个Vector，然后再对Vector遍历操作，就可以得到用户列表了。
public class User {
public static void addUser(...) {
// 数据库insert一条记录
}
public static void deleteUser(...) {
// 数据库delete一条记录
}
public Vector listUsers(...) {
// 数据库select结果放到一个集合里面
}
}
这样的设计基本合理，但是仍然有点小问题。因为在设计的时候，就考虑到了用Java的集合类Vector来实现对不定长数据集的存放，因而违反了面向对象设计的一个原则：在设计的时候不应过早的考虑具体程序语言的实现。所以必须用抽象的方法，和具体实现无关的方法来表达业务逻辑。
我们知道，通常对具有集合特征的数据结构进行遍历通常可以使用next和hasNext方法，next实现取下一个用户，hasNext判断是否还有元素。 因此我们定义一个接口Iterator，这个接口中定义两个方法next和hasNext：
public interface Iterator {
public boolea