Здравствуйте, WolfHound, Вы писали:
WH>Из-за этого "гениального" решения мне несколько раз приходилось писать immutable proxy для того чтобы защититься от собственных случайных ошибок.
Угу, причем именно отдельных прокси-имплементаторов отдельных immutable интерфейсов.
Поначалу я посчитал себя шибко умным, сделал имплементацию некоего MyReadOnlyBase — класса, и в public сигнатурах использовал именно его. Однако, соседи за партой так же быстро приводили его к наследнику, типа:
(MyMutable)myReadOnlyBaseVariable;
Так что, остается именно так — полновесные прокси, с разделением на интерфейсы и реализации на ровном месте (где этого не требовалось).
А потом подумаешь малость... И придет к тебе еще более "просветленное" решение: "да нахрена это вообще надо, есть же юнит тесты... и их все-равно запускать"...
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VladD2, Вы писали:
VD>>Еще хорошо бы все же иметь некий механизм позволяющий инкапсулировать общение между двумя тесносвязанными классами (вроде држбы в плюсах)
IT>internal — редкостная дрянь, впрочем не на много хуже чем friend в плюсах.
кстати, это единственный механизм реализации открытого immutable класса, при реально использующемся internal mutable-наследнике без дополнительного прокси.
Опять же, такая фича провоцирует на порождение множества мелких сборок.
Здравствуйте, vdimas, Вы писали:
V>кстати, это единственный механизм реализации открытого immutable класса, при реально использующемся internal mutable-наследнике без дополнительного прокси.
Проблемы начинаются когда ты такой класс начинаешь выносить из сборки. Тут сразу же появляются и прокси и другие подпорки
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>А потом подумаешь малость... И придет к тебе еще более "просветленное" решение: "да нахрена это вообще надо, есть же юнит тесты... и их все-равно запускать"...
Вот-вот. Сначала нужно определиться с уровнем доверия к вызывающему коду, а уже потом строить от него всякие защиты.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vdimas, Вы писали:
V>>А потом подумаешь малость... И придет к тебе еще более "просветленное" решение: "да нахрена это вообще надо, есть же юнит тесты... и их все-равно запускать"...
IT>Вот-вот. Сначала нужно определиться с уровнем доверия к вызывающему коду, а уже потом строить от него всякие защиты.
Уровень доверия... вона как...
Нужно тогда ввести в язык вместе с private, readonly и пр. конструкцию мамой_клянусь
или там в особо ответственных случаях мля_буду ...
Здравствуйте, IT, Вы писали:
V>>А потом подумаешь малость... И придет к тебе еще более "просветленное" решение: "да нахрена это вообще надо, есть же юнит тесты... и их все-равно запускать"...
IT>Вот-вот. Сначала нужно определиться с уровнем доверия к вызывающему коду, а уже потом строить от него всякие защиты.
Это не защита, и уровень доверия здесь ни при чем. Это ближе к более ясному выражению своих намерений, и к переносу информации из комментариев в код, для того чтобы компилятор мог напоминать, например, о расхождениях в намерениях автора класса/функции и их пользователя.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vdimas, Вы писали:
V>>кстати, это единственный механизм реализации открытого immutable класса, при реально использующемся internal mutable-наследнике без дополнительного прокси.
IT>Проблемы начинаются когда ты такой класс начинаешь выносить из сборки. Тут сразу же появляются и прокси и другие подпорки
К сожалению, они зачастую "невыносимы", т.е. даже подпорки иногда не помогают. Например, мы не можем подменить Nodes-collection в том же TreeView, да и во многих других аналогичных моментах. Сделать в своем наследнике прокси для Nodes — тоже фигушки, ибо не все события внутри него поддаются перехвату/обнаружению.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, vdimas, Вы писали:
V>>>А потом подумаешь малость... И придет к тебе еще более "просветленное" решение: "да нахрена это вообще надо, есть же юнит тесты... и их все-равно запускать"...
IT>>Вот-вот. Сначала нужно определиться с уровнем доверия к вызывающему коду, а уже потом строить от него всякие защиты.
CS>Уровень доверия... вона как... CS>Нужно тогда ввести в язык вместе с private, readonly и пр. конструкцию мамой_клянусь CS>или там в особо ответственных случаях мля_буду ...
А ещё -- никому не дам, дам только ему и его друзьям, дам всем и.т.п.
Если нам не помогут, то мы тоже никого не пощадим.
