Имеет ли смысл этот DSL для моего контейнера DI?

Question

Поскольку я не являюсь носителем английского языка, я лучше не создам DSL, который звучит неудобно для других. Контейнер DI возник из проекта, и я изолирую его как отдельный проект. Я вижу другие контейнеры DI/IOC, используя синтаксис, например bind(interface).to(class). Я хотел бы использовать следующее (псевдо-код):

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

сделать эти имеют смысл или это звучит как строительство от кого-то, кто не понимает некоторые тонкости семантики этих слов?

Answer 1

Я думаю, что ваш подход имеет такой же смысл, как и примеры из других проектов DI.

Несколько замечаний:

1. bind/to короче, чем писать given/thenUse. Это не проблема сама по себе, но если вы можете достичь того же значения с более короткими именами, нет оснований использовать более длинные (в приведенных примерах они оба читаются одинаково)

2. Если есть установленный шаблон имени для одного и того же использования, тогда жизнь будет проще (например, ухватить концепцию/значение) для пользователей, которые знают, что установленный шаблон подходит к вашей реализации, что принесет пользу.

   Если вы используете «преобразование» пользователей других подобных библиотек/инструментов в ваш, использование соглашения об именах smae снижает барьер входа для этих пользователей.

   Если ваше воплощение концептуально отличается, то некоторые способы, однако, было бы лучше использовать разные имена, чтобы подчеркнуть разницу и уменьшить когнитивный диссонанс (между тем, что ожидается и что происходит).

   Если вы думаете (один из), то другие шаблоны именования имеют недостаток в них, который создает когнитивный диссонанс (между тем, что подразумевается под именем и тем, что он на самом деле делает), заменив его лучшей схемой именования, может означать больше последователей.

3. Хотя given(class).inject(param).inMethod(method) хорошо читается на английском языке, имеет порядок объектов, которые могут быть нелогичными для кого-то (класса/паров/метода, в отличие от класса/метода/паров, что естественный порядок для ОО-языков: Class.method(param);) ; рассмотреть: