| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
ООП
МЯУ © (2004-09-10 22:59:00)У меня куча наследников одного класса, в котором описано большое количество абстрактных методов. Все методы в implementation описывать не охота (где-то 2/3 из них будут состоять из begin...end). Можно ли как нибудь перед вызовом метода проверить, overriden ли он у потомка?
Суслик (2004-09-13 16:57:00) [1]
> [38] Суслик © (13.09.04 16:53)
Добавка.
Перенос методов в предка и переопределение их только в некоторых потомках есть способ эмуляции множественного наследования - ты в независимости от текущей иерархии классов можешь наделить класс общими с другими классами свойсвами. В дельфи есть еще один способ такой эмуляции - интерфейсы. Не спорю, что в данном случае может он и лучше - знать бы задачу.
Суслик (2004-09-13 16:53:00) [2]
> [37] Rem (13.09.04 16:45)
Тебе же надоело? :))
Если нет, то можно аргументированно пообсуждать.
Разберем твою фразу
> Ведь программисты Borland'а изначально не знали бизнес-специфики
> Ваших задач
Она лишена смысла в контексте того, что я сказал раньше про то, что неизвестна специфика задач.
Моя фраза была такой
>>Ты просто не можешь знать необходимый полиформизм.
Согласись, что ты действительно не можешь знать необходимый полиформизм. А не можешь, т.к. не знаешь задачу
Представь себе, что класс TElement, описывает все элементы системы. При этом суть игры такая, что любой элемент теоретически может выполнять любую роль. Вот! Пример! Например, в игре есть понятие "удар" (типа удар оружием).
В первой версии игры автор сделал как ты сказал - класс TWeapon с методом Strike. Все оружие он унаследовал от TWeapon. А вот представь, что во второй версии он хочет и табуретку наделить такаим свойством - чем плохо, за ножку и по голове. Но табуретка унаследована не от того класса, что делать. Ясно что - переделывать.
А вот представь, что все наследуется от TElement, у которого есть метод Strike. У многих классов он пуст. Переопределен только у оружия. Насколько проще реализовать возможность бить табуретом в этом случае?
Я не говорю, что надо делать так всегда. Твой пример с ВКЛ очень плох, просто ужасен - лужа все стерпит (с) (Игорь Шевченко)
Поэтому, давать советы делать глубокую иерархию можно только зная специфику задачи, вложенные в проект деньги, а как следствие перспективы проекта и пр. Ты этого знать не можешь - зачем утверждаешь, что делать все надо не так?
Rem (2004-09-13 16:45:00) [3]2 Суслик
Ну тогда садитесь, переписывайте VCL, включая в TObject все методы и свойства TEdit, TLabel, TPanel, TComponent, TClientSocket... и еще сотен других объектов. Ведь программисты Borland'а изначально не знали бизнес-специфики Ваших задач. И вообще они зря за VCL взялись! Скорее всего (я подозреваю!) они много напортачили. Их логика - не Ваша (Вы ведь часто на Borland ругаетесь, признайтесь! ;)
Когда будет готово - выкладывайте в интернет Ваше универсальное хранилище. Вас признают!
Суслик (2004-09-13 16:38:00) [4]
> Мне надоела эта дискуссия...
а мне то как надоела :)))
Rem (2004-09-13 16:32:00) [5][32]
Если надо заправлять диван бензином - его надо порождать от класса TFueledObject. Или использовать предка более низкого уровня.
Надо не подстраиваться под ошибки, а исправлять их.
Если проблемы возникают на столь раннем этапе - то потом их будет во много раз больше.
Мне надоела эта дискуссия...
Суслик (2004-09-13 16:28:00) [6]
> [33] Ega23 © (13.09.04 16:26)
Все может быть.
Давать советы пусть и с виду страшно умные нельзя не зная специфики.
Ega23 (2004-09-13 16:26:00) [7]Откуда ты знаешь, что автору точно не понадобится заправлять диван бензином. Очень может быть, что такая возможность в будущем предусмотрена, только для нее не написан пока функционал?
Гм, ну если данная игра что-то навроде ГЭГа, то вполне возможно...
Суслик (2004-09-13 16:23:00) [8]
> [26] Rem (13.09.04 16:11)
> Использование обсуждаемых здесь методов - грубое нарушение
> ООП
Рискую перевести пост в потрепаться, но готов аргументированно поспорить.
Т.к. вы не автор вопроса, то вы не можете в должно мере владеть бизнес-логикой приложения. Ты просто не можешь знать необходимый полиформизм. Откуда ты знаешь, что автору точно не понадобится заправлять диван бензином. Очень может быть, что такая возможность в будущем предусмотрена, только для нее не написан пока функционал?
Ты так уверен в своей правоте, как будто сам вопрос задавал :))
Ega23 (2004-09-13 16:21:00) [9]суслик © (13.09.04 16:20) [29]
Да я уже понял, что ты про вторую фразу говорил.
Rem (2004-09-13 16:20:00) [10][21]
А через полгода, имея на руках только откомпилированный модуль, Вы будете на себя же ругаться, когда, набрав название объекта, получите от Delphi длиннейший список методов, большинство из которых ничего не делает. И будете вспоминать, что же именно этот объект должен делать. И будете кричать ему "фас, аппорт, сидеть, лежать", а он будет молчать и мило улыбаться в ответ...
суслик (2004-09-13 16:20:00) [11]
> [27] Ega23 © (13.09.04 16:14)
> Блин, а как же тогда вот это понимать:
Ты выкинул вторую фразу
>>если я не ошибаюсь try except имеют накладные расходы, которые больше, чем просто вызов пустой функции.
а без нее изменяется смысл поста.
Я говорил, что в данной ситуации лучше сделать так, а не так как хочет автор, т.е. с try excep
Прошу прощения, если ввел в заблуждение.
Суслик (2004-09-13 16:17:00) [12]
> [26] Rem (13.09.04 16:11)
Странный ты, е-мое.
Первая странность (вернее для данного форума норма, но для нормального человека все же нетипично) - отстутсвие внимания при чтении постов.
Вторая странность (опять же норма для форму, но не для жизни) - отсутсвие полезного совета в конкретной ситуации.
В данной ситуации решение с пустыми телами методов лучше чем тот ответ [1] с которым согласился автор вопроса. Вот и все. VMT и прочая безусловно полезная информация вполне могут быть и не использованы в данном случае. Несмотря на то, что мне самому подход автора не нравится все же рискнул дать конкретный совет (и даже сопроводил его доказывающим кодом) сделать не так, как хочет автор.
Ega23 (2004-09-13 16:14:00) [13]Блин, а как же тогда вот это понимать:
суслик © (13.09.04 15:37) [12]
лучше сделать все методы просто virtual с пустими телами, а не virtual abstract.
?
Я же именно про это в [13] спросил: "Чем лучше"?
Rem (2004-09-13 16:11:00) [14][17]
И Вам в том числе.
>>с какой стати
>>куча наследников одного класса... в котором описано большое количество... методов
С точки зрения затрат памяти: Что такое VMT Вам объяснять не нужно? Сколько памяти будут занимать "большое количество методов" в "куче наследников"?
С точки зрения семантики: Объект, который не может выполнить действие, не должен иметь метода, который предполагает это действие. Исключение - пустой метод в переопределенном классе, когда необходимо отменить какое-то действие. Иначе нет смысла этот метод определять. Директива abstract не спроста введена в Object Pascal.
С точки зрения Delphi: Сколько Warning'ов и Hint'ов выдаст компилятор? Или Warning'и и Hint'ы придумали в Borland'е от нечего делать? Или вы привыкли не обращать на них внимания?
С точки зрения ООП: Никто не отменял грамотное проектирование иерархии классов. Использование обсуждаемых здесь методов - грубое нарушение ООП.
Хотя, можно на это все не обращать никакого внимания. Пишите так, как пишите - и пусть пользователи (как вашей программы, так и классов) будут вам судьями.
Аминь!
Суслик (2004-09-13 16:11:00) [15]
> [24] Ega23 © (13.09.04 16:09)
а...
я это вроде не утверждал.
так что не знаю почему...
Ega23 (2004-09-13 16:09:00) [16]Суслик © (13.09.04 16:07) [23]
Нет, я спрашиваю почему virtual с пустым телом метода работает быстрее, чем vitual; abstract; без тела метода.
С try - except и так всё ясно.
Суслик (2004-09-13 16:07:00) [17]
> [22] Ega23 © (13.09.04 16:02)
Я что-то запутался.
Ты спрашиваешь почему в конкретном примере лучше не пользоваться try excet.
Как я понимаю, все дело в том, что try except имеет серьезные накладные расходы. Опять же насколько я понимаю structured exception handling реализован не в дельфи, а в ОС. В общем читай Рихтера, часть 5. Там было что-то про ресурсоемкость обработки исключений. Детали не помню
Ega23 (2004-09-13 16:02:00) [18]Суслик © (13.09.04 15:58) [21]
Блин, хорошо, перефразирую: "ПОЧЕМУ?"
Суслик (2004-09-13 15:58:00) [19]
> [20] Ega23 © (13.09.04 15:56)
> Суслик © (13.09.04 15:48) [14]
Чем, чем?
Тест запусти - разница в несколько порядков (в пять!). Вот и ответ.
> [19] Rem (13.09.04 15:56)
> LMD
еще один борец за чистоту :))
Ega23 (2004-09-13 15:56:00) [20]Суслик © (13.09.04 15:48) [14]
Ну может быть. Но речь-то о потомках и переопределённых методах, насколько я понял...
Я к тому, что я всегда такие методы через virtual; abstract; определял. Вот мне и интересно, чем просто virtual с пустым кодом может лучше быть...
| |
Страницы: 