我的DI容器的DSL是否有意义?

时间:2012-05-19 17:46:19

标签: api inversion-of-control usability dsl fluent-interface

由于我不是母语为英语的人,我最好确保不要创建一个对其他人来说听起来很尴尬的DSL。一个DI容器出现在一个项目中,我把它隔离为一个单独的项目。我看到其他DI / IOC容器使用bind(interface).to(class)之类的语法。我会使用以下(伪代码):

given(interface).thenUse(class)
given(class).constructWith(id=5)
given(class).inject(observer).inMethod(addObserver)

这些是否有意义,或者听起来像是一个没有掌握这些词语的某些更精细语义的人的构造?

1 个答案:

答案 0 :(得分:2)

我认为你的方法与其他DI项目的例子一样有意义。

很少注意到:

  1. bind / to的撰写时间比given / thenUse短。这本身并不是问题,但如果你可以用较短的名字达到相同的含义,那么没有太多理由使用较长的名称(在给定的例子中它们都读取相同的内容)

  2. 如果对于相同的用途存在已建立的名称模式,那么对于知道已实现的模式的用户来说,生活将更容易(例如掌握概念/含义),这将是一个好处。

    如果您正在“转换”其他类似库/工具的用户之后,使用smae命名约定会降低这些用户的进入门槛。

    如果你的实施在概念上有所不同,那么,使用不同的名称强调差异并减少认知失调(在预期和发生的事情之间)可能会更好。

    如果您认为(其中一个)其他命名模式中存在一个缺陷,会产生认知失调(在名称暗示的内容与实际内容之间),用更好的命名方案替换它可能意味着更多的追随者。

  3. 虽然given(class).inject(param).inMethod(method)在英语中读得很好,但它有一个对象的顺序可能对某人违反直觉(类/ param /方法而不是class / method / param,这是自然顺序OO语言:Class.method(param););考虑:given(class).and(method).useParam(param)