В процедуру передаются объекты двух классов, у них названия методов немного различаются. Нужно как-то проверить наличие метода перед его вызовом. Можно ли так сделать?

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

es3000 писал(а) 15. Сентября 2006 :: 08:05:

А классический полиморфизм не подходит? Единый интерфейс классов сделать можно?

ИМХО
Если алгоритм подразумевает, что ему передается объект, поддерживающий метод "НекийМетод", и ему приходит объект, не поддерживающий этот метод, то такую ситуацию следут трактовать как ошибку, и добиваться того, что бы ситуация впредь не повторялась, путем правки консерватории, а не лепить заплатки, "здесь играем, здесь не играем, а здесь рыбу заворачивали".

es3000
А чем, собственно, проверка типа не устраивает?

Тут с дизайна бы начать...

es3000 писал(а) 18. Сентября 2006 :: 08:39:

Ты недопонял, что я хотел сказать.
Как раз и не надо никаких ПопытокИсключений, и Если ТипЗначения.
Я пишу
об.Метод();
и все.
Если вдруг оказалось, что пришел объект без Метод(), вывалится ошибка, и дальше уже надо разбираться, как так вышло, что пришел объект без Метод(), а не городить огород с попытками.

Я вот тоже подумывал о реализации интерфейсов, но, похоже, 1С++ еще не дорос до этого уровня.

А пока я согласен с Орефковым. Если в коде объект.Метод() произошла ошибка, значит надо найти откуда она выросла.

И кстати, в качестве интерфейса достаточно определить пустой класс, наследовать от него и включить контроль типов. Тогда все эти ошибки и вылезут.

es3000
Хм... какова цель проверки?
Проверка в целях безопасности недавно обсуждалась.
Если же речь идет о Цитата:
, выход один - проверять тип. Причем, зачастую, достаточно проверить базовый тип объекта.

es3000 писал(а) 19. Сентября 2006 :: 07:21:

Недостаточно для чего?

зы: Предположим, в проекте есть сотня классов с методом "Добавить()". В некоторых классах метод добавляет строку в табличную часть документа, в других - добавляет новый элемент справочника и т.п. Т.е. без информации о типе объекта невозможно гарантировать правильность алгоритма.

es3000
Цитата:

Цитата:

Это новость! Как же мы работали до сих пор?

В любом случае, метод не может быть определен отдельно от интерфейса (класса).
Т.е. только имя метода, без типа, не позволяет нам идентфицировать поведение объекта.

orefkov
Я и подвожу автора к этой мысли

зы: хотя, сначала, речь шла, несколько, не об этом...

Цитата:


Согласен не совсем точно я выразился. 
Точнее будет так. Проверки типов будет недостаточно для написания универсальной обработки объектов, которые обеспечивают одинаковое поведение, но могут быть реализованы разными разработчиками и соотвественно могут иметь разные типы.
Опять же повторяю - тут придумывать нечего - для этого есть интерфейсы.

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


Цитата:

В 1С++ уже столько всего полезного сделано, что можно еще чуть-чуть добавить, чтобы превратить из Duck Interface в нормальную систему.

es3000

Цитата:

Хех... Типы, значит, могут быть разными, а сигнатуры (не говоря уже о назначении) этих методов разными быть не могут?

Цитата:

Вот чудак-человек! Как нету?! Сам же пишешь про Duck Interface!

Ладно, резюмирую еще раз:
- если речь [все еще ] идет о вопросе в начале ветки, то проверки типов не избежать. При этом проверять наличие метода уже не требуется.
- если речь идет об объектах, имеющих абсолютно одинаковые снаружи методы, проверять вообще ничего не требуется: Duck Interface в действии.

es3000
Да я в курсе про интерфейсы.
Только, какое они имеют отношение к 1С и 1С++?

es3000 писал(а) 19. Сентября 2006 :: 12:42:

Ты будешь долго смеяться, но такой метод уже есть - у класса MetaInfoClasses. Хотя и имеет ограниченную ценность: Цитата:

es3000 писал(а) 19. Сентября 2006 :: 11:04:


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

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

Цитата:


Так пожалуйста. 1С++ поддерживает множественное наследование. Так что никто не мешает тебе реальные классы наследовать в том числе от пустых - интерфейсов.

PS. Кстати, совем недавно пол дня промучился с тем, что не мог выловить ошибку - не возникало исключения, хотя процесс исполнения прерывался. И я никак не мог найти, где  же возникает ошибка. Осложнялось еще все тем, что в классах нет отладки. Оказалось, что после того, как поймаешь исключение, возникшее в методе, вызванном через Делегат, следующие исключения генерируются, но с пустым сообщением. Вообщем, удовольствие еще то.

Вывод. Плохо, когда не возникает исключений там, где они должны быть.

PPS. О! Кстати! Сегодня не менее часа искал ошибку. Оказалость в вызове метода пропустил запятую. Стоило включить проверку типов - и ошибка как на ладони!

Я не против метода. Я против неправильного его использования.

С другой стороны, чувствую, что есть подвох в твоем варианте использования, но пока не знаю какой. 

ИМХО, если метод проверки наличия метода   будет - никому от этого хуже не станет. На сегодняшний момент "Попытка" является единственным гарантированным методом определения. К сожалению, введя обработку исключений, в 1С не озаботились определением типа возникшего исключения. Потому нельзя сказать, возникло ли исключение потому что метода нет, или в самом методе ошибка. Наверно, именно это имели в виду предыдущие ораторы, когда орали на попытку.

Чтоб реабилитировать попытку и утиные интерфейсы, приведу контр-пример (считаем, что 1С++/формэкс у нас нет): необходимо выполнять некие действия над справочником/документом, действия выбираются из меню, меню вызывается по кнопке на форме. При этом часть действий одинаковая для объектов разного типа, часть - различная (например, справочник провести нельзя). Кнопка может располагаться  в формах: документа, элемента справочника; а также в списках(журналах) - в  последнем случае должны вызываться действия над текущей записью. 
Так вот, логично было бы все это дело оформить как процедуру в ГМ, а в формы повставлять кнопку с ее вызовом с передачей контекста. Однако тут встает проблема определения допустимых действий: по типу-низя (ТипЗначения переданного контекста - ГрупповойКонтекст). Можно конечно еще одним параметром передать "что это" (но чем меньше параметров, тем лучше), или вообще сделать разные процедуры для разных форм (но тогда дублируем код для общих действий). Вот-тут то и подойдет "Попытка" как средство определения типа:

Попытка
    Конт.НачалоИнтервала();
	Объект=Конт.ТекущийДокумент;
	ЭтоДок=1;
	ЭтоСписок=1;
Исключение
	Попытка
	    Объект=Конт.ТекущийДокумент();
		ЭтоДок=1;
	Исключение
		Попытка
		    Объект=Конт.ТекущийЭлемент();
			ЭтоСпр=1;
		Исключение
			ЭтоКакаяТоФигня=1;
			Возврат;
		КонецПопытки;
		Попытка
		    Конт.ПолучитьОтбор();
			ЭтоСписок=1;
		Исключение
		КонецПопытки;
	КонецПопытки;
КонецПопытки;
 

Вот такая вот лесенка. Если ходит как утка и крякает, как утка - то это утка и есть. И значит плавать должна тоже.