软件系统坏死的症状

 “Copy”程序：

一个从键盘读入字符并输出到打印机的程序。

void Copy()
{
  int c;
  while ((c = RdKbd()) != EOF)
  WrtPtr(c);
}

用户希望Copy程序能从纸带读入机中读入信息。

现实中的约束－－不能改变接口

Copy程序的第一次修改结果：

bool ptFlag = false;
//remember to reset this flag
void Copy()
{
  int c;
  while ((c = (ptFlag ? Rdpt() : Rdkbd())) != EOF)
  WrtPtr(c);
}

客户又希望Copy程序有时可以输出到纸带穿孔机上。

//Copy程序的第二次修改结果
bool ptFlag = false;
bool punchFlag = false;
//remember to reset these flag
void Copy()
{
  int c;
  while ((c = (ptFlag ? Rdpt() : Rdkbd())) != EOF)
  punchFlag ? WrtPunch(c) : WrtPtr(c);
}

从中我们可以嗅到程序的坏味了：

• 僵化：

–单一的改动会导致有依赖关系模块中的连锁改动 －－ 增加第3种读入/输出方式？

• 脆弱：

–进行一个改动，程序与之无概念上联系的地方都可能出现问题。

• 牢固：

–提出代码进行复用很复杂。

• 不必要的复杂：

–包含没有用的代码。

• 不必要的重复：

–每个重复的代码体中大体相似，但有细微的差别。

• 晦涩：

–模块难以理解。

 

可以肯定，随着需求的进一步变化，坏味的趋势会更严重，程序会变得混乱不堪。

解决方法：运用OO的做法

void Reader
{
public:
	virtual int read() = 0;
};

class KeyboardReader : public Reader
{
public:
	virtual int read() {return RdKbd();}
};

KeyboardReader g_defaultReader;
void Copy(reader& reader = g_defaultReader)
{
	int c;
	while ((c = reader.read()) != EOF)
	WrtPtr(c);
}

回顾：

• 何时改善设计

–最开始的设计就考虑到以后的变化？

•有时是不可能的。

•过度复杂。

•记住设计是有代价的，如果确实不会发生变化，就不需要过度设计。

–当需求第一次会导致原有的设计发生腐化时，抓住这次机会去改进设计。

•避免打补丁的方式。

 

问题所在：

• 依赖关系的不灵活性：

–高层模块直接依赖于底层细节。

–Copy模块直接依赖于KeyBoardReader和PrinterWriter

–依赖倒置：可以用Strategy模式实现依赖的倒置。

• 针对实现编程，而没有针对接口编程。