最近面试有两次碰到过给你一个需求,或者一个什么样的功能,你会怎么去设计/实现。
https://github.com/DarrenDuXuan/CodeDesign
-
接口设计
设计一个搜索指定目录下特定类型文件的函数,
要求写出返回值、函数名、参数列表
(不需要写实现)
详细咨询了细节之后,得到的一些细节点有:
1. 针对业务方需求,可能搜索的规则不一样。比如文件名以 abc 开始的文件,文件名以 abc 结尾的文件,文件后缀未 abc 的文件。
2. 返回值,刚开始说的是一个文件名也就是 NSString ,但是后来我想了一下,又沟通了一下,改为了 List 也就是 NSArray <NSString >。
我当时说的两种方案。
-
第一种方案:
定义 ENUMtypedef 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 , 从而增加了方法的可扩展性以及可维护性。这也是用到了设计模式里面的策略模式加简单工厂?
-
第三种方案
- 这种方案,是我在当天晚上睡不着的时候,想到的一种后续业务方可能会提出的一种需求。要问为什么睡不着,那就只能说是面试面的有点自闭,从而睡不着的。
- 说需求,这种接口其实最开始就该想到的,面对不同的业务方,单一策略肯定是太呆了,后续一定会有业务方提出这样的需求。对于这个规则,一种规则不够我们用了,我要同时查好几种规则。 不知道我说明白了没。也就是说,根据一个 key 甚至多个key 查找同时满足多种规则的文件,输出对应 List 。
- 这个时候 ENMU 就不合适了,要请出 NS_OPTIONS 这尊大神。
typedef NS_OPTIONS(NSUInteger, FileSearchRules) { FileSearchRulesFileNameBegin = 1 << 0, FileSearchRulesFileNameEnd = 1 << 1, FileSearchRulesExtension = 1 << 2, };
在这样的需求下,我就只能想到使用正则表达式了,首先根据规则编写正则,拿到所有文件名的 List ,再根据正则去匹配出最后的 List 输出。
或者有什么更好的实现方式,还请评论我。
-
结构设计
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 怎么去实现,扩展性以及可读性等等。都需要细细的去思考。
对于框架搭建,常见的设计模式还是要了然的。至于架构那几点,单一职责什么的,也是要知道的。