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

Красота такого подхода легко демонстрируется на простом примере. Допустим, я хочу сделать компонент "как JLabel", но в дополнение к его функционалу обладающий еще какой-нибудь мелкой деталью. Например, приобретающий красный цвет, если надпись в нем содержит грамматическую ошибку. Естественное решение - наследоваться от JLabel. А какой у нас JLabel - абстрактный али финальный? Если второе - наше желание идет лесом, и мы начинаем извращаться. Если первое - значит, страдают все, кому нужен JLabel без дополнений и кто в результате не может просто так взять и инстанциировать его.

Таким образом с практической точки зрения это сведется вот к чему: выпуская любую библиотеку классов, я буду вынужден продублировать каждый публичный ее класс. Если раньше были, допустим, JLabel, JButton, JText - то теперь я должен буду сделать JLabel, JFinalLabel, JButton, JFinalButton, JText, JFinalText. В результате чего всем участникам процесса станет намного, намного удобнее.

NotGonnaGetUsи думаю: а всякое ли "естественное решение" небезобразно? :)
Как Вам сказать... думаю, Вы уже пару лет как в курсе моего мнения относительно красоты явовских решений; имхо авторы набросились на специализацию классов примерно так же, как неумный человек - на поклонение Господу. Это вызывает вполне понятные последствия и у кода, опирающегося на эти классы.

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

NotGonnaGetUsДоработка напильником не такая тривиальная задача как кажется.
Не надо уводить разговор в сторону, давайте сосредоточимся на теме. Предлагаю простой и незамысловатый выбор:

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

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

GKS_SamaraЭто да. Но вот к чему это приводит?
К нормальной работе.

GKS_SamaraЗаплатки- тоже распространенная практика, но не от хорошей жизни.
Хм. Ваша фраза показывает одну мою ошибку: я не уточнил, что под "практическим программированием" имел в виду то, что делают вменяемые и профессиональные люди. Заплатки я к этой категории не отношу.

GKS_SamaraС чего все началось- с обсуждения одной небольшой системой управления предприятием. Где наследование формочек (delphi) и панелек зашло так далеко, что при правке чего-либо одного приводит к фантастическим эффектам в другом месте. Т.е. наследники заложились на цвет кнопочки вооооон там, а тут его поменяли. Цвет- это так, для ясности :)
Безусловно, любую иерархию классов можно спроектировать неудачно; вполне возможно, получилось что-то вроде того, что ранее привел NotGonnaGetUs . Однако, не наследование тому виной, и указанный принцип от этого не спасет. Показать это проще всего тривиальным примером: допустим, мы взяли описанную Вами "плохую" структуру, взяли те классы, которые одновременно инстанциируются и имеют наследников и привели их в соответствие этому принципу: отпочковали от них тривиальных наследников и стали инстанциировать именно их. И что, программе от того станет лучше?

Визуальное наследование - отдельная интересная тема, но и там действует общий принцип. Формально то, что Вы сказали, можно сформулировать так:

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

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

GKS_SamaraКонтракты увы, ни в delphi ни в java не внедряются,
"Увы" здесь имхо лишнее.

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

GKS_SamaraНо явно написанный в заголовке с проверкой при выполнении (require) или при тестах (ensure) - все же лучше, imho.
Как Вам сказать.... это детские игры. Тут есть пара моментов.

1. Ничего глобального таким образом не опишешь. Попробуйте сформулировать контракт, который например для дельфы скажет: "перед вызовом деструктора формы обязательно должно быть вызвано событие OnClose". То, что метод X должен быть вызван с параметром Y, значение которого не больше Z - чепуха, легко вылавливаемая и легко контролируемая кучей способов. Основные проблемы - архитектурные, а как раз на них никакого вменяемого формального контракта не навесишь.

2. Наиболее интересные проверки - промежуточные, а не входные-выходные. "Метод вызван с неправильным параметром" - гораздо более приятная ошибка, нежели, например, "sql-запрос в середине логической цепочки вернул ноль строк".

GKS_SamaraОчевидно, что OnClose меняет состояние объекта.
Совершенно не очевидно. Если, конечно, не делать этого специально.

GKS_SamaraВот это и задается требованием.
То есть мы начинаем ломать программу под попытку ее проверить. Это порочная практика.

GKS_SamaraВынести запрос в отдельный метод, возвращающий набор строк результата
То же самое. Представьте себе, что гаечный ключ, который Вы купили, для применения к автомобилю требует предварительно выломать из него задние сидения или, допустим, перекрасить его в зеленый цвет. Нужен Вам такой инструмент?

GKS_SamaraА что ж он делает тогда?

Как Вы предлагаете в деструкторе проверить, вызывался этот код или нет?

GKS_SamaraКонтракт- не панацея, это удобный инструмент для некоторых случаев.
И его отсутствие- привычно, но неудобно.
Во-первых, кто Вам сказал, что они отсутствуют? Отсутствует максимум - ненужная и вредная поддержка этого инструмента со стороны языка. Точно так же древние языки поддерживали средства работы с файлами, которые сейчас перенесены в куда более подходящее место.

GKS_SamaraВедь в любой java-программе встречаются вещи типа
"а вот этот параметр должен быть таким-то"
"а вот этот exception кидается если мы вот это нарушили".
И? Контракты не дают здесь ничего нового. Есть исключения, есть assert-ы, есть трассировка некритических ошибок и тревожных признаков.

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

GKS_SamaraА как мне просто записать, что "вот это должно выполнятся, иначе по башке получишь"?
Assert - для того, для чего подходит. Ну или любые аналогичные средства. Но архитектурных проблем это не исправит.

GKS_SamaraЧтобы наследники по-умолчанию проверяли, но можно было явно отключить?
Полиморфизм. Тут важно не только это; важно то, что если наследник вызывает inherited - должны провериться контракты предка. Как раз это и будет.

GKS_SamaraИ чтобы при смене менялось все автоматом, а не править в двух местах?
Не понял вопроса. Вернее, не понял, какую ситуацию Вы подразумеваете.

GKS_SamaraА assert'ы в контрактном программировании тоже есть.
Есть. Как вынужденная мера. Контрактное программирование - это по сути бесполезная надстройка над придуманным не помню кем простым и маленьким макросом ASSERT. Какой-то смысл у нее появляется с точки зрения автоматической верификации кода, впрочем....

GKS_SamaraНо это не устраняет возможность появления такой ошибки, как ужесточение входного требования.
А что же устраняет возможность появления такой ошибки? Разве что редактор, который в момент написания кода высветит ошибку и не даст сохранить такой текст...

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

GKS_SamaraТут приходится дублировать и сам exception,
Это персональная дурость явы, которую можно и нужно записать в минусы языку, но никак не концептуальный недостаток "всех языков". Лично я предпочитаю следующую точку зрения: в Delphi подпрограммы определяются с обязательным использованием ключевого слова procedure, в Яве подпрограммы определяются с обязательным использованием ключевых слов thows Throwable.

GKS_Samara и текст.
Где? Не вижу в примере дублирования текста. Или другую явовскую дурость под названием javadoc также относим к программе?

GKS_SamaraА теперь рассмотрим тот же пример, как будто в java есть контракт
....
Дублирования кода _нет_.
Не вижу, какое именно дублирование кода устранено. Ткните, пожалуйста, пальцем. А лучше - давайте так: я пишу тот же самый пример -


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

GKS_SamaraСущественный плюс, на мой взгляд. Учитывая то, что ООП-то было задумано для устранения дублирования кода
Это, простите, отдельная глупость.

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