软件设计遇到的一个与同事产生思想不一致的问题，大家参谋一下

hongbupt

进程A 和 进程 B 需要通信， A发送（由class Send 完成）， B接收（由class Recv）。发送的数据值有限的，也就是说把一个枚举值发送出去， 我的设计伪代码如下：

进程A：
class Send{
public:
     send_event(eventid);
};

进程B：
class Recv {
public:
      recv_event(eventid);
};

然后定义一个event 头文件 由A 和 B包含进去就可以了，

enum event{
EVENT_1,
EVENT_2,
EVENT_3,
EVENT_4,
EVENT_5,
EVENT_6,
EVENT_7,
EVENT_8,
......
};

但是同事觉得以下方式好：

class Send{
public:
  send_event_1();
  send_event_2();
  send_event_3();
  send_event_4();
  send_event_5();
  send_event_6();
  send_event_7();
  send_event_8();
   .....
};

class Recv{
public:
  recv_event_1();
  recv_event_2();
  recv_event_3();
  recv_event_4();
  recv_event_5();
  recv_event_6();
  recv_event_7();
  recv_event_8();
   .....
};

我这种方式设计的代码太冗余，并且接口总是随着event 变化而变化，没有可扩展性。

大家看看如何

hongbupt

洗望大家发表一下意见，尽管问题简单

ThinkMachine

你同事的理由呢？

hongbupt

理由比较多，几个重要理由是：减少共享头文件，不需要传递event参数而直接调用函数。至少到目前，我还没看到这样写代码

shan_ghost

接口设计原则： 完整且最小。

完整就是功能完备，所需的功能都能提供；最小就是接口数目要少，越少重用率就越高，代码冗余也就越小，有错误被测到的可能性就越高。


不过，注意这里有个前提，就是 接口本身要简洁，不要传条件参数进去——如果参数A取true，则做这个；如果参数B取false，则做哪个。
甚至如果滥用条件参数，那么任何功能都可以用一个接口完成： 如果参数A等于printf，则xxx；如果参数B等于scanf，则yyy，这显然就扯淡了。


具体到你的设计上，如果接受/发送不同的消息有不同的逻辑，那么就应该分成不同的接口（但先用同一个接口接受所有消息、然后再dispatch下去应该更合理一些；甚至如果预期以后event种类、数量可能变化的话，搞一个注册/回调机制会更优雅）；否则，如果没有功能差别的话，单一接口更好一些。

020794

强烈顶楼上，说得太好了

020794

原帖由 shan_ghost 于 2009-11-4 10:14 发表
接口设计原则： 完整且最小。

完整就是功能完备，所需的功能都能提供；最小就是接口数目要少，越少重用率就越高，代码冗余也就越小，有错误被测到的可能性就越高。


不过，注意这里有个前提，就是 接口本 ...

金玉良言

hongbupt

说的太好了，我完全同意，我的接口就是用来接收事件的，然后再把事件传递给 状态自动机，状态自动机根据不同输入事件做不同事情。这些事件用途都是为同一个状态自动机输入参数。

epegasus

2强相遇,勇者胜

hongbupt

这里的事件的逻辑都是为一个状态机所用，而不是类似于 event1 是驱动打印机而event2是驱动网卡这样毫无关联的事件。