Ликуем!

Товарищи. Я вам ничего не говорил, но хотел бы указать на один любопытный подкаст, слушать который нужно с отметки 16:10

Почему объектно-ориентированное программирование провалилось?

Ссылка на интересный обзор с интересными ссылками на классику и классиков.
Итак...
Почему объектно-ориентированное программирование провалилось?

XDTO-пакеты. Неименованные типы

В продолжение к посту XDTO-пакеты, xml, xml schema несколько слов о неименованных типах.

Давайте посмотрим, что будет, если в конструкторе XDTO-пакета к свойству добавить определение типа и, в свою очередь, добавить туда еще свойств:

Как видите, свойства "Адрес" и "Телефон" сложного типа ("ОбъектXDTO"). А телефон еще и списковый тип (я задал "Максимальное количество" равное трем).

XDTO-пакеты, xml, xml schema

«Гло́кая ку́здра ште́ко будлану́ла бо́кра и курдя́чит бокрёнка»
(первая ассоциация, пришедшая в голову
после прочтения "мана" о XDTO-пакетах)

Приветствую, многоуважаемый all!

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

С чего начинается?..

С чего начинаются XDTO-пакеты для неискушенного разработчика? Для меня они начались с вопроса: "А что это еще за хренотень в дереве метаданных?" И еще я знал, что это что-то про xml. Но мы начнем не с этого. А с объекта ФабрикаXDTO. Как можно догадаться из названия, это фабрика объектов (XDTO расшифровывается как XML Data Transfer Objects).

1C, ООП, DDD и дальше

Сегодня я хочу пригласить вас немного помечтать. А то что это мы все за код да за код. Давайте о жизни. Ну и о коде, конечно, тоже. Потому что какая жизнь у программиста без кода?

Вот недавно я прочел (если честно, еще дочитываю) очень увлекательную книжку с умным названием "Приемы объектно-ориентированного проектирования" за авторством знаменитой "Gang of Four". В книге идет речь о шаблонах проектирования. Кстати, рекомендую от всей души, если кто еще не читал. Сложно представить себе, что ООП можно изучать без таких простых и наглядных примеров использования, какие приводятся в этой книге. Честное слово, я бы ввел ее в школьную программу, может, и не в школьную, но в университетскую точно. А пытливому уму везде найдется польза и применение. Хоть 1С и не поддерживает ООП в полной мере, но и нашему брату, 1С-нику, крупицу истины из нее почерпнуть не грех.

А теперь давайте про 1С и ООП. Когда-то (до 19 октября 2005) Википедия про язык 1С утверждала, что:

Данный язык является интерпретируемым объектно-ориентированным языком высокого уровня.

(На самом деле это, конечно же, не так, но об этом позже.)
И добавляла, что:

Платформой предоставляется фиксированный набор базовых классов, на основании которых можно создавать любое количество порожденных классов, наследующих их свойства и методы. Разработчик имеет возможность определять собственные дополнительные процедуры и функции, а также свойства порожденных классов (с некоторыми ограничениями). Допускается только одна ступень наследования классов. Не допускается переопределение процедур, описанных в базовых классах.

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

А вот если бы!.. А вот если бы 1С была как Axapta или C++, например. Уж там-то наверняка полноценно поддерживается ООП, можно и шаблонов навертеть, объектную модель отгрохать - закачаешься. Только вот беда, у C++ порог вхождения выше. С 1С все просто: открыл конфигуратор - и ты уж программист. Сначала форму печатную поправил, потом расчет суммы подкорректировал, и пошло-поехало (ботинками не кидайтесь, пожалуйста, сам так начинал и еще кучу народа знаю такого же). А открой проект на C++ (сиплю-сиплю, а ничего не выходит) - чего-то не там переставил, и все - не компилируется в лучшем случае. Сложно и дорого. Потому-то 1С так мил сердцу мелкого бизнесмена, что не нужны заоблачные бюджеты на разработку, да и типовых конфигураций пруд пруди. Ну и нам, 1С-никам, заодно тепло и сухо. Но объектов хочется.

И вот недавно сама 1С подкинула интересную мысль. Помните релиз 8.2.14? Там, где общие реквизиты вернули. Так вот, что такое общие реквизиты с точки зрения ООП? Не что иное, как обычные свойства класса "Документы". Класс документы-то всеми подклассами наследуется, и свойства, стало быть, тоже. А что если разрешить не один уровень наследования от документов, а несколько? Вот это было бы здорово. Захожу я в конфигуратор (1Сv9, конечно же!), добавляю в документы группу "Товарные документы". Сразу в эту группу документов реквизиты добавляю, типа "Контрагент", "Опустил", "Принял" и ТЧ "Товары" с такими реквизитами - "Номенклатура", "Количество", "Цена". И тут же в модуле группы документов пишу код, что, мол, если количество поменялось - сумму пересчитать, если сумма - цену. Ну, вы все эти процедуры обработки реквизитов и сами по сто раз писали, чего я рассказываю. А потом уже в группе документов "Товарные документы" создаю "Приходную накладную", "Расходную накладную", ну и все, что положено. И у них все эти реквизиты и ТЧ уже есть - унаследовались от товарных документов. Просто волшебство и сплошной "ахалай-махалай" получается. Конечно, кое-где добавляю особенностей для каждого класса, реквизитов специфичных, но каркас работает общий. Удобно, черт возьми. Надо разрядность цены в товарных документах поменять - р-р-р-раз! - и поменял одним махом. Реквизит-то один. И код по обработке один. Так, по мелочи, потом пройтись останется. Ну, естественно, кроме группы "Товарные документы" делаю группу "Кассовые документы" из общего корня - "Документы". Там свои особенности, но общего тоже много. И так далее, и так далее.
Про то, что похожие фокусы со справочниками и другими объектами работают, говорить не буду: сами спокойно дофантазируете, если хотите.
Тут же, кстати, и общие модули немного разгрузятся. Есть модуль группы документов, там и обработки для этой группы документов можно разместить. Например, всякие поиски цен, обработки подборов и прочее. Оно ж все, по логике, к товарным документам относится, верно ведь? Вот пусть в модуле группы "Товарные документы" и лежит, чтобы долго не искать.
И подсистемы тоже как-то оборачиваются в новом свете. Теперь те же документы объединяются в группы с иерархией намного лучше, чем это делали подсистемы. Вот есть группа "Кассовые документы", и все, что относится к кассе, находится в ней. И это обоснованно с точки зрения наследования и структуры кода. Хотя с отношением к нескольким подсистемам проблема получается, но, наверное, и тут какое-то решение есть.
Конечно, это еще не полноценное ООП, но хороший шаг вперед. Или назад?

Давайте посмотрим, что Википедия сейчас пишет про 1С:

Данный язык является предварительно компилируемым предметно-ориентированным языком высокого уровня.

Ключевое слово тут "икра" предметно-ориентированным. На самом деле это очень важно. Именно предметно-ориентированность позволяет быть языку 1С "заумью с человеческим лицом". Когда такие понятия, как "документ" или "проводка", встроены в само ядро платформы, то всякие надуманные абстракции вроде классов и подклассов тихо бледнеют и не отсвечивают. В нормальных "больших" языках программирования тоже хотят так уметь. Даже целое направление придумали - DDD (русская Википедия, извините, об этом еще не в курсе). Так не испортим ли мы 1С, если начнем туда тянуть все эти наследования? Не знаю. Если бы я был разработчиком платформы (во куда хватил! но мы ж тут помечтать договорились, да?), я бы по-тихому все-таки протащил бы такую доменную сущность, как группы документов, не особо афишируя, что оно все торчит из ООП. В принципе, в рамках доменной модели (не путать с объектной) понятие "группа документов" вполне интуитивно понятно, ценно и достаточно функционально. Так что катастрофы тут не предвидится. Катастрофа предвидится, когда мы заговорим о множественном наследовании, но тут могу заметить, что это:

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

Частью! Так что нам тут бояться нечего, тут еще сами апологеты ООП до конца не определились.
Ну а не хочется вам с этими новомодными "группами документов" разбираться да все конфигурации переписывать - пожалуйста. Не наследуйте от групп, наследуйте от "Документы". И для вас как будто и ничего не поменялось. Вот вам, кстати, обратная совместимость.
Да... Много еще чего можно хорошего намечтать...

Оставляю вас за этим занятием и хочу пожелать вам хорошего дня и хорошего кода.

P.S.: Сильно не ругайте, если кто чем недоволен, о грубых ляпах пишите - буду исправляться.

Публикация на Infostart

Снова статические методы классов в 1С

Я совершенно напрасно переживал по поводу статических методов классов, которых мне (и не только мне) так не хватает. В версии 1С 8.2 у объектов метаданных есть "Модуль менеджера" и функции описанные в нем фактически и являются статическими методами классов. Во всяком случае их можно так использовать.
Те, кто все понял, дальше могут не читать, с остальными давайте разберемся подробнее.

Я сделал небольшой пример. База с тремя справочниками: "Номенклатура", "КатегорииЦен" и "Цены". Номенклатура хранит список товаров, справочник "КатегрииЦен" - просто классификатор категорий, а справочник "Цены" подчинен номенклатуре и имеет два реквизита: "Категория" и "Цена" (Число). Таким образом в нем хранится цена для конкретного товара и конкретной категории. Достаточно стандартная ситуация. (Конечно, это можно организовать и регистром сведений или еще как-нибудь, но для примера я взял справочник. Просто так.)

Скачать базу можно тут: StaticMethods.zip

А теперь самое главное. Обработка "УстановитьЦены" выводит два списка: список товаров и, при выборе конкретного товара, в правом списке будут отображены его цены по каждой категории (с возможностью редактировать).
Обычно для чтения цены пишут функцию вроде "ПолучитьЦену", на вход которой передается товар и категория (а может еще и валюта, единица измерения или много чего, в зависимости от ваших нужд) а на выходе у нее полученная цена. Иногда такую функцию пишут и для записи цены.

Если с самими функциями все понятно, то вопрос где их положить до недавнего времени оставался открытым. В 7.7 такая функция скорее всего попала бы в глобальный модуль. В результате чего глобальный модуль со временем превращался в неподъемное собрание функций. Можно было всякими ухищрениями класть функции в обработки или внешние файлы или строго соблюдать структуру и принципы комментирования глобального модуля. Все-равно это все оказывалось неудобным или мало эффективным.

В 8.1 появились общие модули (много! много! ;-) и это существенно упростило дело. Во всяком случае "помойка функций" стала расти намного медленнее и при грамотно организованной структуре общих модулей можно было быть уверенным, что другой программист найдет вашу хитрую функцию быстрее и сможет использовать ее повторно, а не писать свою. Что безусловно хорошо, так как код используется повторно. Ну, если он вообще будет что-то искать. ;-)

Однако, всегда хочется лучшего. Например, есть функции, которые относятся исключительно к какому-либо справочнику или документу, но нужны во всей конфигурации. Можно завести общий модуль по имени справочника, но не хотелось бы. Или можно было бы положить такие в модуль объекта. Но без объекта нельзя обратиться к модулю, а не всегда хочется тянуть целый объект из базы, когда достаточно ссылки (или ссылка вообще не нужна). Т.е. с одной стороны функции нужна привязка к "классу" объектов, а с другой, конкретный объект для работы функции не требуется. В ООП такая функция обязательно стала бы статическим методом класса, а в 1С 8.2 ее можно положить в "Модуль менеджера".
Обратите внимание на то, как я вызываю функцию "ПолучитьЦену" в обработке "УстановитьЦены":

НоваяСтрока.Цена = Справочники.Номенклатура.ПолучитьЦену(ТекущийТовар, Выборка.Ссылка);
 

Через менеджер справочника. Мне не нужен лишний общий модуль или какие-то другие ухищрения.
Конечно, если говорить конкретно о функции "ПолучитьЦену", то вы могли бы поместить ее и в модуль менеджера справочники "Цены" или даже в "КатегорииЦен" или еще как-нибудь. Все зависит от того как вы строите архитектуру вашего приложения и какие используете соглашения при разработке. Но в любом случае возможность создать "статический метод класса" у вас есть. Что на мой взгляд - прекрасно.

Спасибо за внимание и хорошего вам кода.

Публикация на Infostart.

Статические методы класса

Мне ужасно нехватает возможности создавать статические методы встроенных классов метаданных  в 1С.
Приходится использовать "общие модули", которые через некоторое время превратятся в помойку функций, как их не упорядочивай.

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

Что такое "технология COM"

Нашел интереснейший архив статей Архив статей "Что такое "технология COM"
Читается как детективный роман, захватывающее и интересное чтиво.
К тому же, несмотря на то, что статься о COM она очень хорошо наводит порядок в голове касательно того, что называется ООП. Все, кто не до конца понимают теорию ООП, возможно найдут для себя новый способ "прожевать" эту информацию, пропустив ее через COM.

P.S.: Однако, нужно признать, что у меня есть трудности с пониманием того, что такое "фабрика класса" в COM. Нужно будет обязательно вернуться к этим статьям.