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


И это правильное решение. Вот создали мы TResourceStream. Окей, писать мы не можем. А потом мы передали его в процедуру Func1(AStrm: TStream), которая помимо кучи чтений (её обязательная работа) выполняет в самом конце одну запись - также обязательная часть её работы. И? Поток спокойно проглотит запись, т.к. теперь там не стоит возбуждение исключения. И это безопасно? Ладно, пусть там будет какое-то автогенерируемое исключение наподобие Abstract Error. Тогда всё равно получается, что от ситуации с возникновением исключения в run-time вы никуда не уйдёте, как было - так и осталось. Помимо путаницы (когда у нас метод невидим, когда он возбуждает исключение и т.п.) мы получаем лишние усилия разработчиков Delphi, которые можно было бы пустить в другое место.

Далее, пусть в классе вы запретили вызов метода предка, а у его потомка кто-то его снова включил. В какую-то процедуру передаётся класс с "погашенным методом". Вы передаёте туда класс-потомок, у которого метод повторно включён. Хотя метод есть, но вызвать вы его не можете. Опять какая-то нелогичность и путаница.

Замечу, что ситуация в целом несколько напоминает механизм абстрактных методов. Компилятор ведь не запрещает вам вызывать абстракный метод, уповая на то, что вы в run-time передадите экземпляр, где он реализован. Также и здесь. Уж если вы сделали метод public - вот любой его и сможет вызвать. А если вы его по какой-то причине не поддерживаете - ну так возбудите исключение. Это единообразно согласуется с общим поведением в Delphi. А вот это "скрытие методов" - IFWTPICPPTPICPP.

Вообще в C(++) понадобавляли много чего из серии "ааа... ну как же без этого, а ВДРУГ кому-то это понадобиться???". Из-за этого язык стал одним из самых мощных, гибких, но в то же время сложным и небезопасным. Дай людям в руки возможность и они обязательно воспользуются ей неправильно. Например, там есть возможность создать класс со статическим (не виртуальным) деструктором. И что? Допускаю, что когда-то кому-то такая возможность однажды пригодилась, но противовесом стали бесчисленные множества кривых реализаций со статическим деструктором вместо виртуального. В интернете куча статей и постов в блогах для таких вот горе-разработчиков: "почему деструктор ВСЕГДА должен быть виртуальным". А вот в Delphi он виртуален по-умолчанию. И проблем нет. А если он кому-то понадобиться - это не проблема как-нибудь сэмулировать.
Так же и эта вот возможность скрытия методов. Да, польза от неё может быть, но вреда намного больше.

P.S. Да, и это не единственный пример с исключениями в run-time, вот ещё, к примеру:

Этот пример ловит ситуации, когда в тип переменной SomeVar мы добавили несколько новых констант, а в каком-то case в коде забыли их учесть.

Это сообщение отредактировал(а) CodeMonkey - 6.4.2009, 08:46

   Одно другому не мешает. Я точно не помню иерархию, но допустим, что TResourceStream наследуется не напрямую от TStream, а от промежуточного TReadOnlyStream, который генерит общее для всех потомков исключение WriteError. Теперь у TResourceStream есть необходимое поведение, но есть и лишние методы в секции public. Класс TResourceStream последний в цепочке, поэтому все лишние методы следует скрыть, так как же как скрываются свойства не имеющие смысла в контексте текущего класса.
  Такая фича не может быть потенциально опасной, потому что ее цель увеличить степень безопасности. 


  Так в том то и прикол что и в С++ нет такого механизма...

Ну не знаю, я в сях вообще 0   , но разве не об этом говорили:




Я там не говорил о конкретно TResourceStream, но если брать пример с ним, то те мои слова остаются в силе, если предположить, что мы создаём наследника от TResourceStream у которого работают write-методы.


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

Молодец Alexeis, удачный пример привел.

в cpp нельзя изменить область видимости метода в наследнике, я правильно понял цитату ? а как же это :

 ?   

Это сообщение отредактировал(а) mes - 6.4.2009, 14:29

Я думаю всем  понятно, чем проще код, тем он более понятен  и легко модифицируем и это может является показателям профессионализма. Увеличение энтропии всегда не хорошо,а добавление механизма сокрытия статических паблик методов добавлять много неоднозначностей. Часто говорится   что C++ мощный язык, но даже например перегрузка операторов собирает много критики. Вспоминается поговорка "заставь дурака богу молится дак он и лоб расшибет". Если вы не правильно спроектировали иерархию классов, можно воспользоваться средствами рефакторинга или можно натворить такого, что последующая модификация и развития проекта станет задачей архи сложной и не посильной, когда переписать все заново будет намного проще, чем что то исправить.  
Заметьте  множественно наследование считается злом, вы предлагаете что то похожее. ООП родилось не в мгновение ока, и  подменять принципы ООП не есть гуд. 

ага, дельфи в этом плане безопаснее, чем cpp. 

имхо правильней(более применима к обсуждаемому контексту ) эта поговорка звучала бы при замене слова "заставь" на "позволь" 
 

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


Согласен, но не всегда возможно (по каким либо причинам) довести иерархию до идеала . 


Это сообщение отредактировал(а) mes - 6.4.2009, 15:09

  Да ну, значит инкапсуляция теперь уже не принцип ООП? Объект предоставляет наружу, только то что допустимо к использованию, то что считает нужным и ничего лишнего. Текущий вариант как раз является нарушением принципа инкапсуляции. 
  Не надо думать что реализация ООП в Delphi это на 100% соответствие основным принципам. Это лишь жалкое подобие. Теоретическая концепция намного глубже.

Добавлено через 2 минуты и 16 секунд

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

да, но "не много" звучало в контексте того, что есть вариант получше :

  

Я этого и не говорил. Но если уже заговорили про это, то думаю лучше посмотреть как это реализовано в JAVA и С#..

Добавлено @ 16:52

пословицу смотреть выше 
 

Если например у нас иерархия состоит из 20 классов, то вы допускаете возможность в каждом классе менять область видимости как угодно? Или если была в одном классе видимость  изменена с  public на private, то в его наследниках он уже будет не видим?

и вообще бред какой то, хочешь менять область видимости делай virtual

Это сообщение отредактировал(а) cemick - 6.4.2009, 17:10

да ?!   поясните пожалуйста   

cemick, только при этом нужно в наследнике вызывать метод предка. Тоже самое делается с любым методом, виртуальность тут ни при чем.

cemick, нет слов ..     чудеса  

Это сообщение отредактировал(а) mes - 7.4.2009, 01:21

Да, он с "любым методом" очень не красиво так делать.