4

虽然我有一些开发经验，但我还没有设计 API 或更大规模的项目。

我的一般过程通常涉及以下内容：

  1. 提出一些建议的设计。
  2. 列出他们的优点和缺点。
  3. 给定一组场景（X 更改、添加的新功能等）——设计如何对其做出反应。

这是我自己的“风格”；我想知道在哪里可以阅读更多关于做这些事情的正式流程和方法的信息？（在线、书籍等）

4

3 回答 3

4

框架设计指南是一本很好的书。此外，.NET Framework Standard Library Annotated Reference是另一本很棒的书。

以下是我遵循的一些原则：

  • 少即是多：去掉功能可以让用户更快地提高工作效率，因为要学习的概念更少。少即是多导致...
  • 进入门槛低：用户希望快速学习新框架/API 的基础知识。他们想通过实验而不是通过阅读文档来学习。大多数人只有在特别有趣或超出基本场景的情况下才会花时间完全理解一个功能
  • 类型名称应该是名词短语：它们代表系统的实体。名称也应该代表场景。最容易识别的名称应该用于最常用的类型，即使更适合不太常用的类型。FDG 书中给出的示例是Printer和PrintQueue，这Printer将是最容易识别但PrintQueue更能描述概念的地方。这导致...
  • 专注于抽象而不是概念。使用的示例是File.NET 中的基类和派生的NtfsFile. 大多数开发人员会自动尝试实例化 a File，结果发现它是abstract. 像这样的继承在实现中效果很好，但是......
  • 框架设计与 OO 设计不同：例如，在 .NET 中存在对象层次结构；Stream, StreamReader, TextReader,StringReader和FileStream. 有一个清晰的层次结构，但是在考虑一个场景时会让人感到困惑，例如读取文件。
  • 程序集代表打包和部署边界。最佳实践（无论如何在 .NET 中）通常说名称空间应该匹配程序集，例如MyCompany.MyTechnology.dll具有名称空间MyCompany.MyTechnology和其他名称空间，例如MyCompany.MyTechnology.MyFeature. 这不一定适用于框架/API；这里的程序集应该代表开发人员的逻辑分组，并考虑到性能（加载时间）、易于部署和易于版本控制。这是一种平衡行为；当只有 1 个程序集时，没有人喜欢引用超过 1 个程序集。如果程序集太大并且逻辑分组很差，没有人喜欢依赖他们不需要的东西（例如，即使您在 API 中使用的功能与 ADFS 无关，也必须额外依赖 ADFS ）。
于 2012-05-15T17:47:13.030 回答
3

我喜欢 The Clean Coder 一书，以及 C# 中的敏捷原则、模式和实践，最后是 Robert C. Martin 编写的 Clean Code。我喜欢他的写作方式，我喜欢他的编码风格，它给了我很多思考和应用到我自己作为程序员的职业生涯的机会。你可以在亚马逊上以相当便宜的价格买到所有这些书。Robert C. Martin 也有自己的网站来处理这类事情。http://www.objectmentor.com/omTeam/martin_r.html这是在“关于我们的团队部分”中以他为特色的网站。在那里四处寻找，看看你是否找不到他的其他网站，以及他编写的一个名为 Fitnesse 的程序。

尽管您的风格对于业余爱好者倾向于在较大规模上进行的正常大小的项目看起来不错，但可能涉及更多步骤。你想写什么在线服务？我目前正在为 Zoho 编写另一个，但我一直忘记将我的代码从工作中导入到我的程序中。

于 2012-05-10T21:29:45.020 回答
1

我刚刚为我们工作中的一个项目编写了一个 API，我确实有几点意见。

方法论原则上很好，但请考虑您的要求。您是否会有多个开发人员来推进和维护 API，或者您主要负责开发？如果是前者，那么架构的结构化方法和流程将在未来发生（可怕但不可避免的）变化时带来好处。

如果是后者，那么您将拥有更大的灵活性。每个 API 都在尝试实现不同的东西，无论是插件框架，还是服务的“公共”入口点——我建议您收集一些需求并确定遵循其中一种方法是否会使您受益。

于 2012-05-11T07:15:20.950 回答