Принципы ООП в 1С (pattern Iterator)

Программирование - Практика программирования

ООП pattern Iterator Iterator GoF pattern ООП в 1С

17
Iterator или курсор, один из паттернов который реально применяю в повседневной жизни.

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

Для Каждого Стр Из Таб Цикл
	// Выполняем какие-то действия с Стр
КонецЦикла;

Ок написали цикл и все хорошо, через какое-то время появляется необходимость в алгоритме получить номер строки (элемента если у нас массив), что мы делаем, добавляем счетчик

Счетчик = 0;
Для Каждого Стр Из Таб Цикл
  // Выполняем какие-то действия с Стр
  Счетчик = Счетчик +1;
КонецЦикла;

Можно конечно и так

Для а = 0 По Таб.Количество()-1 Цикл
  // Выполняем какие-то действия
КонецЦикла;

но тогда нам нужно по всему телу цикла менять Стр на Таб[а] или в начале объявлять  Стр = Таб[а]; т.е. обеспечивать совместимость изменений со старой реализацией. 

И в первом примере с объявлением переменной счетчик и во втором с Стр = Таб[а]; обе переменные избыточные, вы вынуждены были их ввести т.к. изменился алгоритм. 

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

А если нам нужно коллекцию перебрать в обратной последовательности? А если нужно сортировать массив? Начинаем городить огород и причем этот огород в каждом месте нашего проекта, где потребовалось, там и сделали. 

Эти все проблемы решает паттерн курсор.

Курсор = Обработки.КурсорТаблицаЗначений.Создать().Конструктор(Таб).Имплементация("КурсорИнтерфейс");
Пока Курсор.Следующий() Цикл
  // Выполняем какие-то действия
КонецЦикла;

Обращение к текущему элементу Курсор.ТекущийЭлемент(), обращение к индексу Курсор.ТекущийИндекс(), хотите делаете метод Сортировать(), хотите делаете сеттер а-ля  Курсор.ОбратныйПеребор(Истина) и бог его знает что вы еще добавите в курсор и эта ваша фишка будет доступна для любых коллекций, таблица значений, массив, структура и прочие. Единственное будут меняться реализации курсора, например

Курсор = Обработки.КурсорМассив.Создать().Конструктор(МойМассив).Имплементация("КурсорИнтерфейс");
Пока Курсор.Следующий() Цикл
  // Выполняем какие-то действия
КонецЦикла;

 

Если свою реализацию положить на диаграмму классов получим.

т.е. из классической схемы убран агрегатор в квази ООП он кажется избыточным.

17

Скачать файлы

Наименование Файл Версия Размер
Принципы ООП в 1С (pattern Iterator): Пример реализации
.zip 7,76Kb
08.08.18
1
.zip 7,76Kb 1 Скачать

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. PerlAmutor 32 12.07.18 20:59 Сейчас в теме
Под пиво покатит.
На продакшене, увидев подобное я бы погрузился в древнерусскую тоску.

Практически новый метод обфусцировать код. Спасибо за труды.
talych; monkbest; sbcode; Gorus; Dimz_z; Dragonim; palsergeich; yelloo; pm74; wbazil; RainyAugust22; LexaSH; yurii_host; +13 Ответить
2. lazarenko 175 13.07.18 09:52 Сейчас в теме
(1)
я бы погрузился в древнерусскую тоску.

почему? )))
9. VladimirL 828 13.07.18 14:12 Сейчас в теме
(2) Потому что мы не привыкли мыслить концепциями ООП и платформа не дает для этого удобных инструментов. Применение ООП фактически идет против сложившейся культуры разработки и, как правило, избегается. По той же причине последние версии БСП кажутся сложными. Как Вы замечали в предыдущих публикациях, там ряд подходов ООП реализован, но с помощью тех возможностей процедурного программирования, которые дает платформа. Поэтому код действительно запутан, а в для реализации позднего связывания часто применяется оператор "Выполнить", усложняющий отладку.

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

Надеюсь продолжите публикации на эту тему.
talych; babys; CyberCerber; Volfy; lazarenko; +5 Ответить
10. brr 174 13.07.18 15:57 Сейчас в теме
(9) Может разработчики 1С посмотрят на творящийся ужас и скажут: "давай дадим им ООП"
thevist; talych; CyberCerber; yurii_host; +4 Ответить
16. VladimirL 828 13.07.18 21:18 Сейчас в теме
(10) Кажется, что сейчас у них в приоритете EDT и развитие GUI. Еще судя по партнерскому форуму из планов не убирают переход на микросервисную архитектуру 8.4 и переписывания кучи кода серверной части на Java. Из этого направления пока что только RAS, RAC и система взаимодействия живыми вышли ))

На развитие самого языка скорее всего ресурсов не хватает, и оно идет в основном по пути переноса ряда функций БСП на уровень платформы. Да и появление ООП в платформе было бы спорным решением для российского рынка. Текущие позиции на рынке держатся во многом за счет простоты языка. Если только борьба за международный рынок заставит над развитием языка в этом направлении поработать, как сейчас заставляет работать над EDT.
18. boln 986 15.07.18 04:24 Сейчас в теме
(16)
Текущие позиции на рынке держатся во многом за счет простоты языка.
Крайне сомнительно. На 1С программируют уже давно не "домохозяйки".
thevist; babys; Gesperid; brr; CyberCerber; +5 Ответить
21. brr 174 16.07.18 12:00 Сейчас в теме
(16)Простота языка уже мешает, сложность конфигураций выросла, язык должен соответствовать.
pfilyk; boln; talych; Gesperid; +4 1 Ответить
34. babys 83 18.07.18 12:11 Сейчас в теме
(21) Ну тут надо ориентироваться скорее на то, что язык прикладной и насыщать его бизнес функциями как VB for Office, а не тупо гнать в универсальность, не важно с ООП или без оного.
А как пример функциональной простоты С-- можно глянуть :)
3. Synoecium 399 13.07.18 11:07 Сейчас в теме
Ок написали цикл и все хорошо, через какое-то время появляется необходимость в алгоритме получить номер строки (элемента если у нас массив)

используйте тогда метод Индекс(), он почти во всех коллекциях есть
5. lazarenko 175 13.07.18 11:18 Сейчас в теме
(3) ну как же, в самой очевидной коллекции - массив, нету.
6. Synoecium 399 13.07.18 11:33 Сейчас в теме
(5) есть метод, подходящий для массива уникальных значений: Найти(<Значение>)
7. lazarenko 175 13.07.18 11:51 Сейчас в теме
(6) и Вы считаете это не костыль?
8. Synoecium 399 13.07.18 12:23 Сейчас в теме
(7) костыль, по сути это поиск по значению, что медленнее обращения к переменной с индексом. Не умаляя достоинств вашего решения, я вспомнил пару решений, не описанных в статье, как без него обойтись.
4. Synoecium 399 13.07.18 11:12 Сейчас в теме
В первом примере, на какие грабли мы можем наступить, ну к примеру у нас тело цикла достаточно большое, где-то в середине мы (или другой разработчик) пишем Продолжить;, и все, нам эта строка поломала всю логику.

а тут можно просто инкрементировать счетчик в самом начале цикла - просто начинать не с 0, а с -1, либо уменьшать на 1 при получении элемента по индексу
rinat_alp2; +1 Ответить
11. sommid 13.07.18 16:06 Сейчас в теме
минус в том, что это не получится использовать везде, т.к. &НаКлиенте в УФ это не взлетит.. и там все равно будете писать как обычно, и только на сервере продвинуто )
а так идея интересная
вопрос еще в накладных расходах на лишний объект
monkbest; lazarenko; +2 Ответить
13. lazarenko 175 13.07.18 17:52 Сейчас в теме
12. Сурикат 183 13.07.18 16:11 Сейчас в теме
Подскажите, а зачем нам такие накрутки с имплементация , наследованием...?
Ведь на самом деле мы договариваемся, что наш класс должен содержать определенные методы и поля.

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

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

Но статьи хорошие
Спасибо вам!
l1ike; brr; +2 Ответить
14. lazarenko 175 13.07.18 18:06 Сейчас в теме
(12) Платформа это сделает уже при выполнении, скажет не внятное что-то типа "метод объекта не обнаружен", тут мы себя защищаем от такого и приводим к одному типу "интерфейс".
Вот два примера
1. Если мы заходим например динамически подсовывать обработки, например как в статье про observer (https://infostart.ru/public/858073) мы по хорошему тут же должны проверить сопоставима обработка с интерфейсом или нет.
2. Это удобно для случаев когда нам нужно привести к одному типу, например как в статье про pattern Chain of responsibility (https://infostart.ru/public/851798), там Handler приведен к типу интерфейса. К тому же если рассматривать текущий пример, допустим мы уберем имплементацию и напишем 2 курсора для массива и ТЗ, в одном из курсоров не захотим/забудем реализовать какой-то объект, например сортировку, т.к. он конкретно в нашей задаче не нужен, в целом не страшно, но уже теряется унификация, получится как сейчас у платформы, у какой-то коллекции есть метод Индекс() у какой-то нет. А вообще это ж пример как можно, понятно что можно и без интерфейса, можно вообще и без обработок.
32. lazarenko 175 18.07.18 08:59 Сейчас в теме
(14)
какой-то объект

какой-то метод*
24. l1ike 17.07.18 07:18 Сейчас в теме
(12) Чего только люди не придумают, чтобы не писать тесты.
26. starik-2005 1427 17.07.18 14:31 Сейчас в теме
(24) в Боинге тесты заменили ревизией кода - повысили производительность труда в 8 раз (Макконнелл, "Совершенный код").
27. l1ike 17.07.18 14:50 Сейчас в теме
(26) А если на хаскеле писать, то если скомпилировалось - значит нет ошибок )))
28. starik-2005 1427 17.07.18 15:06 Сейчас в теме
(27)
значит нет ошибок
Не факт. Если нет ошибок в типах, то это не значит, что их вообще нет:
Отличительная черта языка — серьёзное отношение к типизации; во многом в связи с этим язык назван в честь исследователя теории типов и изобретателя комбинаторной логики Хаскелла Карри.
29. l1ike 17.07.18 15:39 Сейчас в теме
(28) Остальные ошибки, как правило, проще отлавливаются приемочными тестами, либо при сдаче работ заказчику.
30. starik-2005 1427 17.07.18 16:11 Сейчас в теме
(29)
Остальные ошибки, как правило, проще отлавливаются приемочными тестами, либо при сдаче работ заказчику.
Не совсем так. В ходе исследований, на которые ссылается Макконнелл, выяснилось, что тесты обычно выявляют не более 30% ошибок, при этом ревью кода выявляет до 70%, что сопоставимо с парным программированием. В тестировании пользователями бета-версий выявляется до 97% ошибок, остальные 3% ошибок могут достаточно долго жить в проекте и не быть обнаруженными, что, понятное дело, влечет за собой риски от правильности результатов работы системы до уровня защищенности данных от атак хаккеров.
31. l1ike 17.07.18 16:58 Сейчас в теме
(30) Возможно, это конечно специфика именно конкретной предметной области и состояния конкретного проекта. На предыдущем месте работы я 2 года занимался именно ревью кода подрядчиков, и самый большой объем работы это работа вместо компилятора по контролю типов. На соответствие требованиям у нас проверяли аналитики, и ошибки когда считается не правильно были намного менее критичны чем когда на 40 заводах отгрузка встает из за того что где-то в общем модуле добавили Документ.Подразделение, а в каких-то документах подразделения нет.
15. boln 986 13.07.18 20:45 Сейчас в теме
Всячески приветствую исследования автора в применении паттернов GoF к 1С. Сам имею такие наклонности :)

Но в данном кейсе, ИМХО, все же есть момент "паттерн ради паттерна". Выгода для программиста весьма туманна, согласен с комментариями. Все-таки паттерны изобретаются не ради самих паттернов.
talych; Gesperid; Tavalik; CSiER; +4 Ответить
17. nicxxx 197 14.07.18 11:25 Сейчас в теме
Расскажите, кто-нибудь, автору про запятые. "т.е. из классической схемы убран агрегатор в квази ООП он кажется избыточным."
33. lazarenko 175 18.07.18 09:00 Сейчас в теме
19. nomadon 317 16.07.18 09:31 Сейчас в теме
Решение интересное, подойдет скорее для oscript, подбешивает писать в кавычках без автодополнения
20. CyberCerber 218 16.07.18 11:41 Сейчас в теме
Многих, наверное, пугает, вот эта страшная строка:
Курсор = Обработки.КурсорТаблицаЗначений.Создать().Конструктор(Таб).Имплементация("КурсорИнтерфейс");

А нельзя, может, и с потерей принципов, сделать такую реализацию?
Курсор = Курсоры.Создать(Таб);

Здесь Курсоры - это общий модуль. В метод Создать передаем нужную коллекцию, и, в зависимости от типа, возвращается та или иная обработка со своими реализациями методов работы с коллекциями.
Но у данной методики остается такой же недостаток, а именно отсутствие контекстной подсказки по методам. Решить это можно следующим образом:
Курсор = Обработки.КурсорИнтерфейс.Создать();
Курсор.Конструктор(Таб);

Тогда в переменной Курсор будет Объект.Обработка и все экспортные методы будут подсказываться.
Реализацию для каждого типа коллекций придется сделать не через наследование, а через агрегацию. Т.е. при вызове метода Конструктор в зависимости от типа переданной коллекции, в реквизит обработки, например, Реализация кладется та или иная обработка. И все методы обработки КурсорИнтерфейс будут выглядит так:
Функция Следующий() Экспорт
    Возврат Реализация.Следующий();
КонецФункции;

Т.е. обработка КурсорИнтерфейс будет что-то типа абстрактного класса с виртуальными методами.

P.S. Автор, хочу выразить благодарность за статьи по такой хорошей тематике и пожелать развития темы.
Артано; +1 Ответить
22. brr 174 16.07.18 12:02 Сейчас в теме
23. starik-2005 1427 16.07.18 13:55 Сейчас в теме
25. pun4er 17.07.18 08:38 Сейчас в теме
35. babys 83 18.07.18 12:25 Сейчас в теме
Это 4 или 5, которые мне попадались, попытка загнать 1С в рамки "классического" ООП :)

Пока всё остаётся на уровне "мне было надо, я сделал кусок".
Оставьте свое сообщение