Questions tagged «api-design»

我正在包装一个C ++ API，该API提供对C函数中的数据存储（Hazelcast）的访问，以便也可以从仅C代码中访问数据存储。 用于Map数据结构的Hazelcast C ++ API如下所示： auto map = hazelcastClient->client->getMap<int, string>(mapName); map.put(key, value); 它使用key和和的模板类型value。由于C中没有可用的模板，因此我考虑为该getMap<T, U>方法的每种特殊化创建包装函数。也就是说，对于每种C类型。虽然我知道有signed和unsignedC型的版本，我很好限制API仅支持int，double，float，char *为key和value。 所以我写了一个小脚本，可以自动生成所有组合。导出的函数如下所示： int Hazelcast_Map_put_int_string( Hazelcast_Client_t *hazelcastClient, const char *mapName, int key, char *value, char** errptr ); int Hazelcast_Map_put_int_int( Hazelcast_Client_t *hazelcastClient, const char *mapName, int key, int value, char** errptr ); ... 生成功能get，set，contains与所有可能的组合key和value种类增加了代码的数量相当多，虽然我觉得生成的代码是一个好主意，它具有创造某种代码生成的基础设施增加了额外的复杂性。 我可以想象的另一个想法是C中的一个泛型函数，如下所示： int …

9 c++  c  api-design 

假设您有某种数据结构，该数据结构保留在某种数据库中。为简单起见，我们将此数据结构称为Person。现在，您要负责设计CRUD API，该API允许其他应用程序创建，读取，更新和删除Person。为简单起见，让我们假定通过某种Web服务访问此API。 对于CRUD的C，R和D部分，设计很简单。我将使用类似C＃的功能符号-实现可以是SOAP，REST / JSON或其他方式： class Person { string Name; DateTime? DateOfBirth; ... } Identifier CreatePerson(Person); Person GetPerson(Identifier); void DeletePerson(Identifier); 那更新呢？自然要做的是 void UpdatePerson(Identifier, Person); 但你会如何指定哪些领域Person要更新？ 我可以提出的解决方案： 您始终可以要求通过一个完整的“人员”，即客户将执行以下操作来更新出生日期： p = GetPerson(id); p.DateOfBirth = ...; UpdatePerson(id, p); 但是，这将需要某种事务上的一致性或在Get和Update之间锁定；否则，您可能会覆盖其他客户端并行进行的其他更改。这会使API更加复杂。此外，由于下面的伪代码（假设客户端语言支持JSON），因此容易出错。 UpdatePerson(id, { "DateOfBirth": "2015-01-01" }); - 看起来正确-不仅会更改DateOfBirth，而且会将所有其他字段重置为null。 您可以忽略所有的字段null。但是，您将如何在不更改 DateOfBirth和有意将其更改为null之间做出区别？ 将签名更改为void UpdatePerson(Identifier, Person, ListOfFieldNamesToUpdate)。 将签名更改为void …

9 design  api  web-services  api-design  crud 

通常，事件侦听器不应超出注册它们的对象的寿命。 这是否意味着事件侦听器默认情况下应由弱引用持有（由对象侦听器存储在弱集合中进行注册）？ 是否存在有效的情况，使听众的生命力超越其创造者？ 又或者像这样的情况是一个错误，不应允许？

9 api-design  event 

假设您有一个由API库支持的大型项目。该项目还附带了一个公共API，供最终用户使用。 有时您需要更改支持项目的API库。例如，您需要添加需要更改API的功能，新方法，或者需要更改传入或传自API的对象之一或这些对象之一的格式。 假设您还在公共API中使用这些对象，那么公共对象也会在您每次执行此操作时发生更改，这是不希望的，因为您的客户端可能依赖于API对象保持相同的解析代码才能正常工作。（咳嗽C ++ WSDL客户端...） 因此，一种潜在的解决方案是对API进行版本控制。但是，当我们说“版本” API时，听起来这还必须意味着对API对象进行版本控制以及为每个更改的方法签名提供重复的方法调用。因此，对于每个版本的api，我都会有一个普通的旧clr对象，这似乎也不可取。即使执行此操作，我也肯定不会从头开始构建每个对象，因为这将导致大量重复代码。相反，该API可能会扩展我们用于基础API的私有对象，但是随后遇到了同样的问题，因为如果不应该在公共API中使用附加属性，这些属性也将可用。 那么，这种情况通常适用于什么理智呢？我知道许多公共服务，例如Windows的Git都维护一个版本控制的API，但是我在构想一个支持该功能的体系结构而没有大量覆盖各种版本控制方法和输入/输出对象的重复代码时遇到了麻烦。 我知道，比如语义版本的尝试过程中把一些理智的时候应该发生的公共API休息。问题在于，如果对象之间的距离不远，似乎很多或大多数更改都需要破坏公共API，但是我发现没有重复代码的好方法。

9 versioning  api-design