Должен ли контракт дублировать или делегировать?

Realist

Философский вопрос об идеале, к которому надо стремиться.
Для примера у меня есть две функции для подсчета количества рабочих дней в году и вообще на любом интервале).

  

int countBusinessDays(HolidayCalendar* calendar, Date* begin, Date* end)

{...}



int countBusinessDaysInYear(HolidayCalendar* calendar, year)

{

// assert(calendar);

return countBusinessDays(calendar, Date(1,1,year Date(1,1,year+1;

}

Вопросы про функцию countBusinessDaysInYear. Фишка в том, что параметр calendar непосредственно не используется, но это как бы деталь реализации. Насколько эта деталь должна быть видна снаружи?
— Должен ли контракт содержать информацию о том, как обрабатываются некорректные значения (calendar==NULL)?
— Должна ли функция countBusinessDaysInYear проверять корректность параметра calendar или полностью делегировать это в countBusinessDays?
— Должен ли контракт функции countBusinessDaysInYear говорить о том, что такое бизнес-день (по сути копирование контракта countBusinessDays или же должен отсылать к контракту самой countBusinessDays (по сути мы раскрываем реализацию)?
— Соответственно, что должны тестировать unit-тесты функции countBusinessDaysInYear? Они должны проверить, что год "включил" 31 декабря и 1 января (то есть делегирование реализовано верно); или же должны перепроверить и всю логику того, что такое бизнес-день (как учитывается короткое рабочее воскресенье из-за переноса праздников)?

Dasar

>Философский вопрос об идеале, к которому надо стремиться.
у функции countBusinessDayInYear - можно ввести два понятия контракта: "добавочный" и "полный".
"добавочный" контракт - это тот контракт, который добавляет непосредственно сама функция countBusinessDaysInYear (то, что добавляется в контракт непосредственно из тела функции)
"полный" контракт - это сумма "добавочного" контракта и "полных" контрактов функций: countBusinessDays и конструктора Date
функция добавляет две вещи:
одну смысловую - что такое год, как именно он выражается через дни.
одну "техническую" - year + 1. соответственно - если конструктор Date принимал year до MaxYear, то функция CBDIY может принимать только до MaxYear-1
в идеале:
техническая вещь - должна быть отражена в контракте
смысловая вещь - должна быть специфицирована и протестирована
"полный" контракт функции должен строиться автоматически на основе "добавочных".

Dasar

и ответы на вопросы
>— Должен ли контракт содержать информацию о том, как обрабатываются некорректные значения (calendar==NULL)?
нет, это должно выводится автоматически при выведении контракта
>— Должна ли функция countBusinessDaysInYear проверять корректность параметра calendar или полностью делегировать это в countBusinessDays?
не должна, т.к. сделать это лучше, чем функция CBD - она все равно не сможет, но делая это сама - она может это делать неправильно.
>— Должен ли контракт функции countBusinessDaysInYear говорить о том, что такое бизнес-день (по сути копирование контракта countBusinessDays или же должен отсылать к контракту самой countBusinessDays (по сути мы раскрываем реализацию)?
для простого использования - должен автоматически выстраиваться полный контракт, которые копирует контракт CBD,
для специфического использования - должна быть возможность узнать из контракта, что CBDIY есть простой фасад над CBD (если в идеале тесты строятся автоматически, то как раз эта информация бы пригодилась)
>— Соответственно, что должны тестировать unit-тесты функции countBusinessDaysInYear? Они должны проверить, что год "включил" 31 декабря и 1 января (то есть делегирование реализовано верно); или же должны перепроверить и всю логику того, что такое бизнес-день (как учитывается короткое рабочее воскресенье из-за переноса праздников)?
в первую очередь, тесты должны проверять, что год сформирован правильно (что правильно учтены 31 и 1)
плюс один-два общих теста на то, что интеграция выполнена правильно (т.е. фактически что мы правильно вызвали CBD и Date-ы)

Realist

Слушай, я, наверное, отсталый, но под контрактом я понимал текстовое описание того, что делает функция. Комментарий в .h файле (да, я пишу на C++). А тут какой-то вывод автоматический... Это в мире Java так, как ты говоришь, я правильно угадал?

Dasar

ты меня про идеал спрашивал? или про что?
зы
я вообще удивлен, что на C++ кто-то знает про слово контракт

rosali

> по сути мы раскрываем реализацию
нет ничего страшного в раскрывании реализации, если эту реализацию никогда не собираешься менять. никогда не говори никогда, это всё понятно, но конкретно в этом примере шансы на смену реализации нулевые.

Dasar

>Слушай, я, наверное, отсталый, но под контрактом я понимал текстовое описание того, что делает функция.
тогда что-то типа:
CBDIY - это надстройка(фасад) над функцией CBD.
год - берется календарный с 1 января по 31 декабря.

pitrik2

Это в мире Java так, как ты говоришь, я правильно угадал

эээ
под джавой тут же тоже javadoc имеется ввиду
в javadoc есть например конструкция @see, которая указывает что часть доки к этому методу надо смотреть в доке к другому методу
ну в с++ ты же юзаешь какойнить фреймворк документации? docbook или тому подобное?
что там есть подобного?

Оставить комментарий