[infostart] Принципы ООП в 1С

Шаблон проектирования visitor, по моему мнению весьма полезен для 1С. visitor или посетитель, данный шаблон решает задачу выноса бизнес логики из класса наружу. Приведу аналогию с принципом которому придерживаются разработчики БСП (да в принципе типовых конфигураций), если разработчик разрабатывая какой-то функционал предполагает, что какая-то чать может быть переопределена прикладными разработчиками, он выносит такие методы в переопределяемые общие модули. Переопределяемый общий модуль, это тот же модуль как и все остальные, просто в имени у него есть слово "Переопределяемый", т.е. у него так же нужно включать возможность изменения если захотим что-то переопределить. По большому счету, все это держится на чистых договоренностях. Шаблон проектирования visitor решает данную задачу тем, что бизнес логика (ту которую в дальнейшем будет переопределяться или вообще отдаваться полностью на откуп прикладных программистов) описывается в самом посетителе. Вариаций реализации Observer'а много, смысл сводится к одному, событийное взаимодействие двух и более объектов. Основные моменты данного шаблона, это 2 класса сущностей, observer и subject (много примеров где subject представлен как интерфейс observable). Оbserver это интерфейс обязующий имплементирующие классы иметь некий метод который subject будет вызывать (на схеме используемой в этой статье это notify). Subject или observable имеет три основных метода, это добавить подписчика, удалить подписчика и оповестить подписчиков, все, вот и весь шаблон. В данной статье будет рассмотрен пример реализации GoF паттерна проектирования decorator в среде разработки 1С. Основная цель данного шаблона, это возможность динамического расширения функциональности базового класса. Сразу оговорюсь, т.к. в 1С нет ООП, это будет не чистый пример реализации данного шаблона, однако свою задачу данный пример будет решать. Chain of responsibility или Цепочка обязанностей из wiki Шаблон рекомендован для использования в условиях: в разрабатываемой системе имеется группа объектов, которые могут обрабатывать сообщения определенного типа; все сообщения должны быть обработаны хотя бы одним объектом системы; сообщения в системе обрабатываются по схеме «обработай сам либо перешли другому», то есть одни сообщения обрабатываются на том уровне, где они получены, а - другие пересылаются объектам иного уровня. Прочитав когда-то давно книжку "Разработка управляемых форм", составил для себя такую схемку-напоминалку для обращения в процессе разработки. С тех пор не раз выручала и избавляла от необходимости лезть в гуглы.