Сложности, юзабилити и читабельность FluentAPIs - образец: FluentMethodInvoker


new MethodExecuter()
    .ForAllInvocationsCheckCondition(!Context.WannaShutDown)
        .When(shouldRun).ThenInvoke(x => x.Methods(new Action[] { B.Process, A.Process }))
        .When(shouldRun).ThenInvoke(x => x.Method(B.Process).Repeat(100))
        .Invoke(x => x.Method(C.Process));

Я намеренно ничего не говорю о том, что этот API делает. Я показывал этот API моим товарищам по команде, и это им не нравится. Для них это не читается.

Что вы думаете об API? Какие советы у вас есть? Что вы думаете о complexitiy, удобство использования и читабельность API-интерфейсов, свободно и как добиться хорошего API?

Редактировать Почему я строю этот API?

Ну, у меня есть куча методов, которые вызываются синхронно, когда условие ложно. Условие применяется вызов метода foreach.

if (!Context.WannaShutDown) A.Process();
if (!Context.WannaShutDown) B.Process();
if (!Context.WannaShutDown) C.Process();
if (!Context.WannaShutDown) D.Process();
if (!Context.WannaShutDown) E.Process();
if (!Context.WannaShutDown) F.Process();
if (!Context.WannaShutDown)
{
   if (condition) 
   {
       for (int i = 0; i <= 100 i++)
       {
           Z.Process();
       }
   }
...

Мне не нравится такой код хрень. То, что я хотел сделать, это решить "проблему" только с классом, который отвечает за вызове методов. Я пытался построить API, который является максимально простым, но, похоже, мне не удалось.



325
3
задан 21 июня 2011 в 08:06 Источник Поделиться
Комментарии
2 ответа

Кирк Уолл делает некоторые отличные моменты в его комментарий, который мог бы быть ответ ИМХО.


Апис свободно не лучше ИПсО факто.

Вы совершенно правы в своем желании реструктурировать ваш приведенный пример кода в редактирование, но, возможно, стоило бы сначала изучить некоторые другие возможности, прежде чем решиться на использование плавного API.

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

Только с помощью данного кода образца (при условии IProcess интерфейс), вы могли бы уже улучшить его, написав что-то вроде этого:

Dictionary<IProcess, int> executeOperations = new Dictionary<IProcess, int>
{
{ A, 1 }, { B, 1 }, { C, 1 }, { D, 1 }, { E, 1 }, { F, 1 },
{ Z, 100 }
}

foreach ( var executeItem in executeOperations )
{
if ( !Context.WannaShutDown )
{
for ( int i = 0; i <= executeItem.Value; ++i )
{
executeItem.Key.Process();
}
}
}

Это не ясно, какие условия в вашем примере кода предполагается, или почему только Z проверить, но для демонстрационных целей я считаю, что приведенный выше пример показывает, что есть и другие способы рефакторинга кода без необходимости полагаться на свободно синтаксис. Можно заменить тип int значение в словаре структуру, содержащую дополнительные параметры.

Что сказал, Я верю вашим поставленным образцу еще слишком мал для того, чтобы точно сказать, является ли или не используя синтаксис свободно может быть оправдано.

1
ответ дан 22 июня 2011 в 05:06 Источник Поделиться

Свободно API в целом всегда заставляют меня вспомнить pooQuery. Плавные API (на мой взгляд), направлены на те же цели, что привело к созданию Кобола: чтобы быть читаемыми и "понятной" для не-программистов. Программисты, конечно, знаем, что это заблуждение. Трудность в программировании не понимая особенности синтаксиса данного языка программирования, но в разработке логических шагов, необходимых для реализации определенного алгоритма. Зная это, многословный, английском языках ("Апис свободно") не помогают, и, по сути, служат лишь для запутывания алгоритма.

0
ответ дан 21 июня 2011 в 08:06 Источник Поделиться