本文探讨了API设计中的权衡原则，包括原理与删除原则的取舍、正确性与易用性的平衡，避免过度追求性能而违背设计原则，并强调了兼容性的全面考虑。同时分享了在功能扩展中采用的方法多态与属性的优缺点，指出选择最适合的方案的重要性。通过对比方法和属性的使用，揭示了业务需求和代码简洁性之间的权衡。
续接上篇，今晚又看了看大牛的书，再结合过往工作，总结如下：
1、弃用原理与删除原则做权衡。
2、正确性与易用性的把握。
3、不能因为过度的追求性能提升而违背API的设计原则。
4、兼容性不仅仅是表象的。正确的、异常的都是兼容上需要考虑的，举例上个版本里有方法返回异常类，但是当前版本没有了，从某种程度上也带来了不兼容性。
5、API可以对称再好不过，但也不是一定恪守的。老话：见名知意，学会用代码表达，就像我们平时用母语与人交流那样。
用自己今晚加班导致自己总结的不好，说出来让自己都不相信。结合前几天的工作，说一说功能扩展上我常用的两个方法，方法多态与属性。一开始我自己喜欢用方法，结果就定义了N多同名方法，还用了很多作废Attribute，最可怕的是方法调用时给使用者带来越久越复杂的特性。用属性的方式实现功能扩展，可以让方法的调用保持一个较简单的方式，但是用着用着推广着推广者，发现使用者经常因为遗漏导致很多问题的产生。从这两个方法的使用折射了一个很普通的问题，凡事没有最优，只能尽可能的找到最合适的，方法复杂性可以通过对象参数来降低复杂性；属性的方式实现扩展，属性必须有合情合理的默认值，不建议使用类型的默认值，要从业务上多考虑。
最后说句心里话，点灯熬夜让自己感觉有存在感,越在北京飘着越感觉没有存在感，是不是因为自己点灯熬夜越来越少了?
扫一扫
364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
