Финализация виртуальных методов
Модератор: Модераторы
Уж поверь мне - ничего я не путаю.
Добавлено спустя 2 минуты 41 секунду:
Вот, простой пример вспомнил: попробуйте на VCL сделать MDI приложение без скроллеров в клиентской области. Без хака.
Добавлено спустя 2 минуты 41 секунду:
Вот, простой пример вспомнил: попробуйте на VCL сделать MDI приложение без скроллеров в клиентской области. Без хака.
Max Rusov писал(а):Чего ты хочешь добиться? Доказать что я дурак и можно было обойтись без Hack'а? Подобные примеры довольно трудно привести, потому что они обычно встречаются, когда решаешь нестандартные задачи.
я не хочу ничего ни о ком плохого говорить, или доказывать что кто-то из нас двоих идиот.
Мне тоже приходилось решать нестандартные задачи, но ни разу мне не приходилось стучаться к private.
Вообще, самый жуткий хак VCL-а, это наличие у каждого WinControl-а, есть свойство Handle.
2 Mr.Smart. ну это полулегальный способ объявить наследника и получить доступ к protected... пользовался пару раз
- AbakAngelSoft
- постоялец
- Сообщения: 273
- Зарегистрирован: 06.08.2008 19:28:26
- Откуда: Краснодар
- Контактная информация:
скалогрыз писал(а):как можно залесть в private класса находясь в другом модуле (ином, чем объявленный класс)?
можно но не нужно!
скалогрыз писал(а):можно ли пример, где это нужно?!
иногда на самом деле нужно, Max Rusov прав. Но только потому что определенный класс, повторюсь, не верно спроектирован. Завтра покопаюсь в своих проектах и приведу пару примеров из реальной жизни стандартных классов vcl.
Max Rusov писал(а):сделать приложение в котором было бы 2-MDI формы
А в чем была сложность если не секрет?
Полюбуйся, как в VCL реализованы методы GetMDIChildCount/GetMDIChildren. Вообще пример не очень удачен, тут даже Hack классы не помогли, пришлось Forms править...
2скалогрыз: Что-то я не понял вот это. Такая конструкция помогает добраться до private?
and писал(а):2скалогрыз: Что-то я не понял вот это. Такая конструкция помогает добраться до private?
аха. Структура классов THackList и TList будет совподать.
Но это нелегально, и чревато последствиями в тех случаях, когда внутреняя реализация класса TList изменится.
ох... дурной пример заразителен.
ЗЫ: ещё раз повторюсь, что мне ниразу не пришлось использовать подобный способ. Мне проще было бы сделать copy-paste и "доделать" уже новый класс, чем, что-либо хакать ))
to AbakAngelSoft
по поводу предусмотрительности при проектировании классов. если вы проектируете какойто свой локальный класс который никому насторону выкладывать ненамерены, то очень возможно поверить что можно предсказать как оно будет использоваться и заприватить\опубликовать только то что нужно. (только накой ето надо если для себято? я свои классы делю только на публик и протектед и то только для того чтоб в инспекторе кода методы както упорядочить)
а если посмотреть на глольные либы VCL,FCL,LCL... которыю пользуют массы, то будь Вы хоть 20ти пядей волбу предсказать как оно потребуется использовать\изменять\наворачивать неполучиться, а если и постараться времени и сил на ето убьется значительно больше чем эффекта от такого разграничения доступа. по любому криворукость исправляется набитыми шишками а не хлыстами и стопзнаками
>>Но отказ от строгости это дорога в анархию и неработающий код с трудноуловимыми багами.
лично я для себя уяснил что безглючный код - ето хорошо протестированый код, а не код который написан строго - про такой код могу только говорить что он компилируется. Хороший пример в етом Pyton - куча кода на нем рубится, но чтото он никак не загнется от недостатка срогости.
по поводу предусмотрительности при проектировании классов. если вы проектируете какойто свой локальный класс который никому насторону выкладывать ненамерены, то очень возможно поверить что можно предсказать как оно будет использоваться и заприватить\опубликовать только то что нужно. (только накой ето надо если для себято? я свои классы делю только на публик и протектед и то только для того чтоб в инспекторе кода методы както упорядочить)
а если посмотреть на глольные либы VCL,FCL,LCL... которыю пользуют массы, то будь Вы хоть 20ти пядей волбу предсказать как оно потребуется использовать\изменять\наворачивать неполучиться, а если и постараться времени и сил на ето убьется значительно больше чем эффекта от такого разграничения доступа. по любому криворукость исправляется набитыми шишками а не хлыстами и стопзнаками
>>Но отказ от строгости это дорога в анархию и неработающий код с трудноуловимыми багами.
лично я для себя уяснил что безглючный код - ето хорошо протестированый код, а не код который написан строго - про такой код могу только говорить что он компилируется. Хороший пример в етом Pyton - куча кода на нем рубится, но чтото он никак не загнется от недостатка срогости.
- AbakAngelSoft
- постоялец
- Сообщения: 273
- Зарегистрирован: 06.08.2008 19:28:26
- Откуда: Краснодар
- Контактная информация:
К сожалению не локальный и не для себя. Тогда бы я все оставил в public в том числе и поля.
В этом и заключается работа программиста!
Не правильный у Вас подход.
"набитые шишки" программирования:
http://www.lenta.ru/world/1999/10/01/nasa/
http://ru.wikipedia.org/wiki/Therac-25
http://ru.wikipedia.org/wiki/%D0%90%D0%B2%D0%B0%D1%80%D0%B8%D1%8F_%D1%80%D0%B0%D0%BA%D0%B5%D1%82%D1%8B-%D0%BD%D0%BE%D1%81%D0%B8%D1%82%D0%B5%D0%BB%D1%8F_%D0%90%D1%80%D0%B8%D0%B0%D0%BD_5_(4_%D0%B8%D1%8E%D0%BD%D1%8F_1996)
http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%80%D0%B8%D0%BD%D0%B5%D1%80-1
Естественно, на слуху только те которые обошлись в миллиарды долларов, а сколько "мелких" ошибок программирования, которые обошлись всего в несколько миллионов долларов, никто просто не считал.
Как можно было оттестировать посадочный модуль марсохода на земле? К сожалению не смог найти статью где рассказывалось что автоматические тесты на земле в том числе и моделирование посадки весь комплекс проходил на ура!
Отсюда вывод: никогда не надо надеяться на тестирование и ни в коем случае нельзя превращать в тестеров пользователей.
Я не предлагая отказаться от тестирования, но считаю, что ориентироваться только на него чревато проблемами.
Я работаю в миллион рублевом проекте, но думаю мне не простят ошибки вроде марсохода.
Куча кода рубится на C, но вы каким то образом оказались на этом сайте...
alexrayne писал(а):будь Вы хоть 20ти пядей волбу
В этом и заключается работа программиста!
alexrayne писал(а):криворукость исправляется набитыми шишками а не хлыстами и стопзнаками
Не правильный у Вас подход.
"набитые шишки" программирования:
http://www.lenta.ru/world/1999/10/01/nasa/
http://ru.wikipedia.org/wiki/Therac-25
http://ru.wikipedia.org/wiki/%D0%90%D0%B2%D0%B0%D1%80%D0%B8%D1%8F_%D1%80%D0%B0%D0%BA%D0%B5%D1%82%D1%8B-%D0%BD%D0%BE%D1%81%D0%B8%D1%82%D0%B5%D0%BB%D1%8F_%D0%90%D1%80%D0%B8%D0%B0%D0%BD_5_(4_%D0%B8%D1%8E%D0%BD%D1%8F_1996)
http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%80%D0%B8%D0%BD%D0%B5%D1%80-1
Естественно, на слуху только те которые обошлись в миллиарды долларов, а сколько "мелких" ошибок программирования, которые обошлись всего в несколько миллионов долларов, никто просто не считал.
Как можно было оттестировать посадочный модуль марсохода на земле? К сожалению не смог найти статью где рассказывалось что автоматические тесты на земле в том числе и моделирование посадки весь комплекс проходил на ура!
Отсюда вывод: никогда не надо надеяться на тестирование и ни в коем случае нельзя превращать в тестеров пользователей.
Я не предлагая отказаться от тестирования, но считаю, что ориентироваться только на него чревато проблемами.
Я работаю в миллион рублевом проекте, но думаю мне не простят ошибки вроде марсохода.
alexrayne писал(а):Хороший пример в етом Pyton - куча кода на нем рубится, но чтото он никак не загнется от недостатка срогости.
Куча кода рубится на C, но вы каким то образом оказались на этом сайте...
>>Куча кода рубится на C, но вы каким то образом оказались на этом сайте... 
ето мое детство с етого начинал. вообще работаю с ембеббедом - а там паскаль невариант. такчто как ниплачь а Си рулит.
По поводу милионных ошибок, мое имхо, жесткость языка должна чтото существенное предлагать взамен, а по
моему опыту только усложняет жизнь, отвлекает на себя труд вместо того чтоб етот труд и время вложить в
тестирование. и если уж всерьез о ней говорить - то дельфи жесткостью похвастать неможет, его навороты
направлены на расширение возможностей (приват\публик в том же числе, протектед конешно под вопросом),
имхо, ето уже показатель что нужно а что нет (выходит жесткость нетак уж людям и нужна).
(то что надежность неособо людям нужна, могу подтвердить по ряду моих переругиваний с Марко ванДерротом или Джонасом Маебе - они нивкакую нехотят вносить элементы ады или оберона в их паскаль, только дельфя для них икона)
Я довольно плотно поработал в ВДХЛе (он наследник Ады), местами его жесткость меня бесить начинала, писал также код на верилоге(он наследник С). и там и там количество ошибок было немеряное и единственный способ сделать устройство более менее работающим - отладить его на тестбенчах. у программистов уже методология образовалась - половина труда на разработку программы, половина - на тестирование.
Так вот на верилое прога пишется както проще, нетак компилятор достает.
после написания пары ядер я меня появилось чень четкое ощущение что начиная с некоторого порога сложности программы совершенно безразлично насколько вы умны и насколько быстро просчитываете зависимости - упустите одну, повалится все. такчто хороший моделер и набор тестов становится единственной гарантией.
ето мое детство с етого начинал. вообще работаю с ембеббедом - а там паскаль невариант. такчто как ниплачь а Си рулит.
По поводу милионных ошибок, мое имхо, жесткость языка должна чтото существенное предлагать взамен, а по
моему опыту только усложняет жизнь, отвлекает на себя труд вместо того чтоб етот труд и время вложить в
тестирование. и если уж всерьез о ней говорить - то дельфи жесткостью похвастать неможет, его навороты
направлены на расширение возможностей (приват\публик в том же числе, протектед конешно под вопросом),
имхо, ето уже показатель что нужно а что нет (выходит жесткость нетак уж людям и нужна).
(то что надежность неособо людям нужна, могу подтвердить по ряду моих переругиваний с Марко ванДерротом или Джонасом Маебе - они нивкакую нехотят вносить элементы ады или оберона в их паскаль, только дельфя для них икона)
Я довольно плотно поработал в ВДХЛе (он наследник Ады), местами его жесткость меня бесить начинала, писал также код на верилоге(он наследник С). и там и там количество ошибок было немеряное и единственный способ сделать устройство более менее работающим - отладить его на тестбенчах. у программистов уже методология образовалась - половина труда на разработку программы, половина - на тестирование.
Так вот на верилое прога пишется както проще, нетак компилятор достает.
после написания пары ядер я меня появилось чень четкое ощущение что начиная с некоторого порога сложности программы совершенно безразлично насколько вы умны и насколько быстро просчитываете зависимости - упустите одну, повалится все. такчто хороший моделер и набор тестов становится единственной гарантией.
alexrayne писал(а):(то что надежность неособо людям нужна, могу подтвердить по ряду моих переругиваний с Марко ванДерротом или Джонасом Маебе - они нивкакую нехотят вносить элементы ады или оберона в их паскаль, только дельфя для них икона)
Marco van de Voort? да, они оба консерваторы
но форк они же не запрещают сделать
Сейчас пришло в голову...
Если сделать public метод (не virtual), а внем вызывать скрываемый метод, который private - то получится то же самое, что и с final. То есть метод доступен в потомках, но перекрыть нельзя. Или нет?
Если сделать public метод (не virtual), а внем вызывать скрываемый метод, который private - то получится то же самое, что и с final. То есть метод доступен в потомках, но перекрыть нельзя. Или нет?
у меня нету времени рубить паскаль, только интерес остался, и баги которые никак необойти приходится пилить.
а некоторых фич ну очень хочется. такчтоостается только облизываться и надеяться что появится когдато
коллектор модов к фрюхе.
Добавлено спустя 59 секунд:
inherited все равно можно вызвать
а некоторых фич ну очень хочется. такчтоостается только облизываться и надеяться что появится когдато
коллектор модов к фрюхе.
Добавлено спустя 59 секунд:
Climber писал(а):Сейчас пришло в голову...
Если сделать public метод (не virtual), а внем вызывать скрываемый метод, который private - то получится то же самое, что и с final. То есть метод доступен в потомках, но перекрыть нельзя. Или нет?
inherited все равно можно вызвать
- AbakAngelSoft
- постоялец
- Сообщения: 273
- Зарегистрирован: 06.08.2008 19:28:26
- Откуда: Краснодар
- Контактная информация:
Climber писал(а):Если сделать public метод (не virtual), а внем вызывать скрываемый метод, который private - то получится то же самое, что и с final. То есть метод доступен в потомках, но перекрыть нельзя.
Есть класс
Код: Выделить всё
TA = class (TObject)
protected
function MyProc: Int64; virtual;
end;
от него порождаются:
Код: Выделить всё
TB = class (TObject)
protected
function MyProc: Int64; override;
end;
TC = class (TObject)
protected
function MyProc: Int64; override;
function MyProcNew: Integer; virtual;
end;
Потомки TB могут безопасно перекрывать MyProc, а для потомком TC перекрытие этого метода чревато ошибками. Для них введен новый метод MyProcNew. Но народ будет "по привычке" перекрывать MyProc.
PS Может пример слишком надуман, но больше ничего в голову не пришло, что бы объяснить на пальцах. А выкладывать весь проект, где это встретилось, слишком объемно, да и не open source - начальство заругается.
Добавлено спустя 5 минут 21 секунду:
Еще пример: если бы в коллекцию класс item-ов не передавался в конструкторе, а запрашивался динамически через виртуальный метод, то породив коллекцию с определенными типом элементов было-бы неплохо защитить код от получения неверного класса во время компиляции, а не в runtime.
