软件设计中窄接口的概念

软件设计中的“窄接口”设计，

即主张接口定义应体现需求的正交性特点，即同一个接口应该仅全部或部分地体现一类正交需求，软件实现则通过同时实现多个接口来体现实际需求的多角度特性。相反地，即所谓“宽接口”设计，总是努力将来自不同角度，彼此关系不大的需求定义到同一个接口中，仅仅因为这些需求在当前系统中需要被同时满足。

毫无疑问，多数人会在逻辑上认同“窄接口”设计，但“宽接口”设计为什么仍然大行其道（至少也是普遍存在）呢？究其原因是“窄接口”设计在实现上往往意味着软件部件，比如C++的Class要同时实现多个接口，并且其中部分“锦上添花”的接口（为满足一些增强型需求）可能是可选的，具体的Class可以实现也可以不实现，这就给实际编程中的类型转换带来很多烦恼。 

比如，实现一个Class叫Cellphone（手机）， 为描述其不同角度特征，它分别实现了以下接口：IPhone，描述手机的通话功能; ISMS，描述手机的短消息功能; IPower，描述手机的充电方式，比如是否支持USB充电。另外，还实现了一个Class叫MP3，它分别实现了IMemory，描述其容量; 和IPower，描述其充电方式。现在设计一套USB充电系统，根据目标对象是否支持USB充电方式决定是否对其进行USB充电。上述Cellphone和MP3对象都可以被传入USB充电系统，但实际传入的可能是Cellphone的IPhone接口指针及MP3的IMemory指针，USB充电系统自己应该有能力去寻找相应的IPower接口，实际的做法通常也很简单， USB充电系统拿到传入的对象指针先作个动态类型转换：IPower *power=dynamic_cast<IPower*>(parameter_object); 如果转换结果为NULL，则表示其对应的对象根本没有实现IPower接口，也就无法对其充电。 该方法非常简单，且在简单的场合中，通常也工作得很好，但在实际系统设计中，按照普遍性程度，同一类接口也会分层定义，表现为接口之间的继承关系，在实际实现中往往存在复杂的多重“虚继承”（接口实现）与“实继承”（普通类继承）并存的情况，有时会出现“环形继承”，即不同父类共享相同祖先的情形。这时，上面的dynamic_cast会不工作，出现编译错误