ООП

← →
МЯУ (2004-09-10 22:59) [0]

У меня куча наследников одного класса, в котором описано большое количество абстрактных методов. Все методы в implementation описывать не охота (где-то 2/3 из них будут состоять из begin...end). Можно ли как нибудь перед вызовом метода проверить, overriden ли он у потомка?

← →
Defunct © (2004-09-10 23:14) [1]

Можно после вызова: ;)

Try
Obj.DoSomething;
Except
ShowMessage("Не перекрыт")
End;

PS: зачем создавать так много (2/3) ненужных методов?

← →
МЯУ (2004-09-12 12:52) [2]

Defunct © (10.09.04 23:14) [1]
спасибо, всё замечятельно теперь работает.

а с методами вот какая ситуация:
у меня игра в directx, элементы управленяя создаются как потомки класса ТэЕлемент, у которово определены абстрактные методы mousemove, click, dragdrop и т.п. Так что, например, у кнопки всего три реально используемых метода (маусдаун/ап и клик), а все остальные воще не нужны.
Мож, кто подскажет, как сделать лучше?

← →
icWasya © (2004-09-13 12:42) [3]

Ctrl+Shift+C
и все пустые методы создадуться сами

← →
Ega23 © (2004-09-13 13:15) [4]

Обзови как virtual и abstract и вообще не описывай. Описание нужно будет только у потомков.

← →
Rem (2004-09-13 13:36) [5]

Налицо нарушение наследования.
Создать базовый класс, в котором определено минимальное количество абстрактных методов. От него породить нужные классы.
Кроме этого, от него же определить нового абстрактного потомка, в котором добавлены новые абстрактные методы. И т. д.

TMyObjects --- TMyVehicle --- TMyBicycle
| TMyMotorcycle
| TMyCar --- TMyMercedes
| | --- TMyMazda
|
| --- TMyFurniture --- TMySofa
| | --- TMyTable
|
| --- TMyOffices --- TMyComputer
| --- TMyFax

← →
TUser © (2004-09-13 14:03) [6]

> а с методами вот какая ситуация:
> у меня игра в directx, элементы управленяя создаются как
> потомки класса ТэЕлемент, у которово определены абстрактные
> методы mousemove, click, dragdrop и т.п. Так что, например,
> у кнопки всего три реально используемых метода (маусдаун/ап
> и клик), а все остальные воще не нужны.
> Мож, кто подскажет, как сделать лучше?

Надо создавать не один наследник для всего на свете, а иерархию классов, где на разных уровнях и в разных классах вводить ссотв. методы. Тогда не будет ничего лишнего.

← →
Ega23 © (2004-09-13 14:17) [7]

Rem (13.09.04 13:36) [5]

В TMyMercedes мне больше всего My нравится... :о)

← →
МЯУ (2004-09-13 15:24) [8]

icWasya © (13.09.04 12:42) [3]
чего-то не создаются :(
а где нажимать-то?

Rem (13.09.04 13:36) [5]
это конечно круто, но тогда при оперировании всеми этими объектами придётся проверять принадлежность к тому или иному классу, что немного накладно. Скажем, пользователь выполнил действия, вызывающие метод "залить полный бак", нужно смотреть, машина ли щяс под курсором или какая-нибудь MySofa... Так что мне больше нравится вариант от Defunct с try/except.. Мож это и не по ООПэвски, но мороки меньше :)

← →
Ega23 © (2004-09-13 15:29) [9]

if (CurrentObject is TMyCar) then TMyCar(CurrentObject).Залить_Полный_Бак;

← →
Семен Сорокин © (2004-09-13 15:32) [10]

чего-то не создаются :(
Аськины шотакты отруби :)
а где нажимать-то?
в объявлении класса, можно через контекстное меню

← →
Rem (2004-09-13 15:36) [11]

[8]
Вот-вот... Указал пользователь объект, говорит: залить бак. Программа заливает, никаких проблем! Оказывается - диван! Куда лили, что лили, и во что это все вылилось? Программист доволен - никаких проверок делать не надо. Пользователь доволен - хохоту сколько - не программа, а анекдот!

И чего накладного в строке if (Object is TMyMercedes) then? Ни на йоту не накладнее try-except-end...

А так - какой-то Бейсик получается.

Если уж хочется простоты - используйте интерфейсы. Запросили интерфейс. Если получили - объект в состоянии выполнять определенные в интерфейсе действия. Не получили - значит этот объект этого делать всего этого не может... Но и тут не все так просто...

← →
суслик © (2004-09-13 15:37) [12]

лучше сделать все методы просто virtual с пустими телами, а не virtual abstract.

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

← →
Ega23 © (2004-09-13 15:41) [13]

лучше сделать все методы просто virtual с пустими телами, а не virtual abstract.

А чем лучше?

← →
Суслик © (2004-09-13 15:48) [14]

> [13] Ega23 © (13.09.04 15:41)

в смысле это лучше чем try except.

лучше по скорости, сравни

type tcl = class procedure aa; virtual; abstract; end; tcl1 = class procedure aa; virtual; end; procedure tcl1.aa; begin end; procedure TForm1.Button4Click(Sender: TObject); var c: tcl; c1: tcl1; kI: integer; kc, kca, kf: TLargeInteger; begin queryperformancefrequency(kf); c := tcl.create(); queryperformancecounter(kc); for kI := 1 to 10000 do begin try c.aa; except end; end; queryperformancecounter(kca); showmessage(format("%.8f", [(kca - kc) / kf])); c1 := tcl1.create(); queryperformancecounter(kc); for kI := 1 to 10000 do begin c1.aa; end; queryperformancecounter(kca); showmessage(format("%.8f", [(kca - kc) / kf])); end;

← →
Rem (2004-09-13 15:50) [15]

[12] Что такое грабли и как ими пользоваться.

Конструкция try-except-finally-end придумана не для выпрямления кривых рук программиста, а обработки исключительных ситуаций, которые происходят не по вине программиста.

Вызывать абстрактный метод и защищать вызов конструкцией try-except-end - проявление высшего дилетантства.

Если хотите кучу граблей - определите Application.OnException. И будет вам "счасте"...

← →
МЯУ (2004-09-13 15:53) [16]

суслик © (13.09.04 15:37) [12]

вызов try/except будет работать быстрее, чем 10 проверок типа "if (TMyObject is TMySofa) then"? блин, никогда бы не подумал. Ну да ладно, наверно всё же придётся переделать :)
или пустотелые методы сделать лучше?

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

← →
Суслик © (2004-09-13 15:53) [17]

> [15] Rem (13.09.04 15:50)

ты это мне?
Если да, то с какой стати?
Если нет, то почему [12] упомянул

← →
Суслик © (2004-09-13 15:54) [18]

> [16] МЯУ (13.09.04 15:53)

> или пустотелые методы сделать лучше?

я уже сказал, что в данном случае с учетом текущей реализации это лучше - меньше переделывать.
Сравни мой тест - разница в несколько порядков :)))

← →
Rem (2004-09-13 15:56) [19]

LMD

← →
Ega23 © (2004-09-13 15:56) [20]

Суслик © (13.09.04 15:48) [14]

Ну может быть. Но речь-то о потомках и переопределённых методах, насколько я понял...

Я к тому, что я всегда такие методы через virtual; abstract; определял. Вот мне и интересно, чем просто virtual с пустым кодом может лучше быть...

← →
Суслик © (2004-09-13 15:58) [21]

> [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 16:02) [22]

Суслик © (13.09.04 15:58) [21]

Блин, хорошо, перефразирую: "ПОЧЕМУ?"

← →
Суслик © (2004-09-13 16:07) [23]

> [22] Ega23 © (13.09.04 16:02)

Я что-то запутался.
Ты спрашиваешь почему в конкретном примере лучше не пользоваться try excet.

Как я понимаю, все дело в том, что try except имеет серьезные накладные расходы. Опять же насколько я понимаю structured exception handling реализован не в дельфи, а в ОС. В общем читай Рихтера, часть 5. Там было что-то про ресурсоемкость обработки исключений. Детали не помню

← →
Ega23 © (2004-09-13 16:09) [24]

Суслик © (13.09.04 16:07) [23]

Нет, я спрашиваю почему virtual с пустым телом метода работает быстрее, чем vitual; abstract; без тела метода.

С try - except и так всё ясно.

← →
Суслик © (2004-09-13 16:11) [25]

> [24] Ega23 © (13.09.04 16:09)

а...

я это вроде не утверждал.

так что не знаю почему...

← →
Rem (2004-09-13 16:11) [26]

[17]
И Вам в том числе.

>>с какой стати

>>куча наследников одного класса... в котором описано большое количество... методов

С точки зрения затрат памяти: Что такое VMT Вам объяснять не нужно? Сколько памяти будут занимать "большое количество методов" в "куче наследников"?

С точки зрения семантики: Объект, который не может выполнить действие, не должен иметь метода, который предполагает это действие. Исключение - пустой метод в переопределенном классе, когда необходимо отменить какое-то действие. Иначе нет смысла этот метод определять. Директива abstract не спроста введена в Object Pascal.

С точки зрения Delphi: Сколько Warning"ов и Hint"ов выдаст компилятор? Или Warning"и и Hint"ы придумали в Borland"е от нечего делать? Или вы привыкли не обращать на них внимания?

С точки зрения ООП: Никто не отменял грамотное проектирование иерархии классов. Использование обсуждаемых здесь методов - грубое нарушение ООП.

Хотя, можно на это все не обращать никакого внимания. Пишите так, как пишите - и пусть пользователи (как вашей программы, так и классов) будут вам судьями.

Аминь!

← →
Ega23 © (2004-09-13 16:14) [27]

Блин, а как же тогда вот это понимать:
суслик © (13.09.04 15:37) [12]

лучше сделать все методы просто virtual с пустими телами, а не virtual abstract.
?

Я же именно про это в [13] спросил: "Чем лучше"?

> [26] Rem (13.09.04 16:11)

Странный ты, е-мое.

Первая странность (вернее для данного форума норма, но для нормального человека все же нетипично) - отстутсвие внимания при чтении постов.

Вторая странность (опять же норма для форму, но не для жизни) - отсутсвие полезного совета в конкретной ситуации.

В данной ситуации решение с пустыми телами методов лучше чем тот ответ [1] с которым согласился автор вопроса. Вот и все. VMT и прочая безусловно полезная информация вполне могут быть и не использованы в данном случае. Несмотря на то, что мне самому подход автора не нравится все же рискнул дать конкретный совет (и даже сопроводил его доказывающим кодом) сделать не так, как хочет автор.

> [27] Ega23 © (13.09.04 16:14)
> Блин, а как же тогда вот это понимать:

Ты выкинул вторую фразу

>>если я не ошибаюсь try except имеют накладные расходы, которые больше, чем просто вызов пустой функции.

а без нее изменяется смысл поста.

Я говорил, что в данной ситуации лучше сделать так, а не так как хочет автор, т.е. с try excep

Прошу прощения, если ввел в заблуждение.

← →
Rem (2004-09-13 16:20) [30]

[21]
А через полгода, имея на руках только откомпилированный модуль, Вы будете на себя же ругаться, когда, набрав название объекта, получите от Delphi длиннейший список методов, большинство из которых ничего не делает. И будете вспоминать, что же именно этот объект должен делать. И будете кричать ему "фас, аппорт, сидеть, лежать", а он будет молчать и мило улыбаться в ответ...

> [26] Rem (13.09.04 16:11)

> Использование обсуждаемых здесь методов - грубое нарушение
> ООП

Рискую перевести пост в потрепаться, но готов аргументированно поспорить.

Т.к. вы не автор вопроса, то вы не можете в должно мере владеть бизнес-логикой приложения. Ты просто не можешь знать необходимый полиформизм. Откуда ты знаешь, что автору точно не понадобится заправлять диван бензином. Очень может быть, что такая возможность в будущем предусмотрена, только для нее не написан пока функционал?

Ты так уверен в своей правоте, как будто сам вопрос задавал :))

Откуда ты знаешь, что автору точно не понадобится заправлять диван бензином. Очень может быть, что такая возможность в будущем предусмотрена, только для нее не написан пока функционал?

Гм, ну если данная игра что-то навроде ГЭГа, то вполне возможно...

← →
Rem (2004-09-13 16:32) [35]

[32]
Если надо заправлять диван бензином - его надо порождать от класса TFueledObject. Или использовать предка более низкого уровня.

Надо не подстраиваться под ошибки, а исправлять их.

Если проблемы возникают на столь раннем этапе - то потом их будет во много раз больше.

Мне надоела эта дискуссия...

> Мне надоела эта дискуссия...

а мне то как надоела :)))

← →
Rem (2004-09-13 16:45) [37]

2 Суслик

Ну тогда садитесь, переписывайте VCL, включая в TObject все методы и свойства TEdit, TLabel, TPanel, TComponent, TClientSocket... и еще сотен других объектов. Ведь программисты Borland"а изначально не знали бизнес-специфики Ваших задач. И вообще они зря за VCL взялись! Скорее всего (я подозреваю!) они много напортачили. Их логика - не Ваша (Вы ведь часто на Borland ругаетесь, признайтесь! ;)

Когда будет готово - выкладывайте в интернет Ваше универсальное хранилище. Вас признают!

> [37] Rem (13.09.04 16:45)

Тебе же надоело? :))

Если нет, то можно аргументированно пообсуждать.

Разберем твою фразу

> Ведь программисты Borland"а изначально не знали бизнес-специфики
> Ваших задач

Она лишена смысла в контексте того, что я сказал раньше про то, что неизвестна специфика задач.

Моя фраза была такой
>>Ты просто не можешь знать необходимый полиформизм.

Согласись, что ты действительно не можешь знать необходимый полиформизм. А не можешь, т.к. не знаешь задачу

Представь себе, что класс TElement, описывает все элементы системы. При этом суть игры такая, что любой элемент теоретически может выполнять любую роль. Вот! Пример! Например, в игре есть понятие "удар" (типа удар оружием).

В первой версии игры автор сделал как ты сказал - класс TWeapon с методом Strike. Все оружие он унаследовал от TWeapon. А вот представь, что во второй версии он хочет и табуретку наделить такаим свойством - чем плохо, за ножку и по голове. Но табуретка унаследована не от того класса, что делать. Ясно что - переделывать.

А вот представь, что все наследуется от TElement, у которого есть метод Strike. У многих классов он пуст. Переопределен только у оружия. Насколько проще реализовать возможность бить табуретом в этом случае?

Я не говорю, что надо делать так всегда. Твой пример с ВКЛ очень плох, просто ужасен - лужа все стерпит (с) (Игорь Шевченко)

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

> [38] Суслик © (13.09.04 16:53)

Добавка.

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

ООП Найти похожие ветки