Принципы ООП в 1С (pattern Iterator)
Программирование - Практика программирования
Задача данного шаблона это унифицировать алгоритмы работы с коллекциями. Приведу несколько примеров, есть таблица значений нам нужно обойти ее
Для Каждого Стр Из Таб Цикл
// Выполняем какие-то действия с Стр
КонецЦикла;
Ок написали цикл и все хорошо, через какое-то время появляется необходимость в алгоритме получить номер строки (элемента если у нас массив), что мы делаем, добавляем счетчик
Счетчик = 0;
Для Каждого Стр Из Таб Цикл
// Выполняем какие-то действия с Стр
Счетчик = Счетчик +1;
КонецЦикла;
Можно конечно и так
Для а = 0 По Таб.Количество()-1 Цикл
// Выполняем какие-то действия
КонецЦикла;
но тогда нам нужно по всему телу цикла менять Стр на Таб[а] или в начале объявлять Стр = Таб[а]; т.е. обеспечивать совместимость изменений со старой реализацией.
И в первом примере с объявлением пременной счетчик и во втором с Стр = Таб[а]; обе переменные избыточные, вы вынуждены были их ввести т.к. изменился алгоритм.
В первом примере, на какие грабли мы можем наступить, ну к примеру у нас тело цикла достаточно большое, где-то в середине мы (или другой разработчик) пишем Продолжить;, и все, нам эта строка поломала всю логику.
А если нам нужно коллекцию перебрать в обратной последовательности? А если нужно сортировать массив? Начинаем городить огород и причем этот огород в каждом месте нашего проекта, где потребовалось, там и сделали.
Эти все проблемы решает паттерн курсор.
Курсор = Обработки.КурсорТаблицаЗначений.Создать().Конструктор(Таб).Имплементация("КурсорИнтерфейс");
Пока Курсор.Следующий() Цикл
// Выполняем какие-то действия
КонецЦикла;
Обращение к текущему элементу Курсор.ТекущийЭлемент(), обращение к индексу Курсор.ТекущийИндекс(), хотите делаете метод Сортировать(), хотите делаете сеттер а-ля Курсор.ОбратныйПеребор(Истина) и бог его знает что вы еще добавите в курсор и эта ваша фишка будет доступна для любых коллекций, таблица значений, массив, структура и прочие. Единственное будут меняться реализации курсора, например
Курсор = Обработки.КурсорМассив.Создать().Конструктор(МойМассив).Имплементация("КурсорИнтерфейс");
Пока Курсор.Следующий() Цикл
// Выполняем какие-то действия
КонецЦикла;
Если свою реализацию положить на диаграмму классов получим.
т.е. из классической схемы убран агрегатор в квази ООП он кажется избыточным.
Скачать файлы
| Наименование | Файл | Версия | Размер | |||
|---|---|---|---|---|---|---|
|
Принципы ООП в 1С (pattern Iterator): Пример реализации
.zip 7,76Kb
12.07.18
1
|
.zip | 7,76Kb | 1 | Скачать Купить установку от 1700р |
См. также
На продакшене, увидев подобное я бы погрузился в древнерусскую тоску.
Практически новый метод обфусцировать код. Спасибо за труды.
Публикации на самом деле интересные. Применение паттернов в 1С скорее всего усложнит код в случае решения простых задач. Но в случае решения сложных задач или написании библиотек может помочь и сделать решение более гибким. Или даже упростить решение. Непривычность кода тогда можно преодолеть через его документирование и комментирование.
Надеюсь продолжите публикации на эту тему.
На развитие самого языка скорее всего ресурсов не хватает, и оно идет в основном по пути переноса ряда функций БСП на уровень платформы. Да и появление ООП в платформе было бы спорным решением для российского рынка. Текущие позиции на рынке держатся во многом за счет простоты языка. Если только борьба за международный рынок заставит над развитием языка в этом направлении поработать, как сейчас заставляет работать над EDT.
а тут можно просто инкрементировать счетчик в самом начале цикла - просто начинать не с 0, а с -1, либо уменьшать на 1 при получении элемента по индексу
а так идея интересная
вопрос еще в накладных расходах на лишний объект
Ведь на самом деле мы договариваемся, что наш класс должен содержать определенные методы и поля.
Метод имплементация проверяет, что соглашения выполнены. Но ведь и платформа это тоже проверит, когда не найдет нужный метод и вызовет исключение.
На мой взгляд наша цель дополнительно зафиксировать соглашения, что в красивом виде платформа сделать не позволяет.
И подобный стиль написания кода тоже.
Но статьи хорошие
Спасибо вам!
Вот два примера
1. Если мы заходим например динамически подсовывать обработки, например как в статье про observer ( мы по хорошему тут же должны проверить сопоставима обработка с интерфейсом или нет.
2. Это удобно для случаев когда нам нужно привести к одному типу, например как в статье про pattern Chain of responsibility (, там Handler приведен к типу интерфейса. К тому же если рассматривать текущий пример, допустим мы уберем имплементацию и напишем 2 курсора для массива и ТЗ, в одном из курсоров не захотим/забудем реализовать какой-то объект, например сортировку, т.к. он конкретно в нашей задаче не нужен, в целом не страшно, но уже теряется унификация, получится как сейчас у платформы, у какой-то коллекции есть метод Индекс() у какой-то нет. А вообще это ж пример как можно, понятно что можно и без интерфейса, можно вообще и без обработок.
Но в данном кейсе, ИМХО, все же есть момент "паттерн ради паттерна". Выгода для программиста весьма туманна, согласен с комментариями. Все-таки паттерны изобретаются не ради самих паттернов.
Курсор = Обработки.КурсорТаблицаЗначений.Создать().Конструктор(Таб).Имплементация("КурсорИнтерфейс");А нельзя, может, и с потерей принципов, сделать такую реализацию?
Курсор = Курсоры.Создать(Таб);Здесь Курсоры - это общий модуль. В метод Создать передаем нужную коллекцию, и, в зависимости от типа, возвращается та или иная обработка со своими реализациями методов работы с коллекциями.
Но у данной методики остается такой же недостаток, а именно отсутствие контекстной подсказки по методам. Решить это можно следующим образом:
Курсор = Обработки.КурсорИнтерфейс.Создать();
Курсор.Конструктор(Таб);Тогда в переменной Курсор будет Объект.Обработка и все экспортные методы будут подсказываться.
Реализацию для каждого типа коллекций придется сделать не через наследование, а через агрегацию. Т.е. при вызове метода Конструктор в зависимости от типа переданной коллекции, в реквизит обработки, например, Реализация кладется та или иная обработка. И все методы обработки КурсорИнтерфейс будут выглядит так:
Функция Следующий() Экспорт
Возврат Реализация.Следующий();
КонецФункции;Т.е. обработка КурсорИнтерфейс будет что-то типа абстрактного класса с виртуальными методами.
P.S. Автор, хочу выразить благодарность за статьи по такой хорошей тематике и пожелать развития темы.
Просмотры 2779
Загрузки 0
Комментарии 35
Создание 12.07.18 18:18
Обновление 12.07.18 18:18
№ Публикации 865839
Рубрики Практика программирования
Кому Программист
Тип файла Архив с данными
Платформа Платформа 1С v8.x (все механизмы)
Конфигурация Не имеет значения
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Раздел учета Не имеет значения
Доступ к файлу Абонемент ($m)
Код открыт Да
