Похоливарим еще? (java, checked exceptions)

← →
euru © (2007-11-22 10:55) [200]

> Юрий Зотов © (22.11.07 10:05) [198]

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

← →
Юрий Зотов © (2007-11-22 11:06) [201]

> euru © (22.11.07 10:55) [200]

И от чего же тут надо защищаться?

Вот есть конструктор Throwable(String, Throwable).
Есть потомок этого класса CloneNotSupportedException.
Почему нельзя написать new CloneNotSupportedException("...", e)?
В чем тут опасность, от которой надо защищаться?

← →
Сусл © (2007-11-22 11:13) [202]

> [201] Юрий Зотов © (22.11.07 11:06)
> > euru © (22.11.07 10:55) [200]
>
> И от чего же тут надо защищаться?
>
> Вот есть конструктор Throwable(String, Throwable).
> Есть потомок этого класса CloneNotSupportedException.
> Почему нельзя написать new CloneNotSupportedException("...",
> e)?
> В чем тут опасность, от которой надо защищаться?

Позволь я отвечу?
Здесь как бы 2 направления мысли есть - почему в языке конструкторы не наследуются, почему конкретный разработчик класса CloneNotSupportedException (ты же недумаешь, что именно придумывал язык) не отнаследовал требуемый тебе конструктор?

по первому вопросу сказать нечего - для этого и топик заведен :) авось ближе к концу ясно станет, почему так сделано.

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

← →
Юрий Зотов © (2007-11-22 11:35) [203]

> конкретному разработчику показалось, что так правильно

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

Дим, ну не верю я что он настолько дурак. Тут что-то другое.

← →
Сусл © (2007-11-22 11:41) [204]

> Дим, ну не верю я что он настолько дурак. Тут что-то другое.

может быть не стоит нагружать такой функциональнсотью клон?
почитай в Эккеле 3-е издание Приложение А раздел "клонирование"
там страниц 20 текста, есть кстати подраздел "почему сделано так странно?".

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

← →
euru © (2007-11-22 11:56) [205]

> Юрий Зотов © (22.11.07 11:06) [201]

> Почему нельзя написать new CloneNotSupportedException("...", e)?

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

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

← →
Petr V. Abramov © (2007-11-22 13:23) [206]

> Юрий Зотов © (22.11.07 11:35) [203]
> Дим, ну не верю я что он настолько дурак. Тут что-то другое.

"не ищите сложные объяснения простых вещей" :)))

← →
iZEN © (2007-11-22 14:28) [207]

> Юрий Зотов © (22.11.07 10:05) [198]
> Не верю. Понимаете, я не верю, что класс Object писали дураки.
> Наоборот, я не сомневаюсь, что его писали очень умные и
> очень опытные люди. И если они сделали именно так - значит,
> какой-то смысл в этом есть, что-то они в виду имели. Вот
> в ЭТОМ и хочется разобраться.

Знаете что, на это я могу посоветовать почитать книжки в такой последовательности:

• Кен Арнолд, Джеймс Гослинг, Дэвид Холмс, «Язык программирования Java», 3-е издание (изд. Вильямс, 2001г);
• Стивен Стелтинг «Java без сбоев: обработка исключений, тестирование, отладка» (изд. КУДИЦ-ОБРАЗ, 2005г);
• Джошуа Блох «Java. Эффективное программирование» (изд. Лори, 2002г).

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

← →
iZEN © (2007-11-22 14:47) [208]

Можно я влезу в вашу дискуссию?

Влезаю.

> Юрий Зотов © (22.11.07 10:05) [198]
>
> Дим, огромное спасибо за ценный совет читать книги. Только
> это... видишь ли, Эккеля я как бы читал. И как бы далеко
> не раз. И что конструктор может в потомке стать недоступным
> - это я в курсе. Но не могу понять - а почему и зачем так
> сделано? Неудобно ведь.

Почему неудобно? Вы про образцы проектирования слышали? Про Фабричный метод, про Синглтон?
Так оно для поддержки всего этого и сделано.
А ещё есть такое понятие как КОНТРАКТ.

> Юрий Зотов © (22.11.07 10:05) [198]
>
> Вот в данном конкретном случае - никто не мешает написать
> потомка CloneNotSupportedException и объявить в нем конструктор
> с параметрами (String, Throwable). И все завернется, как
> миленькое.

Не факт.
Метод Object.clone() может быть весьма нетривиален в потомках: как делать клонирование ГЛУБОКО (строить клоны всех полей и объектов, всю композицию объекта) или ПОВЕРХНОСТНО (только для нефинальных полей примитивного типа)?

Интерфейс Cloneable — это интерфейс-метка. Он предопределяет МИКСИН (примесь), которую можно приделать к потомкам. Обычные интерфейсы кроме этого определяют больше семантики, а именно доопределяют КОНТРАКТ. Интерфейс Cloneable не задаёт контракт.

Почему так сделали — я лично не понял — слишком много степеней свободы дали методу клонирования, а вот что не додали — вопрос.

> Юрий Зотов © (22.11.07 10:05) [198]
> Но остается тот же вопрос - порождать потомка
> класса лишь для того, чтобы сделать доступным нужный конструктор
> - это есть бред. И почему этот бред мне навязывают? Что,
> модель ООП для джавы дураки придумывали? Не верю. Тогда
> чего они хотели этим скрытием конструкторов добиться?

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

> Юрий Зотов © (22.11.07 10:05) [198]
>
> А насчет того, что у джавы философия есть - может, и есть.
> Но слова твои прозвучали, тем не менее, голословно. Потому
> что оттого, что кто-то перевел "Thinking in Java" как "Философия
> Java", никакой философии еще не возникло - а никаких других
> доказательств ты не привел.

Брюса Эккеля лучше не читать. У него какая-то "своя" философия. Например, он не уверен надёжности реализации многопоточности.

> Юрий Зотов © (22.11.07 10:05) [198]
>
> То, что броско названо какой-то там "философией" называется
> на самом деле проще, понятнее и конкретнее - "реализованная
> модель ООП". И она есть в ЛЮБОМ ОО-языке, потому что иначе
> не бывает. Ну так вот - некоторые аспекты этой реализации
> в Jav"е выглядят, как минимум, недостаточно продуманными.
> Что очень странно - и в чем и хочется разобраться.

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

← →
euru © (2007-11-22 15:19) [209]

> iZEN © (22.11.07 14:47) [208]

> Про Фабричный метод, про Синглтон? Так оно для поддержки
> всего этого и сделано.

> Скрытие конструкторов очень помогает заменить наследование
> агрегацией.
А это точно не следствие архитектуры Java?

← →
DiamondShark © (2007-11-22 17:36) [210]

> Но остается тот же вопрос - порождать потомка класса лишь
> для того, чтобы сделать доступным нужный конструктор - это
> есть бред. И почему этот бред мне навязывают?

> ну не верю я что он настолько дурак. Тут что-то другое

Это другое сильно напоминает байку про диаметр ракеты-носителя и ширину конской задницы.

Берём Ц++, пишем:

class Foo
{
public:
Foo(int i, int j)
{
}
};

class Bar: Foo
{
};

Foo* foo = new Foo(1,2); // Ok
Bar* bar = new Bar(1,2); // Figvam
return 0;

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

Нафига это в managed языках, где поля экземпляра инициализируются значениями по умолчанию (иначе бы GC не работал!) -- лешему известно.
В Яву и СиШарп такое поведение явно собезьяничали с того, что было вдолблено в головы.

Все умные слова про шаблоны и фабрики -- это уже рационализация задним числом.

> euru © (22.11.07 15:19) [209]
>
> > iZEN © (22.11.07 14:47) [208]
>
> > Про Фабричный метод, про Синглтон? Так оно для поддержки
> > всего этого и сделано.
>
> > Скрытие конструкторов очень помогает заменить наследование
> > агрегацией.
> А это точно не следствие архитектуры Java?

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

> привело к рождению на свет таких сущностей как "класс-одиночка",
> "фабричный метод"

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

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

> DiamondShark © (22.11.07 17:36) [210]
у тебя ссылки нет живой.
а то нифигандекс на слова ракета и сопутствующие выдает из цензурного про покупку лошадей
:)

← →
J_f_S (2007-11-22 23:41) [214]

> а то нифигандекс на слова ракета и сопутствующие выдает
> из цензурного про покупку лошадей:)

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

Похоливарим еще? (java, checked exceptions) Найти похожие ветки