(UTC)
(Группа Модераторов: 1c++ moderator)
‹ Предыдущая Тема | Следующая Тема ›
Переключение на Главную Страницу Страницы: 1 ОтправитьПечать
Обычная тема О засадах Duck-интерфейсов (число прочтений - 2749 )
fez
Forum Administrator
1c++ power user
Отсутствует


I wanted to cry, but the
tears wouldn't come

Сообщений: 2712
Зарегистрирован: 19. Мая 2006
Пол: Мужской
О засадах Duck-интерфейсов
11. Октября 2006 :: 20:21
Печать  
Доделывал тут сегодня книгу продаж.
В одном специфическом случае в базе не было счета-фактуры, а было только поле в другом документе, в котором фиксировался номер счета-фактуры. Дата счета-фактуры совпадала с датой документа, и все остальные нужные данные тоже можно было получить из документа-основания.

Сделал "утиный" объект, который усиленно прикидывался счетом-фактурой. Возвращал все необходимое: контрагента, Итог("Сумма"), НомерДок, ДатаДок и даже Вид().

Все вроде бы работает (ошибок не выкидывает), но в моксель данные все равно не попадают.

Думал, думал, потом понял. Перед выводом в моксель данные собирались в таблице значений. А у таблицы значений соответствующее поле типизировалось, как "Документ".

P.S. Я давно не типизирую поля в своих таблицах значений, поскольку подспудно не люблю этого делать. Теперь мое подспудная нелюбовь получила веский довод Улыбка
  
http://fezeev.livejournal.com/
Наверх
www  
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: О засадах Duck-интерфейсов
Ответ #1 - 11. Октября 2006 :: 20:48
Печать  
Засада в неявном приведении типов имхо.
Не все ёгурты одинаково полезны.

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

Это как раз позволило бы управлять неявными преобразованиями типов и ловить подобные ошибки не отходя от кассы.

P.S.
Типизация не есть плохо - плохо, что ТЗ ничего не знает о классах и не умеет с ними работать.
Если, скажем, расширять ту же ИТ - так типизация вполне может дать положительный результат.
Только смысл ее не в неявном преобразовании, а в производительности, минимизации ресурсов и контроле ошибок.
  
De quelle planète es-tu?
Наверх
 
IP записан
 
fez
Forum Administrator
1c++ power user
Отсутствует


I wanted to cry, but the
tears wouldn't come

Сообщений: 2712
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: О засадах Duck-интерфейсов
Ответ #2 - 12. Октября 2006 :: 06:03
Печать  
[quote author=kms link=1160598062/0#1 date=1160599733]
Типизация не есть плохо - плохо, что ТЗ ничего не знает о классах и не умеет с ними работать.
Если, скажем, расширять ту же ИТ - так типизация вполне может дать положительный результат.
Только смысл ее не в неявном преобразовании, а в производительности, минимизации ресурсов и контроле ошибок.[/quote]
Я понимаю смысл типизации колонок числами. Строками. Ну датами.
Для всего вышеперечисленного.

Но вот типизацию агрегатными обектами я не понимаю.
  
http://fezeev.livejournal.com/
Наверх
www  
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: О засадах Duck-интерфейсов
Ответ #3 - 12. Октября 2006 :: 06:58
Печать  
Да, для элементарных типов возможна конкретная оптимизация скорости и ресурсов.
Сейчас, к примеру, целое число в 32 бита занимает 84 байт в CValue, а могло бы занимать 4.
Строка занимает 84 байта + размер CString, а могло бы эти 84 байта не занимать - и т.д.

А для агрегатов - это контроль ошибок.
Я вообще против неявных преобразований - по крайней мере, необрабатываемых в классе.

Т.е. как могло бы быть:
Пусть есть  экземпляр класса Расходная_Накладная - наследник документа.
При приведении его к типу "дата", к примеру, пусть вызывается процедура "ПреобразованиеКТипу_Дата()" класса.
И в этой процедуре и осуществляется собственно преобразование или генерация ошибки.

При отсутствии определенных процедур преобразования - должна генерироваться ошибка.
  
De quelle planète es-tu?
Наверх
 
IP записан
 
fez
Forum Administrator
1c++ power user
Отсутствует


I wanted to cry, but the
tears wouldn't come

Сообщений: 2712
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: О засадах Duck-интерфейсов
Ответ #4 - 12. Октября 2006 :: 15:39
Печать  
kms писал(а) 12. Октября 2006 :: 06:58:
А для агрегатов - это контроль ошибок.

Как показал мой случай - типизация агрегатов может ПОРОЖДАТЬ ошибки. Так "зачем нам типизация в насквозь нетипизированном языке?" (с) уже не знаю чей Улыбка

kms писал(а) 12. Октября 2006 :: 06:58:
Пусть есть  экземпляр класса Расходная_Накладная - наследник документа.
При приведении его к типу "дата", к примеру, пусть вызывается процедура "ПреобразованиеКТипу_Дата()" класса.
И в этой процедуре и осуществляется собственно преобразование или генерация ошибки.

При отсутствии определенных процедур преобразования - должна генерироваться ошибка.


Мысль здравая. Естественно, это должно работать для любого КОП, и как мне кажется, при отсутствии процедуры преобразования должна работать системная функция преобразования. А иначе не будет обратной совместимости.
  
http://fezeev.livejournal.com/
Наверх
www  
IP записан
 
Переключение на Главную Страницу Страницы: 1
ОтправитьПечать
‹ Предыдущая Тема | Следующая Тема ›
 
  « Главная ‹ Раздел Вверх  



Valid RSS Valid XHTML Valid CSS Powered by Perl Source Forge