Api 如何编写好的非常有用的通用库？

我询问了微软.NET库及其源代码的复杂性。从我所阅读的内容来看，编写通用库和编写应用程序可能是两件不同的事情。在编写库时，您必须考虑客户，他们可能是所有人（假设我发布库供公众使用）

---

在学习编写图书馆时，什么样的实践、理论或技术是有用的？您在哪里学习编写类似.NET库中的代码？这看起来像是一种我不太了解的“黑色艺术”

我将开始更多地研究设计模式。您可能不会发现其中一些模式有多大用处，但随着您对库设计的深入，这些模式将变得更加适用。我还想买一份NDepend——一个伟大的代码度量工具，它可以帮助您更好地解耦。您可以使用.NET库作为示例，但就我个人而言，由于它们的复杂性，我认为它们不是很好的设计示例。另外，开始看一些开源项目，看看它们是如何分层和结构化的。

这是一个相当主观的问题，但这里有一个客观的答案。这本书（一定要拿到第二版）是一本关于如何编写有效类库的好书。内容非常好，经常有不同意见的注释发人深省。每家商店都应该有一本这本书

Krzysztof Cwalina的博客是一个很好的起点。他的书《框架设计指南：可重用.NET库的约定、习惯用法和模式》可能是.NET库设计最佳实践的权威著作

---

图书馆作者经常忽视的一条建议是将成本内部化。如果有些事情很难做，图书馆应该去做。我经常看到库的作者向API的消费者施加压力，而不是自己解决问题。取而代之的是，寻找最难的东西，并确保图书馆能做到，或者至少让它们变得非常简单。

你肯定需要观看Josh Bloch的演讲（1小时9米长）。他是Java大师，但库设计和面向对象是通用的。

我将转述Scott Meyers的话，我发现这是我得到的最好建议：

坚持最不令人惊讶的原则：努力提供操作符和函数具有自然语法和直观语义的类。保持与内置类型行为的一致性：当有疑问时，按照INT的方式执行

认识到任何人能做的事情，他们都会做。他们会抛出异常，他们会将对象分配给自己，他们会在给对象赋值之前使用对象，他们会给对象赋值，但从不使用，他们会给对象赋值，他们会给对象赋值，他们会给对象赋值，他们会给对象赋值，他们会给对象空值。一般来说，如果它要编译，就会有人来做。因此，使您的类易于正确使用，而难以错误使用。接受客户机会犯错误，并设计您的类，以便您能够防止、检测或纠正此类错误

努力实现可移植代码。编写可移植程序并不比编写不可移植程序困难多少，而且性能上的差异很少会显著到足以证明不可移植结构的合理性

即使是为定制硬件设计的程序也常常被移植，因为库存硬件通常在几年内达到同等的性能水平。编写可移植代码可以让您轻松切换平台，扩大客户群，并吹嘘支持开放系统。如果您在操作系统抽奖中下注错误，也可以更轻松地恢复

设计您的代码，以便在需要更改时，将影响本地化。尽可能地封装；使实现细节私有化

---

编辑：我刚刚注意到我几乎是重复的；对不起！但事实证明，我们正在链接布洛赫的不同演讲，即使主题完全相同。（cherouvim链接到2005年12月的一次演讲，我在2007年1月的一次演讲。）好吧，我将在这里留下这个答案——你最好同时观察这两个方面，看看他的信息和表达方式是如何演变的：）

---

FWIW，我想指出这篇Google技术演讲的作者，他是Java世界中一位非常受尊敬的人，他曾就API设计发表过演讲并撰写了大量文章。（哦，还设计了一些非常好的通用库，比如Java集合框架！）

Joshua Bloch，谷歌技术讲座，2007年1月24日：
“”（视频约1小时长）

你也可以在他的文章中读到许多相同的想法（但我还是建议你看演示！）

（看到你来自.NET方面，我希望你不要让他的Java背景太过妨碍：-）这在很大程度上并不是Java特有的。）

---

编辑：下面是Josh Bloch的另一篇文章，关于为什么编写库很难，为什么它仍然值得努力（规模经济）——这是对一个问题的回答，基本上是“它能有多难”。（这是关于Google Collections library的演示的一部分，它也完全值得一看，但更以Java为中心。）

第一条规则是将API设计与UI设计一样对待：收集有关用户如何真正使用UI/API的信息，他们觉得有什么帮助，以及他们遇到了什么阻碍。使用这些信息来改进设计。从能够忍受API搅动的用户开始，随着API的成熟逐渐稳定下来

---

我在这里写了一些关于API设计的笔记：

几个单独的要点：

NET Framework不是类库。这是一个框架。这是一套t