类型分离（API设计）

Question

假设您为某个库设计了一个API。

您希望在API中公开某些数据类型（例如Person）（例如getAllPeople()）。

考虑以下目标：

• 可以轻松地将成员添加到Person（可扩展）
• 不要在库的客户端和您的实现（耦合）
之间引入依赖关系
• Person可能包含对库客户端不感兴趣的内部状态信息

你会怎么做？

1. 在库标头/ API包中定义Person;同时拥有库的客户端和实现依赖于它（高耦合;非常容易扩展）
2. 在API /标头中定义Person;在库实现中定义PersonModel extends Person（易于扩展;仍然有一些耦合）
3. 在impl中定义PersonModel;在API中定义Person extends PersonModel（糟糕的依赖关系）
4. 在impl中定义PersonModel;在API中定义Person并在需要时复制内容（难以扩展;无耦合）
5. 其他什么？

Answer 1

事实上，Person是API的一部分。库用户有责任选择如何在其体系结构的上下文中解耦API。你不应该强加它。

如果用户不想使用您的Person对象，他必须封装/复制您的对象。

当然，您可以将Person设计为可扩展的，但无论如何它都是API的一部分。该API的用户与其耦合。他必须选择何时何地需要与之分离以及如何去做。如果Person设计得很好，他可能只是到处使用它。如果设计不当或不易使用/扩展，那么他将复制有趣的部分并重新设计。

设计API时，“Person”类型的对象应该是一个接口，例如用户不应该有权访问该实现。如果person是API服务的输入，则任何实现都应该有效（Liskov原则）。如果Person是输出参数，则用户应该获得引用，并且任何底层内部实现都不会与客户端代码耦合。处理对象构建时很难，但使用*工厂设计模式，您甚至可以管理它。如果客户端代码没有可见的具体实现，那么您有一个很好的API： - ）