GKS_SamaraА нельзя в наследнике добавить предусловий через and. Только через or.
Да, внутри можно assert'ов поставить, но вот require - нельзя.
"Нельзя" - Вы здесь имеете в виду "нельзя физически" или "нельзя концептуально"? Впрочем, я не согласен ни с тем, ни с другим.

GKS_SamaraЧестно говоря, после такого заявления хочется завершить разговор- настолько оно бредово. Полное знание возможных exception'ов метода- то, чего _очень_ мне не хватает в других языках.
Во-первых, в яве полного знания нет. Во-вторых же, это скорее всего пройдет, как только Вам надоест, поменяв одну маленькую функцию, носиться исправлять throws во всех функциях, которые ее прямо или косвенно используют.

GKS_SamaraПоскольку рассматривание implementation части чужого unit'а- занятие для мазохиста,
Тогда давайте обойдемся без обсуждения явы - поскольку в ней implementation намертво увязан с interface, и как следствие, "не просматривать его" невозможно.

GKS_Samaraто надо добавить еще и interface часть:
Это, кстати, совершенно необязательно.

GKS_Samara
Не надо портить код. Интерфейсная часть к этому имеет вид


GKS_SamaraНеобходимость этого комментария и устраняет контракт.
Необходимости в этом комментарии нет, это мусор.

GKS_SamaraЭто кроме _синтаксических_ требований к наследнику- только ослаблять предусловия и только усиливать постусловия.
Это мертворожденное требование, на практике - бессмысленное и нереальное.

GKS_SamaraНельзя физически- компилятор пошлет.
Значит, в таком вот "нарушающем" потомке просто не будут писать requires, сделают проверку другими способами.

GKS_SamaraИначе нельзя. А то я читаю спецификацию класса, вижу требование к параметру "value>=0", вызываю и получаю по шее. Как? А оказывается мне подсунули его потомка в 10 колене и он хочет еще и "value!=1".
Сугубо теоретически - согласен, нельзя. Очень красивая, стройная теория, с одним большим минусом - она не дает ответа на вопрос "как же писать программы, отвечающие этому требованию".

Как любил говорить мой научный руководитель - "Математик делает то, что можно, так, как нужно. Программист же делает то, что нужно, так, как можно". Вышеизложенное требование - сугубо математическое в смысле этого высказывания.

GKS_SamaraОно достаточно полное. Знание о крахе виртуальной машины или ошибке четности памяти мне не надо- все одно надо будет убить себя об стену :)
Существует полно ситуаций, когда и убивать себя незачем, но и "знания" нет. Я обычно привожу в пример обновление информации в статусбаре. Если код, обновляющий статусбар по таймеру, начнет падать по какой-либо дурацкой причине - надо всего лишь отключить это обновление и убрать статусбар, это будет лучшей реакцией в 99% случаев. Но программист, привыкший полагаться на throws как на источник информации о возможных исключениях, об этом заведомо никогда не подумает, не имеет права. А потому, в зависимости от деталей реализации, такой подход приведет к следующим вариантам:

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

GKS_SamaraЕсли у маленькой функции вдруг появилось еще одно слабое место или предусловие, то все одно всех клиентов надо пересматривать, что бы там компилятор не позволял.
Если не понимать смысла концепции исключений, то безусловно, надо. Есть такой очень забавный эффект, наблюдаю не в первый раз, я бы его назвал оптимизмом новичка. Выглядит он примерно так:

- была некая неудобная технология, например, "коды завершения функций" и обработка ошибок на основании их анализа

- когда она всех достала, начали разрабатывать более продвинутые техники, в итоге приведшие к появлению исключений

- постепенно сложилось поколение программистов, не работавших с кодами возврата

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

Это Ваше "надо пересматривать" противоречит принципу модульности. Нормальная ситуация: ошибку регистрирует один модуль, вызывается он из другого модуля, а обрабатываться ошибка будет в третьем модуле. И другой модуль ни фига не должен знать об этой ошибке; его задача всего лишь - не мешать ее нормальной обработке. Требуя "пересматривать", Вы предлагаете завязать хорошие и правильные модули в один дурацкий неразрывный клубок, в этакий "один большой пельмень" (который получается, если пачке пельменей дали подтаять).

GKS_SamaraУ Явы надо читать не java, а JavaDoc'и.
Это нереально. Мало-мальски серьезный javadoc не имеет ни шанса соответствовать реальному положению дел; этого можно добиться только либо в тривиальных искусственных случаях, а-ля примеры в книжках, либо есть "все бросить" и поставить основной целью не выпуск продукта, а поддержку javadoc-ов.

Для иллюстрации проще всего сослаться на javadoc-и по JDK. Вот уж, казалось бы, флагман, которым пользуются миллионы людей, который поддерживается большой командой, который является выставочным примером, показателем технологии. Однако, если работать на яве - регулярно приходится лезть в исходники и регулярно обнаруживается даже не неполнота, а явные ошибки javadoc-ов. Лично я - эдак полгода честно пытался пользоваться, после чего пришел к выводу, что это пустая трата времени. Если хочешь "узнать как надо делать" - надо смотреть tutorial, если хочешь "узнать, что за хрень творится" - надо сразу лезть в исходники.

GKS_SamaraХотя подход Oberon/eiffel (в терминах delphi- создание interface по implementaton автоматически) мне нравится больше.
Автоматизация кодогенерации показывает недостатки языка. Такие вещи лучше делать на уровне IDE (скажем, показать заголовок класса без реализации, а лучше и без приватных частей и с отключаемым отображением protected). Хотя еще лучше - иметь язык и технологию, которые позволят видеть и редактировать "то, что нужно, так, как нужно" хоть в нотепаде.

GKS_SamaraНу или бы подход Ada/Modula2 с раздельными частями, когда package body можно не видеть вообще.
По опыту PL/SQL, все нормальные средства редактирования тем не менее дают возможность смотреть их вместе :)

В целом, меня вполне устраивает реализация в PL/SQL (которая взята из Ada), дельфовая пожалуй чуть удобнее (поскольку позволяет быстрый и простой переход между interface и implementation во-первых, и нет теоретического шанса на разъезжание версий interface и implementation).

GKS_SamaraЭто пойдет только для вырожденного случая замены стандартной функции, который нафиг не нужен.
Нет. Комментарий к функции должен давать короткую и четкую формулировку того, зачем эта функция нужна, остальное - мусор, мешающий читать код. Более подробно - можно писать в документации, отделенной от кода, хотя постепенно я все больше и больше убеждаюсь, что потребность в такой документации вызывается проблемами проектирования и кодирования.

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