edges7тем не менее раньше оставались кое-какие вопросы, ответы на которые нашел при изучении Java.
Хм. У меня при изучении Java осталось исключительно изумление по поводу неоправданных ограничений.

edges7Но тем не менее, сама концепция ООП полностью утряслась в голове только после изучения Java.
Хм. Как же она могла полностью утрястись при отсутствии множественного наследования? Это не концепция, это, извиняюсь, фигня.

Кстати, можно пример-другой утрясшихся вопросов, дабы как-то понять?

zloy denЕсли я не ошибаюсь, то это достаточно спорная технология?
Спорная или нет - но существенная часть концепции. Поэтому "полностью" концепция уложиться ну никак не может. А учитывая, что ООП в Java максимально обрезанное, как нигде более, "полностью" меня зацепило.

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

edges7На тот момент, можно сказать, у меня была вообще полная каша по поводу ООП. И тогда это было лучшее, на мой взгляд, что я нашел по ООП. Прочитал - все разложил по полочкам.
Ну скажем так, судя по этой формулировке, язык собственно не повлиял, вопрос только в удачно попавшейся литературе.

edges7Что касается отсутствия множественного наследования. Но ведь это характерно для Java, а не для всех языков.
Дык я просто к тому, что "изучив ООП по-явовски" даже в дельфе полноценно работать нельзя. Потому как в дельфе оно шире. И поэтому "концепцию полностью" выглядит.. самонадеянно :)

maytonОбиделся что downcasts не всегда прокатывают?
Да нет. "Обиделся" я пожалуй что один раз, когда идиотский компилятор ухитрился из-за бредовой реализации инициализации грохнуть мне уже сконструированный объект.

edges7На мой взгляд, в литературе по Delphi не особо сильно уделяется внимание концепции ООП, как таковой
На мой взгляд, внимание "концепции ООП как таковой" должно уделяться в литературе по ООП. В литературе по языку нужно говорить об особенностях реализации ООП-механизмов в языке. Смешивание тем из разных доменов - отвратительная привычка, приводящая к каше в голове у обучаемых. Они уже не понимают "откуда растут ноги" у тех или иных тонкостей, они не понимают, что концептуально, что - детали реализации, а что - глупость, которую надо исправлять. Они способны только заучить книгу аки библию и бездумно сыпать цитатами из нее, не умея даже их обосновать - наподобие прозвучавшего здесь "- зло".

Гыподробнее можно?
Примерно следующая ситуация (прошу прощения за возможные синтаксические ошибки, таки не один год как бросил это дело):


Версию явы не помню, не то 1.3, не то 1.4. Работало это чудо так: делается new B(), в нем super(), вызывается doSomething(), создается someList, завершается A(), и непосредственно перед возвратом в B() выполняется someList = null. Орднунг юбер аллес, Гитлер капут, маразм форева.

ГыИ этому есть обоснование
Любопытно было бы услышать. Правда, почти уверен, что оценю иначе.

ГыЕсли написать так (а это то же самое) было бы понятнее?
Понятно оно и так. Просто это концептуальная глупость.

ГыИ потом зачем инициализировать null'ом поле если оно и так null?
После этого и отказался от этой привычки. Хотя инициализировать - аккуратнее.

edges7Т.е. в данном случае параллельно изучаются и сам язык и применение ООП и в какой степени конструирование программ в стиле ООП. Т.е. наблюдается несколько другой подход.
Угу, именно так. Наблюдается подход "каша". Итогом его становится прорва кодеров, кое-как заучивших, но мало что понимающих. Впрочем, объективности ради, по Delphi хороших книг тоже мало, а в большинстве наблюдается ровно такая же каша из языка, IDE и VCL. Вообще, у меня есть впечатление, что немногочисленные хорошие специалисты сейчас получаются не благодаря первым книгам, которые читали, а скорее вопреки им.

maytonЯ надеюсь, что это был единичный случай, который не в состоянии изменить взгляды на концепцию.
На какую именно концепцию? На ООП? Мое отношение к ней сформировалось лет за семь до появления Явы. На "ООП в Яве"? Мм... мои взгляды, если коротко, сводятся к точке зрения "авторы этой реализации думали задницей", и этот случай действительно не изменил этих взглядов.

ГыЧтобы гарантированность, что в блоке инициализации потомка будет корректно проинициализированная унаследованная часть.
Как я и говорил, фигня это, а не обоснование. "Гарантировать" в данном случае можно и нужно без подобных хреней.

ГыНапример чтобы проходила такая фишка:
Такая фишка спокойно пройдет и при грамотной реализации. Впрочем, сам по себе подобный код не прошел бы у меня code review.

ГыНапример?
Путь, который я полагаю наиболее правильным, реализован в C++ и в Delphi, это возможность программисту явно управлять порядком инициализации.

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

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

ГыА почему не пройдет кодревью? У Вас какие-то предубеждения против анонимных классов?
Правильнее будет сказать так: "у меня предубеждение против анонимных объектов анонимных классов". Из вариантов кода




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

ГыУ меня сразу возникает вопрос. Зачем городить лишнее поле или даже класс, если потом он будет использовать только один раз? На мой вкус это только засоряет код ненужными вещами.
Это спасает код от засорения телом анонимных объектов, представляющего собой гораздо большую угрозу читабельности. Подобные "конструируемые на месте" объекты выглядят более-менее нормально в демонстрационных примерах, но когда в реале нужно инициализировать, например, пять кнопок подряд, навесив на каждую по листенеру с двумя-тремя методами, да и тела методов не из одной строки.... Это кошмар.

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

Вообще, как всегда забавно развитие истории по спирали. Когда-то существовало понятие вложенных, или локальных, подпрограмм. И развитие ООП шло в том числе под лозунгом "наконец-то мы можем уйти от этих жутких, нечитаемых вложенных подпрограмм к простым и ясным последовательно записанным методам объектов". После чего прошло еще несколько лет, и концепцию возродили в виде вложенных объектов, или - в C++ - локальных структур.

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

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

ГыТо есть именованный объект анонимного класса - нормально, анонимный объект именованного класса тоже, а вот вместе ни-ни? Похоже на религию.
Звучит сродни "то есть пить водку - нормально, пить пиво - нормально, а вот вместе ни-ни? Похоже на религию".

ГыПросто у меня подход
Я понимаю и не думаю, что стоит пытаться переубедить друг друга. Просто нас это затрагивает вот по какой причине: блоки инициализации - это заплата на комбинацию двух неудачных с моей точки зрения аспектов ява-концепции: "полностью анонимных объектов" и неименованных конструкторов. Соответственно, их потребности с моей точки зрения не являются концептуально важными; напротив, если их потребности приводят к дополнительным проблемам и ограничениям - тем больше причин доработать концепцию и выкинуть эту гадость.

ГыЕсли же я вижу, что получившаяся конструкция нечитаема
Вопрос "читаемости" является вопросом вкусов. С моей точки зрения, эта конструкция иногда "терпима", иногда "очень плоха", но никогда не "оптимальна".

Гы(а на самом деле человеку, который мало работает с явой она просто непривычна),
Ой, да бросьте. Ну что здесь "непривычного", если вспомнить про существующие уже полвека лямбда-функции?

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

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