[design decision] common case vs. rare case
很多时候,针对大部分情况,你能有一个完美的设计,但是当一些边边角角的情况被考虑进来之后,这个“完美”的设计就不在完美,甚至无法工作,这个时候,你其实有两个选择:
- 重新设计,找到一个对这些rare case也适用的设计
- 保持原有设计,但找到一个让这些rare case能够正常工作的work around
第一种选择的是牺牲了整理设计,妥协后的方案可能能工作,但非常的丑陋; 而第二种选择则是牺牲了部分用户,但保证了整体设计的优美。
选择的关键在于这些rare case到底有多rare,以及这些rare case有多重要。 我的观点是:如果可以,请尽量选择第一种方案。
我这里有个例子:
一般对于C++工程,我们需要在多个平台上编译,并且产生多份binary - 我们现在要做的一个工作是:是对于每个C++项目,同时产生一份针对这个项目的dependency closure(直接依赖+间接依赖),因为不同平台下依赖关系可能不同,该文件和binary一样也是platform-specific的,最好是和binary放在一起,比如:
platform-specific
win32
binary
dependency
win64
binary
dependency
linux32
binary
dependency
linux64
binary
dependency
恩,很完美。
但是,有一个例外,就是header-only的C++项目,它是不会产生binary的,所以也不会有platform-specific这个volume - 怎么办?
- 把dependency这个文件放到其他地方去,从而不会影响到header-only的项目。
- 保持原有设计,但是对于header-only的项目,请你额外创建一个platform-specific的volume吧,谢谢
考虑到把dependency文件放到其他地方都不太合适,而且header-only的C++项目并不多,第二个选择明显要好一些。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· [AI/GPT/综述] AI Agent的设计模式综述
2010-12-10 如果MFC的消息映射表需要排序...