如何优雅的设计一个接口

最近面试有两次碰到过给你一个需求，或者一个什么样的功能，你会怎么去设计/实现。

https://github.com/DarrenDuXuan/CodeDesign

1. 接口设计

   设计一个搜索指定目录下特定类型文件的函数，
   要求写出返回值、函数名、参数列表
   (不需要写实现)
   详细咨询了细节之后，得到的一些细节点有：
   1. 针对业务方需求，可能搜索的规则不一样。比如文件名以 abc 开始的文件，文件名以 abc 结尾的文件，文件后缀未 abc 的文件。
   2. 返回值，刚开始说的是一个文件名也就是 NSString ，但是后来我想了一下，又沟通了一下，改为了 List 也就是 NSArray <NSString >。

我当时说的两种方案。

• 第一种方案：
  定义 ENUM

  typedef NS_ENUM(NSInteger, FileSearchRules) {
     FileSearchRulesFileNameBegin,
     FileSearchRulesFileNameEnd,
     FileSearchRulesExtension,
  };
  

  实现

  - (NSArray <NSString *> *)searchFileList:(FileSearchRules)rules key:(NSString *)key;
  

  根据不同的 rules 去调用不同的查询方法。
  一开始我想的是定义一个 Mode ，里面包含 Rules 跟 key，但是后来想了想，设计接口，最好还是不要使用多余的 Mode ，能一个参数搞定的，最好不要使用两个参数，也要尽可能的去 Mode。

• 第二种方案
  同样是上面的 NS_ENUM ，同样的方法。需要定义一个新的方法，通过 rules 或者不同规则的一个实例，这个实例遵循一个定义好的一个 search 接口，返回对应的 List 。

  @protocol FileSearchProtocol <NSObject>
  - (NSArray <NSString *> *)searchFileList:(NSString *)key;
  @end
  

   - (id <FileSearchProtocol>)getSearchRuleMode:(FileSearchRules)rules {
   }
  

  通过 rules 获取不同规则的实现 Mode ， 从而增加了方法的可扩展性以及可维护性。这也是用到了设计模式里面的策略模式加简单工厂？

• 第三种方案

  1. 这种方案，是我在当天晚上睡不着的时候，想到的一种后续业务方可能会提出的一种需求。要问为什么睡不着，那就只能说是面试面的有点自闭，从而睡不着的。
  2. 说需求，这种接口其实最开始就该想到的，面对不同的业务方，单一策略肯定是太呆了，后续一定会有业务方提出这样的需求。对于这个规则，一种规则不够我们用了，我要同时查好几种规则。 不知道我说明白了没。也就是说，根据一个 key 甚至多个key 查找同时满足多种规则的文件，输出对应 List 。
  3. 这个时候 ENMU 就不合适了，要请出 NS_OPTIONS 这尊大神。

  typedef NS_OPTIONS(NSUInteger, FileSearchRules) {
    FileSearchRulesFileNameBegin = 1 << 0,
    FileSearchRulesFileNameEnd   = 1 << 1,
    FileSearchRulesExtension     = 1 << 2,
  };
  

  在这样的需求下，我就只能想到使用正则表达式了，首先根据规则编写正则，拿到所有文件名的 List ，再根据正则去匹配出最后的 List 输出。
  或者有什么更好的实现方式，还请评论我。

2. 结构设计

   	MP4	AVI	MP3	JPG
   下载	1	1	1	1
   解压	1	0	0	0
   解码	1	1	0	1
   储存	1	1	1	1
   展示	1	1	0	1

   大概意思就是，一套框架，同时支持视频、图片、音频等多种格式的文件下载。下载完成后后续会有很多不同的操作，包括解码、储存等，但是不同格式的文件，需要的路径不一样，就像上面表里面的1和0，1表示需要做这一步操作，0表示不需要，而且后续可能会支持更多操作。你如何去设计。

• 我当时给出的方案是，一个 Mgr ，所有的操作，在上一步操作做完之后，判断当前文件类型是否需要做下一个操作，不需要的直接跳过当前步骤。不过一些步骤需要抽象一个 Protocol 出来（如：解码），不同的文件类型解码方式不同，便于扩展。
• 后续想了想，感觉有点 Low。是不是可以使用数据结构链表，去代替每一步操作。具体情况看代码吧，就只是这么个思路。具体细节肯定还有很多，比如 Node 怎么去实现，扩展性以及可读性等等。都需要细细的去思考。

对于框架搭建，常见的设计模式还是要了然的。至于架构那几点，单一职责什么的，也是要知道的。