如何在陈旧的代码库中找出隐藏的设计？本文讨论两种对于代码结构很重要的模式： 组合方法 和 单一抽象层。对代码应用这些原则有助于找到以前隐藏的可重用资产，有助于把现有的代码抽象为成熟的框架。
在这个 系列 的前两期中，我讨论了如何使用测试驱动开发 (TDD) 帮助您逐步发现设计。如果从头开始一个新项目，这种方法的效果非常好。但是，更常见的情况是您手中已经有许多并不完善的代码，在这种情况下应该怎么办呢？如何在陈旧的代码库中找出可重用的资产和隐藏的设计？
 |
|
本文讨论两个很成熟的模式，它们可以帮助您重构代码，寻找可重用的资产：组合方法 和单一抽象层 (SLAP) 原则。良好设计的元素已经在您的代码中存在了；您只需通过工具找出已经创建的隐藏的资产。
科技的变化速度非常快，这有一种糟糕的副作用：开发人员常常会忽视软件知识。我们往往会认为几年前的东西一定已经过时了。这当然是不对的：许多老书仍然能够提供对于开发人员很重要的知识。这样的经典著作之一是 Kent Beck 所著的 Smalltalk Best Practice Patterns（见 参考资料）。作为 Java 开发人员，您可能会问，“13 年前的 Smalltalk 书对我有什么用呢？” Smalltalk 开发人员是第一批用面向对象语言编写程序的开发人员，他们首创了许多出色的思想。其中之一就是组合方法。
组合方法模式有三条关键规则：
- 把程序划分为方法，每个方法执行一个可识别的任务。
- 让一个方法中的所有操作处于相同的抽象层。
- 这会自然地产生包含许多小方法的程序，每个方法只包含少量代码。
在 “测试驱动设计，第 1 部分” 中，我在讨论在编写实际代码之前编写单元测试时讨论过组合方法。严格遵守 TDD 会自然地产生符合组合方法模式的方法。但是，对于现有的代码，应该怎么办呢？现在，我们来研究如何使用组合方法发现隐藏的设计。
您可能很熟悉正式的设计模式运动，这一运动起源于 Gang of Four 所著的 Design Patterns（见 参考资料）。它描述了应用于所有项目的通用模式。但是，每个解决方案还包含惯用模式，这些模式不够正式，但是得到了普遍应用。惯用模式代表代码中常用的设计习惯。紧急设计的真正诀窍就是发现这些模式。它们包括从纯技术模式（例如这个项目中处理事务的方式）到问题领域模式（比如 “在发货之前总是要检查客户的信用”）的各种模式。
请考虑清单 1 中的简单方法。它使用低层 JDBC 连接一个数据库，收集 Part 对象，把它们放在一个 List 中：
public void populate() throws Exception {
Connection c = null;
try {
Class.forName(DRIVER_CLASS);
c = DriverManager.getConnection(DB_URL, USER, PASSWORD);
Statement stmt = c.createStatement();
ResultSet rs = stmt.executeQuery(SQL_SELECT_PARTS);
while (rs.next()) {
Part p = new Part();
p.setName(rs.getString("name"));
p.setBrand(rs.getString("brand"));
p.setRetailPrice(rs.getDouble("retail_price"));
partList.add(p);
}
} finally {
c.close();
}
}
|
|
|
清单 1 不包含任何特别复杂的东西。但是，它也不包含明显的可重用代码。尽管它相当短，但是仍然应该重构。组合方法模式指出，每个方法应该只做一件事，这个方法违反了此规则。我认为，在 Java 项目中任何超过 10 行代码的方法都应该考虑重构，因为它很可能做多件事。因此，我将根据组合方法模式重构这个方法，看看是否可以分离出原子性部分。重构的版本见清单 2：
public void populate() throws Exception {
Connection c = null;
try {
c = getDatabaseConnection();
ResultSet rs = createResultSet(c);
while (rs.next())
addPartToListFromResultSet(rs);
} finally {
c.close();
}
}
private ResultSet createResultSet(Connection c)
throws SQLException {
return c.createStatement().
executeQuery(SQL_SELECT_PARTS);
}
private Connection getDatabaseConnection()
throws ClassNotFoundException, SQLException {
Connection c;
Class.forName(DRIVER_CLASS);
c = DriverManager.getConnection(DB_URL,
"webuser", "webpass");
return c;
}
private void addPartToListFromResultSet(ResultSet rs)
throws SQLException {
Part p = new Part();
p.setName(rs.getString("name"));
p.setBrand(rs.getString("brand"));
p.setRetailPrice(rs.getDouble("retail_price"));
partList.add(p);
}
|
populate() 方法现在短多了，看起来像是它需要执行的任务的大纲，任务的实现都放在私有方法中。把所有原子性部分分离出来之后，就可以看出我实际上拥有哪些资产了。注意，getDatabaseConnection() 方法没有对 parts 做任何操作 — 它只提供通用的数据库连接功能。这说明这个方法不应该放在这个类中，所以我要把它重构到 PartDb 类的父类 BoundaryBase 中。
清单 2 中是否还有其他方法是通用的，能够放到父类中？createResultSet() 方法看起来相当通用，但是它包含 parts 的链接，即 SQL_SELECT_PARTS 常量。如果能够迫使子类 (PartDb) 把这个 SQL 字符串的值告诉父类，就可以把这个方法提升到父类中。这正是抽象方法的作用。因此，我把 createResultSet() 提升到 BoundaryBase 类中，并声明一个名为 getSqlForEntity() 的抽象方法，见清单 3：
abstract public class BoundaryBase {
private static final String DRIVER_CLASS =
"com.mysql.jdbc.Driver";
private static final String DB_URL =
"jdbc:mysql://localhost/orderentry";
protected Connection getDatabaseConnection() throws ClassNotFoundException,
SQLException {
Connection c;
Class.forName(DRIVER_CLASS);
c = DriverManager.getConnection(DB_URL, "webuser", "webpass");
return c;
}
abstract protected String getSqlForEntity();
protected ResultSet createResultSet(Connection c) throws SQLException {
Statement stmt = c.createStatement();
return stmt.executeQuery(getSqlForEntity());
}
|
这很有意思。是否还能把更多的方法从子类提升到通用的父类中？如果看一下 清单 2 中的 populate() 方法本身，可以看出它与 PartDb 类的连接点是 getDatabaseConnection()、createResultSet() 和 addPartToListFromResultSet() 方法。前两个方法已经转移到父类中了。如果对 addPartToListFromResultSet() 方法进行抽象（并使用适当的更通用的名称），就可以把整个 populate() 方法放到父类中，见清单 4：
abstract public class BoundaryBase {
private static final String DRIVER_CLASS =
"com.mysql.jdbc.Driver";
private static final String DB_URL =
"jdbc:mysql://localhost/orderentry";
protected Connection getDatabaseConnection() throws ClassNotFoundException,
SQLException {
Connection c;
Class.forName(DRIVER_CLASS);
c = DriverManager.getConnection(DB_URL, "webuser", "webpass");
return c;
}
abstract protected String getSqlForEntity();
protected ResultSet createResultSet(Connection c) throws SQLException {
Statement stmt = c.createStatement();
return stmt.executeQuery(getSqlForEntity());
}
abstract protected void addEntityToListFromResultSet(ResultSet rs)
throws SQLException;
public void populate() throws Exception {
Connection c = null;
try {
c = getDatabaseConnection();
ResultSet rs = createResultSet(c);
while (rs.next())
addEntityToListFromResultSet(rs);
} finally {
c.close();
}
}
}
|
把这些方法提升到父类中之后，PartDb 类已经大大简化了，见清单 5：
public class PartDb extends BoundaryBase {
private static final int DEFAULT_INITIAL_LIST_SIZE = 40;
private static final String SQL_SELECT_PARTS =
"select name, brand, retail_price from parts";
private static final Part[] TEMPLATE = new Part[0];
private ArrayList partList;
public PartDb() {
partList = new ArrayList(DEFAULT_INITIAL_LIST_SIZE);
}
public Part[] getParts() {
return (Part[]) partList.toArray(TEMPLATE);
}
protected String getSqlForEntity() {
return SQL_SELECT_PARTS;
}
protected void addEntityToListFromResultSet(ResultSet rs)
throws SQLException {
Part p = new Part();
p.setName(rs.getString("name"));
p.setBrand(rs.getString("brand"));
p.setRetailPrice(rs.getDouble("retail_price"));
partList.add(p);
}
}
|
我通过前面的重构得到了什么？首先，与以前相比，现在的这两个类更集中于自己的任务。这两个类中的所有方法都很简洁，很容易理解。第二，PartDb 类专门处理 parts，不涉及其他东西。所有通用的连接代码都已经转移到父类中了。第三，所有方法现在都是可测试的：每个方法（除了 populate()）都只做一件事。populate() 方法是这些类的实际工作流方法。它使用所有其他（私有）方法执行工作，看起来像是执行的步骤的大纲。第四，现在有了小的构建块，可以组合使用它们，所以方法重用变得更容易了。对于原来的 populate() 方法那样的大型方法，重用的机会很少：在其他类中，几乎不可能需要以完全相同的次序做相同的事情。实现原子性方法使我们能够组合使用功能。
|
|
这些重构工作真正重要的益处是得到了可重用的代码。在 清单 1 中，看不到可重用的资产；只看到一大堆代码。通过把混杂的方法分隔开，我发现了可重用的资产。但是，除了重用，还有其他好处。我还为在应用程序中处理持久性的简单框架建立了基础。在需要通过创建另一个边界类从数据库中收集其他实体时，我已经有了基本框架。这就是 提炼 框架的过程，而不是关起门来设计框架。
获得可重用的资产之后，应用程序的总体设计就会透过组成它的代码逐渐显现出来了。紧急设计的目标之一是找到应用程序中使用的惯用模式。BoundaryBase 和 PartDb 的组合构成一个在此应用程序中反复出现的模式。把代码分隔为小块之后，就很容易看出各个部分是如何协作的。
 |
|
组合方法的定义的第二部分指出，您应该 “让一个方法中的所有操作处于相同的抽象层”。下面给出一个应用此原则的示例，帮助您理解它的意义以及它对设计的影响。
请考虑清单 6 中的代码，这些代码取自一个小型电子商务应用程序。addOrder() 方法接受几个参数并把订单信息存储进数据库中。
清单 6. 取自某电子商务站点的 addOrder() 方法
public void addOrder(ShoppingCart cart, String userName,
Order order) throws SQLException {
Connection c = null;
PreparedStatement ps = null;
Statement s = null;
ResultSet rs = null;
boolean transactionState = false;
try {
s = c.createStatement();
transactionState = c.getAutoCommit();
int userKey = getUserKey(userName, c, ps, rs);
c.setAutoCommit(false);
addSingleOrder(order, c, ps, userKey);
int orderKey = getOrderKey(s, rs);
addLineItems(cart, c, orderKey);
c.commit();
order.setOrderKeyFrom(orderKey);
} catch (SQLException sqlx) {
s = c.createStatement();
c.rollback();
throw sqlx;
} finally {
try {
c.setAutoCommit(transactionState);
dbPool.release(c);
if (s != null)
s.close();
if (ps != null)
ps.close();
if (rs != null)
rs.close();
} catch (SQLException ignored) {
}
}
}
|
addOrder() 方法中有许多杂乱的东西。但是，我感兴趣的是接近 try 块开头的工作流。请注意下面这两行：
c.setAutoCommit(false); addSingleOrder(order, c, ps, userKey); |
这两行代码违反了 SLAP 原则。第一行（和它上面的方法）处理设置数据库基础结构的低层细节。第二行是高层的订单方法，业务分析师会理解它。这两行属于两个不同的领域。如果必须在抽象层之间转移，阅读代码会很困难，这正是 SLAP 原则试图避免的情况。可读性问题导致难以理解代码的底层设计，因此难以分离这个应用程序中的惯用模式。
为了改进 清单 6 中的代码，我要根据 SLAP 原则重构它。在经过两轮提取方法 重构之后，得到了清单 7 中的代码：
public void addOrderFrom(ShoppingCart cart, String userName,
Order order) throws SQLException {
setupDataInfrastructure();
try {
add(order, userKeyBasedOn(userName));
addLineItemsFrom(cart, order.getOrderKey());
completeTransaction();
} catch (SQLException sqlx) {
rollbackTransaction();
throw sqlx;
} finally {
cleanUp();
}
}
private void setupDataInfrastructure() throws SQLException {
_db = new HashMap();
Connection c = dbPool.getConnection();
_db.put("connection", c);
_db.put("transaction state",
Boolean.valueOf(setupTransactionStateFor(c)));
}
private void cleanUp() throws SQLException {
Connection connection = (Connection) _db.get("connection");
boolean transactionState = ((Boolean)
_db.get("transation state")).booleanValue();
Statement s = (Statement) _db.get("statement");
PreparedStatement ps = (PreparedStatement)
_db.get("prepared statement");
ResultSet rs = (ResultSet) _db.get("result set");
connection.setAutoCommit(transactionState);
dbPool.release(connection);
if (s != null)
s.close();
if (ps != null)
ps.close();
if (rs != null)
rs.close();
}
private void rollbackTransaction()
throws SQLException {
((Connection) _db.get("connection")).rollback();
}
private void completeTransaction()
throws SQLException {
((Connection) _db.get("connection")).commit();
}
private boolean setupTransactionStateFor(Connection c)
throws SQLException {
boolean transactionState = c.getAutoCommit();
c.setAutoCommit(false);
return transactionState;
}
|
现在，方法的可读性好多了。它的主体符合组合方法的目标：看起来像是执行的步骤的大纲。方法现在处于高层，甚至非技术用户差不多也能够理解方法的作用。如果仔细看看 completeTransaction() 方法，会发现它只有一行代码。难道不能把这一行代码放回 addOrder() 方法中吗？不行，这会损害代码的可读性和抽象层。从高层的订单业务工作流跳到事务的细节是违反 SLAP 原则的。建立 completeTransaction() 方法能够使代码更概念化，避免具体的细节。如果以后要改变访问数据库的方式，只需修改 completeTransaction() 方法的内容，而不必修改调用代码。
SLAP 原则的目标是使代码更容易阅读和理解。但是，它也有助于发现代码中存在的惯用模式。注意，在用事务块保护更新方面有一个惯用模式。可以进一步重构 addOrder() 方法，见清单 8：
public void wrapInTransaction(Command c) throws SQLException {
setupDataInfrastructure();
try {
c.execute();
completeTransaction();
} catch (RuntimeException ex) {
rollbackTransaction();
throw ex;
} finally {
cleanUp();
}
}
public void addOrderFrom(final ShoppingCart cart, final String userName,
final Order order) throws SQLException {
wrapInTransaction(new Command() {
public void execute() throws SQLException{
add(order, userKeyBasedOn(userName));
addLineItemsFrom(cart, order.getOrderKey());
}
});
}
|
我添加了一个 wrapInTransaction() 方法，它使用 Gang of Four 提出的 Command Design 模式的内联版本实现这个常用模式（见 参考资料）。wrapInTransaction() 方法执行让代码正常工作所需的所有具体工作。考虑到包装这个方法的匿名内部类的真正用途，我留下了几行难看的样板代码 — addOrderFrom() 方法体中的两行代码。这个资源保护块会在代码中重复出现，所以应该考虑把它提升到层次结构中的更高位置。
我使用匿名内部类实现 wrapInTransaction() 方法是为了说明语言语法的表达能力的重要性。如果用 Groovy 编写这段代码，那么可以使用闭包块创建更漂亮的版本，见清单 9：
public class OrderDbClosure {
def wrapInTransaction(command) {
setupDataInfrastructure()
try {
command()
completeTransaction()
} catch (RuntimeException ex) {
rollbackTransaction()
throw ex
} finally {
cleanUp()
}
}
def addOrderFrom(cart, userName, order) {
wrapInTransaction {
add order, userKeyBasedOn(userName)
addLineItemsFrom cart, order.getOrderKey()
}
}
}
|
Groovy 的高级语言语法和特性（见 参考资料）让我们能够编写出可读性更好的代码，在与组合方法和 SLAP 等补充技术相结合时尤其如此。
|
|
在本期文章中，我讨论了对于代码设计和可读性很重要的两个模式。在改进现有代码的糟糕设计时，第一步是把它改造成您能应付的东西。从设计或重用的角度来看，长达 300 行的方法是没用的，因为无法把注意力集中在重要的部分上。通过把它重构为原子性的小块，就能够看出您拥有哪些资产。清楚地了解这些资产之后，就可以找到可重用的部分并应用惯用设计原则。
在下期文章中，我将在组合方法和 SLAP 原则的基础上讨论重构如何推进设计。我将讨论如何发现代码库中隐藏的设计。
学习
- Smalltalk Best Practice Patterns （Kent Beck，Prentice Hall，1996 年）：了解组合方法 模式的更多信息。
- The Productive Programmer （Neal Ford，O'Reilly Media，2008 年）：这本书的第 2 部分提供一个更复杂的组合方法和 SLAP 示例。
- Design Patterns （Erich Gamma 等，Addison-Wesley，1995 年）：这是关于设计模式的经典著作，包括 Command 模式。
- Spring Framework：Spring 是一种成熟的框架。
- “实战 Groovy：Groovy：Java 程序员的 DSL”（Scott Davis，developerWorks，2009 年 2 月）：阅读最近恢复发表的 Practically Groovy 系列，了解 Groovy 的高级语法如何帮助您编写可读性更好、更简短的代码。
- 浏览 技术书店，查找关于这些主题和其他技术主题的书籍。
- developerWorks Java 技术专区：查找数以百计的关于 Java 编程的文章。
讨论
215
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
