Здравствуйте Аноним, Вы писали:
DG>>Все-таки лучше было сделать protected & private (особенно private) не жесткими ограничениями, а просто предупреждениями, т.к. я еще не встречал ни одного класса, у которого нельзя было немного расширить функциональность.
DG>>Т.е. по умолчанию, я не могу вызвать protected & private, но если сильно хочу (и отвечаю за свои действия), то могу. А>Лично я считаю что то что я могу полагаться что никто снаружи не доступится к классу это очень хорошо.
Так полагайся на это и дальше, так как человек вызвавщий protected &private метод делает это на свой страх и риск. Если ты о безопасности от хака, то protected&private тебя не спасут, так как их можно обойти с большим или меньшим геморром.
Также этим нарушаешся закон о том, что лицо купившее программу/библиотеку, может делать все что угодно с ней, переделывать код, реинженерить, переписывать куски и т.д.
A>А сделать возможность доступа к закрытым полям не так то просто. Очень многое в фреймворке на это заточено. К примеру тот же ремоутинг — в прокси включаются только публичные поля. Вызвать private метод нельзя просто потому что он физически отсутствует в метаданных. И и т.д.
На самом деле мне мешает только спецификатор private, т.к. я совсем не могу расширить класс сторонних разработчиков. А при наследование проблем будет меньше, и их можно было решить.
Re[18]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте DarkGray, Вы писали:
DG>>>Т.е. по умолчанию, я не могу вызвать protected & private, но если сильно хочу (и отвечаю за свои действия), то могу. А>>Лично я считаю что то что я могу полагаться что никто снаружи не доступится к классу это очень хорошо.
DG>Так полагайся на это и дальше, так как человек вызвавщий protected &private метод делает это на свой страх и риск. Если ты о безопасности от хака, то protected&private тебя не спасут, так как их можно обойти с большим или меньшим геморром.
Нет, я о безопасности от глюка. Я вобще не понимаю — если это твой код, то никаких проблем поменять прайват на паблик нет, если нормально написанная либа, то там все что нужно будет открыто, а если ненормально написаная — так нафига ей пользоваться?
Re[10]: Отсутствие множ. наследования и тэмплэйтов на CS
От:
Аноним
Дата:
17.06.02 10:05
Оценка:
Здравствуйте AndrewVK, Вы писали:
AVK>Ты специально издеваешся?
Ты зря кипятишься :) Все, что я хотел — чтоб проперти дня, месяца, года можно было изменить по-отдельности, не вызывая ни конструкторов, ни парсеров :) Ты же все время хочешь задавать дату целиком.
Re[16]: Отсутствие множ. наследования и тэмплэйтов на CS
От:
Аноним
Дата:
17.06.02 10:05
Оценка:
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Аноним, Вы писали:
А>>Почему ? Как по информативности, так и по удобству микрософт впереди. AVK>Впереди планеты всей? :) А много ли ты видел не MS документации?
Пользовался доками по программизмам QNX, Linux, Solaris, BeOS, Oracle.
Хорошие доки у соляриса, самые худшие — у кьюникса
AVK>На начхать на формат документации. Главное содержимое. А содерживое MS'овской документации иногда хромает. Я тут где то месяц назад кида пример из доки. Мне удалось уменьшить его раза так в три, при увеличении его понятности.
Вовсе не начхать. Формат предусматривает наличие средств просмотра и поиска. У не-микрософтовских док обычное средство просмотра — текстовый редактор, кривой просмотрщик, или, в лучшем случае, хтмл, поэтому времени на поиск инфы тратится куда больше.
Согласись, что я прав.
Re[15]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
AVK>Ну хорошо, давай твою идею, так сказать разовьем. private,protected,internal мешает программисту? Мешает. Убиваем нафик. Проверка на возврат значение мешает? Проверка на инициализацию мешает? GC мешает? Необходимость обязательной имплементации объявленных интерфейсов мешает? Мешает. Удаляем.
Блин, вовсе не надо удалять !
Ты в неправильном направлении развиваешь мою мысль.
Просто нужно добавить ключевое слово, отменяющее действие другого. Например, злосчастного sealed. А использовать ли unsealed, или нет — личное дело. Так было бы гибче.
DarkGray, как я считаю, прав — это повысило бы гибкость языка. Когда нужно расковырять чужое, а кода нет — это самое то.
Задача решена — УРА ! — землекопа полтора !
Re[19]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
DG>>Так полагайся на это и дальше, так как человек вызвавщий protected &private метод делает это на свой страх и риск. Если ты о безопасности от хака, то protected&private тебя не спасут, так как их можно обойти с большим или меньшим геморром. AVK>Нет, я о безопасности от глюка. Я вобще не понимаю — если это твой код, то никаких проблем поменять прайват на паблик нет, если нормально написанная либа, то там все что нужно будет открыто, а если ненормально написаная — так нафига ей пользоваться?
Дык, "ненормально" написанных библиотек большинство (в том числе от Microsoft), в которых этих protected & private просто немеренно натыкано.
Re[11]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте Аноним, Вы писали:
А>Здравствуйте AndrewVK, Вы писали:
AVK>>Ты специально издеваешся? А>Ты зря кипятишься Все, что я хотел — чтоб проперти дня, месяца, года можно было изменить по-отдельности, не вызывая ни конструкторов, ни парсеров Ты же все время хочешь задавать дату целиком.
Видишь ли какое дело — дата хранится в переменной типа double и в любом случае будет меняться целиком. Ты мне объясни — чем написание собственного wrapper лучше приведенного мною способа?
Здравствуйте Аноним, Вы писали:
А>Здравствуйте AndrewVK, Вы писали:
AVK>>Здравствуйте Аноним, Вы писали:
AVK>>Впереди планеты всей? А много ли ты видел не MS документации? А>Пользовался доками по программизмам QNX, Linux, Solaris, BeOS, Oracle. А>Хорошие доки у соляриса, самые худшие — у кьюникса
Ну линукса понятно, там хороших док не будет. У BeOS были очень хорошие доки, получше MS'овских. У оракля таки да, доки поганенькие. Остального не видел.
А>Вовсе не начхать. Формат предусматривает наличие средств просмотра и поиска. У не-микрософтовских док обычное средство просмотра — текстовый редактор, кривой просмотрщик, или, в лучшем случае, хтмл, поэтому времени на поиск инфы тратится куда больше.
Большинство док сейчас в формате html. Который легко и непринужденно переделывается в столь любимый тобой chm.
А>Согласись, что я прав.
Неа
Здравствуйте IVaNС, Вы писали:
IVNС>Здравствуйте AndrewVK, Вы писали:
IVNС>Блин, вовсе не надо удалять ! IVNС>Ты в неправильном направлении развиваешь мою мысль. IVNС>Просто нужно добавить ключевое слово, отменяющее действие другого. Например, злосчастного sealed. А использовать ли unsealed, или нет — личное дело. Так было бы гибче.
Не, это блин маразм какой то получается. Один классы закрывает, а другой с упорством их обратно разрешает. Нафига тогда вобще sealed если его можно отменить?
IVNС>DarkGray, как я считаю, прав — это повысило бы гибкость языка. Когда нужно расковырять чужое, а кода нет — это самое то.
Не, не понимаю я этого маниакального стремления расковыривать что то чужое. Проще все переписать.
Здравствуйте AndrewVK, Вы писали:
А>>Вовсе не начхать. Формат предусматривает наличие средств просмотра и поиска. У не-микрософтовских док обычное средство просмотра — текстовый редактор, кривой просмотрщик, или, в лучшем случае, хтмл, поэтому времени на поиск инфы тратится куда больше. AVK>Большинство док сейчас в формате html. Который легко и непринужденно переделывается в столь любимый тобой chm.
Так главное-то не txt/html/chm, а хорошая структуризация материала, в MSDN-е я нашел через поиск что-то похожее на то, что я ищу, нажал locate и наслаждаюсь топиками, близкими к моей проблеме.
А том же Man-е/VB-хелпе/stl-хелпе, если я не знаю конкретно, что искать, то и не найду, т.к. это просто плоский хелп, никак не структурированный.
Re[20]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте DarkGray, Вы писали:
DG>Дык, "ненормально" написанных библиотек большинство (в том числе от Microsoft), в которых этих protected & private просто немеренно натыкано.
Да нет, натыкано там все специально. Особенно sealed. Просто надо повнимательнее читать доку, там все нормальные способы сделать то или иное описаны, а не пытаться тоже самое сделать через задницу. Вот например — делаю я синглтон, конструктор естественно объявляю private. Потом появляется такой вот чел, который не разобравшись начинает вопеть — как так конструктор приватный, какая кривая либа. И вызывает приватный конструктор. Получает естественно набор труднотлавливаемых глюков где то внутри библиотеки и начинает орать что либа кривая.
Разработчики библиотек в массе как правило грамотнее их пользователей, поэтому отмена модификаторов доступа принесет больше проблем чем пользы.
Re[12]: Отсутствие множ. наследования и тэмплэйтов на CS
От:
Аноним
Дата:
17.06.02 10:25
Оценка:
Здравствуйте AndrewVK, Вы писали:
AVK>Видишь ли какое дело — дата хранится в переменной типа double и в любом случае будет меняться целиком. Ты мне объясни — чем написание собственного wrapper лучше приведенного мною способа?
В long, если точнее. А смысл во враппере такой, что, кроме того, что по-отдельности работаю с полями, добавил во враппер методы для работы с датами — назв месяцев на нескольких языках, переходы на следующие/предыдущие дни/месяца/года (хотя можно писать d = AddMonths(1), удобнее d.NextMonth()), получение всех месяцев периода и тд.
sealed здесь только помешал.
Re[17]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте AndrewVK, Вы писали:
AVK>Не, не понимаю я этого маниакального стремления расковыривать что то чужое. Проще все переписать.
А оплачивать кто все это будет? И время откуда брать?
Так берешь/покупаешь чужую реализацию, не много ее расковыриваешь, делаешь пару хелперов, несколько нашлепок на чужие классы и работаешь, потихоньку заменяя чужой код на свой или оставляя чужой, если он "достаточно хороший".
При отсутствии anti-private/anti-protected/anti-sealed все это делается очень сложно и не оптимально, так как остается использовать только ту узкую щелку, которую оставил разработчик библиотеки.
Re[19]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте AndrewVK, Вы писали:
DG>Так главное-то не txt/html/chm, а хорошая структуризация материала, в MSDN-е я нашел через поиск что-то похожее на то, что я ищу, нажал locate и наслаждаюсь топиками, близкими к моей проблеме.
Ты знаешь, лично я поиском пользуюсь крайне редко. Обычно знаю где что лежит.
DG>А том же Man-е/VB-хелпе/stl-хелпе, если я не знаю конкретно, что искать, то и не найду, т.к. это просто плоский хелп, никак не структурированный.
Но ведь этими плоскими хелпами весь мир не ограничивается. Чем тебе не нравится хелп Дельфи? Или Java?
Здравствуйте AndrewVK, Вы писали:
AVK> Вот например — делаю я синглтон, конструктор естественно объявляю private. Потом появляется такой вот чел, который не разобравшись начинает вопеть — как так конструктор приватный, какая кривая либа. И вызывает приватный конструктор. Получает естественно набор труднотлавливаемых глюков где то внутри библиотеки и начинает орать что либа кривая. AVK>Разработчики библиотек в массе как правило грамотнее их пользователей, поэтому отмена модификаторов доступа принесет больше проблем чем пользы.
Ты правильно заметил, что в массе грамотнее, а как быть тем пользователем, которые грамотнее разработчика библиотеки или имеют, хотя бы такой же уровень.
Вот захочу я немного расширить твой singleton, добавить пару простых функций и опа, компилятор мне говорит "а не фиг", пользуйся тем, что дают.
Хотя я мог полностью понимать, что хотел сказать этим private-ом разработчик либы, мне это ничем не поможет.
Придется все равно выдирать весь код из либы, переписывать и т.д., что в дальнейшем для меня сильно затруднит переход на следующую версию твоей библиотеки.
Re[13]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте Аноним, Вы писали:
А>Здравствуйте AndrewVK, Вы писали:
AVK>>Видишь ли какое дело — дата хранится в переменной типа double и в любом случае будет меняться целиком. Ты мне объясни — чем написание собственного wrapper лучше приведенного мною способа?
А>В long, если точнее.
Да нет, именно в double. В целой части хранится дата, в дробной время.
А> А смысл во враппере такой, что, кроме того, что по-отдельности работаю с полями, добавил во враппер методы для работы с датами — назв месяцев на нескольких языках,
И это тоже можно сделать стандартными средствами. Причем на таком количестве языков что тебе ни за что самому не сделать. А> переходы на следующие/предыдущие дни/месяца/года (хотя можно писать d = AddMonths(1), удобнее d.NextMonth()),
Ни чуть не удобнее. И и мелочь все это. Не на том внимание заостряешь.
А>sealed здесь только помешал.
Тут я тебе могу объяснить к чему sealed. Фреймворк очень сильно завязан на DateTime. И во многих случаях если ты подсунешь своего наследника это приведет к глюкам. К примеру в ADO.NET осуществляется автоматическое преобразование стандартных типов к sql типам. Представь что будет если ты впихнешь свой DateTime. В лучшем случае она просто выкинет исключение. А в худшем она сериализует твой объект и запихает его в блоб. И ты долго будешь глюки вылавливать.
Это только один пример. Таких моментов в фреймворке масса. Поэтому все стандартные типы объявлены как sealed. Если же очень приспичило свой DateTime — используй агрегацию и реализуй IConvertible.
Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте AndrewVK, Вы писали:
DG>А оплачивать кто все это будет? И время откуда брать? DG>Так берешь/покупаешь чужую реализацию, не много ее расковыриваешь, делаешь пару хелперов, несколько нашлепок на чужие классы и работаешь, потихоньку заменяя чужой код на свой или оставляя чужой, если он "достаточно хороший".
О как — достаточно хороший. Так не бывает — либо хороший, либо плохой. Если вы будете отменять модификаторы то такой код становится крайне плохим. Сейчас эта либа работает, потом очередная версия что то внутри себя меняет и твоя прога начинает глючить по черному, причем ошибки сыпятся внутри чужого кода (который без исходников).
DG>При отсутствии anti-private/anti-protected/anti-sealed все это делается очень сложно и не оптимально, так как остается использовать только ту узкую щелку, которую оставил разработчик библиотеки.
Все, надоело спорить, больше рассказывать про азы ОО проектирования не хочу. Вас, я чувствую, все равно не переубедишь.
Здравствуйте DarkGray, Вы писали:
DG>Ты правильно заметил, что в массе грамотнее, а как быть тем пользователем, которые грамотнее разработчика библиотеки или имеют, хотя бы такой же уровень. DG>Вот захочу я немного расширить твой singleton, добавить пару простых функций и опа, компилятор мне говорит "а не фиг", пользуйся тем, что дают.
Синглтонами как правило реализуется ядро системы. И наследовать от них без исходного кода крайне нежелательно. Если же такая возможность есть то я объявлю конструктор как protected.
DG>Придется все равно выдирать весь код из либы, переписывать и т.д., что в дальнейшем для меня сильно затруднит переход на следующую версию твоей библиотеки.
Вот как раз пользование private членами и затруднит переход на новую версию, ибо я имею полное право вобще прайват-член прибить. Блин, ну что я тут основы ООП рассказываю. Вы специально издеваетесь, либо мы друг друга просто не понимаем.
Здравствуйте AndrewVK,
AVK>Вот как раз пользование private членами и затруднит переход на новую версию, ибо я имею полное право вобще прайват-член прибить. Блин, ну что я тут основы ООП рассказываю. Вы специально издеваетесь, либо мы друг друга просто не понимаем.
Не горячись
Просто ООП — это не панацея. Вопрос в том, что если писать язык только для профессионалов, то можно сделать такие изменения в языке, если думать о том, что чайники тоже захотят пользоваться языком, то есть только два пути: первый — запретить им делать то, что делать в большинстве случаев не нужно, второй — разрешить, но повесить красную табличку: "если вы используете это, то мы не несём никакой ответсвенности". Для профи второй вариант явно лучше.
Re[24]: Отсутствие множ. наследования и тэмплэйтов на CS
Здравствуйте Mishka<T>, Вы писали:
MT>Не горячись MT>Просто ООП — это не панацея. Вопрос в том, что если писать язык только для профессионалов, то можно сделать такие изменения в языке, если думать о том, что чайники тоже захотят пользоваться языком, то есть только два пути: первый — запретить им делать то, что делать в большинстве случаев не нужно, второй — разрешить, но повесить красную табличку: "если вы используете это, то мы не несём никакой ответсвенности". Для профи второй вариант явно лучше.
Спорный вопрос. Человек не автомат — кое где и дурака может свалять, даже наикрутейший профи.