Про 1С++ООП, на ночь глядя бесстыжими вочами

[Пиит]

Повторюсь, любой ТипДанных - это Класс.

А любой Класс это ТипДанных.

В ООБД каждый класс уложен в свою таблицу либо набор таблиц.
Конечно, есть таблица и для Корневого класса Класс, содержащая в себе перечень всех классов.

Что же, получается, для Числа есть своя таблица?
Конечно. Конструкция Число.Пи ничего не напоминает?
Это же наши бывшие Константы - ПредопределенныеЭлементы.

Такие же таблицы есть и у Строк, и у Дат, и у всех прочих Базовых классов и Наследников.
Для Базового класса в концепции ООП как-бы не должено существовать Суперкласса, но
в концепции ООБД мы можем несколько смягчить парадигму, чтобы не нарушать терминологию.
Всё-таки Базовые классы, как и Корневой, заложенны на уровне Машины, как положено, и именно на их основе идёт строительство репозитория.

В числе Базовых Классов/ТиповДанных, кроме примитивов Число, Строка, Дата и Булево, в обязательном порядке входят Структура, Массив, Дерево, Список, Таблица (прошу не путать таблицы БД и Таблицы ООБД), Форма, Макет и так далее.
Список этот ограничен только фантазией разработчика нашей ООСУБД, хоть Графы туда вставляй, лишь бы реализация не подвела...

На зародыш ОпределяемыеТипы не смахивает?

Так мы получили первую ветку Метаданных, под названием ТипыДанных, и можем уже начинать равивать своё дерево Классов. От Числа наследовать, например, Сумму, Количество, Курс, от Строки НаименованиеСпр, КомментарийДок, а от Отца Фамилию и Отчество...

Шутка, на ночь глядя.

[Злоп]

Давайте ближе к практике

[Пиит]

Давайте ближе к практике

А вот с практикой неувязочка вышла.
Весь мой личный опыт не выходит за рамки Конфигуратора.
Когда потух проект 2С, я даже пытался собрать коллектив
спецов, втолковать им что к чему, не вдохновились.
Смешно, спустя много лет, 15 может даже, встретил на улице товарища,
разболтались, и он мне грит: "Помнишь, ты мне втюхивал
про вложенные структуры данных? Так до меня только сейчас дошло!"
Я даже выходил на одного большого чиновника, который вкладывался
в стартапы, боялся за бескровно нажитое, разложил ему вопрос как
политический, мол бабло плывёт в Москву, 1С его в качель, импортозамещаем,
дёргаем за нитки, ставим на гос.предприятия, я эту 1С одной левой и т.д.
В общем, вложился он тогда в деревобработку. Сейчас сидит, давно уже, 9 лет дали.
Писали, что за 200т зелени взяли с поличным, но я не верю, хороший мужик.
Вот и вся история.

[Пиит]

Давайте ближе к практике

Сорри, дружище, затупил, не о той практике сперва подумал.
Нельзя писать на ночь глядя, кошмары в голову лезут, пригрезилось, что мой ник - Форум123.

Итак, что дают нам определяемые ТипыДанных/Классы.
Пример 1, примитивный, но очень показательный, из жизни.

В 2016 году у нас в РБ прошла денежная реформа, деноминация, замена купюр, и
появились настоящие железные копейки. Кто не знает, белорусские деньги называют
метким словом "белки" от того, что была в начале 90-ых такая купюра, 50 копеек с изображением белки,
а на рубле красовался соответсвенно заяц. Со временем "белка" была изъята из оборота, и на протяжении многих лет страна жила без копеек. Ессесно, в типовых конфигурация копеек тоже не было, везде ОКР(), [18.0] и т.д.

Представьте теперь, сколько труда потребовалось, чтобы добавить копейки во все щели в конфигурации.
В реквизиты вроде просто, а модули, где было кругом ОКР() и НоваяКолонка(, "Число", 15, 0), а печатные формы, где повсюду #Ч16.0, и, учитывая большое разнообразие этих 15.0, 17.0, 015.0 и т.д., работа была не из лёгких, персонально с каждой конфигурацией. По сей день всплывают, как эхо войны, то тут то там косяки с этими копейками.
А теперь представьте, что у нас есть некий ОпределяемыйТип "СуммаРуб", который задействован во всех реквизитах всех прикладных объектов. И ОКР() умеет округлять до собственной точности.
Проблема с деноминацией была бы решена одним щелчком....

[Пиит]

Пример 1, примитивный, но очень показательный, из жизни.

Пример 2, определяемые структуры.

Есть в v7 такой объект - Дебет/Кредит, тот который вложен в проводку, я называю его Корреспонденцией, хотя это не очень грамотно в контексте сложных проводок.
По сути это настоящий Объект, с собственными данными и интерфейсом.
А в прикладных объектах мы вынуждены постоянно рожать набор Счет, Субконто1,.., СубконтоХ,
и затем, в стотысячный раз, оформлять его на форме, в модуле и т.д.
Дело упростится в стотысяч раз, если мы определим такую структуру в нашей ветке ТиповДанных.
Итак, на базе класса Структура, создаем наследника - структуру Корреспонденция {Счет, Субконто1,.., СубконтоХ}, один раз пишем МодульОбъекта со всякими ПриВыбореСчета(), один раз рисуем ФормуОбъекта, со всеми Счет.ВидСубконто() и т.д.
А прикладной объект, например Справочник.ОсновныеСредства, будет у нас содержать один единственный для это дела реквизит "ЗатратыНаАмортизацию" типа Структура.Корреспонденция, доступный в контексте элемента через свой интерфейс, и доступный на форме элемента, как некая область вложенной формы.

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

[Пиит]

Пример 2, определяемые структуры.

Пример 3. ТабличныеЧасти, памяти Марка Порция Катона.

Аппологеты восьмерки считают несомненным достоинством наличие множества ТабличныхЧастей у объекта.
Так то оно вроде и так, только зачем выпячивать ТабличнуюЧасть из списка реквизитов, если в нашем
дереве определяемых ТиповДанных это всего лишь "один из", такой же, как и Число, и Структура.
В ветке ТипыДанных-Таблица создаем наследника, нужный нам в работе класс, например ТаблицаТоваров {Товар, Цена, Количество, Сумма}. Далее, как обычно, один раз описываем его модуль (ПриВыбореТовара(), ПересчетСтроки() и т.д.), один раз рисуем форму, и вуаля, можем во все складские документы добавить хоть двадцать реквизитов ТаблицаТоваров,..,ТаблицаУслуг типа соответствующих типов Таблица.ТаблицаТоваров и так далее.

К слову, ОбластьОбъекта в этом случае имеет право на свою ПанельИнструментов...

Что же мы имеем в итоге?
Учитывая, что в процессе развития прикладной конфигурации то и дело возникает необходимость "копнуть назад", например, добавить копейки, увеличить количество субконто в плане счетов, добавить НДС в складские документы, нам не потребуется бегать по всем прикладным объектам, достаточно поправить нужный нам ТипДанных/Класс, и ффсё...

ООБД таки, ептыть.

Ффсё, перерыв.

[АЛьФ]

Ля... концептуальные посты... Респект!

[Пиит]

Ля... концептуальные посты... Респект!

Спасибо, Алексей Леонидович!
Ваша оценка, как специалиста, который давно и плотно в этой теме, мне очень важна.
Это вдохновляет на новые подвиги, в отличие от неодуманных реплик, после которых, признаюсь, руки немного опускаются.

Эти посты - вторая причина, по которой я у Вас в гостях.
Представьте себе только, что я начну писать такие апокрифы на ИС, или даже на Icpp.
Там руки даже и не подымутся. Анафема будет навеки.

[Злоп]

"Понятно что здорово, но здорово непонятно!"

[Пиит]

1срр... на текущий момент это такой же неотъемлемый костыль для клюшек как и формекс. Я бы сказал штатный.

Не как ответ автору, а так, к слову.

Icpp входит в мой список обязательных для внедрения компонент.
В первую очередь меня интересует в ней класс MetaDataWork, доставший в наследство, насколько я понимаю, еще из Rainbow. Мне он нужен для получения идентификаторов Журналов, ОбщихРеквизитов и прочих метаданных, чьи идентификаторы я не могу извлечь обычным способом ЗначениеВСтрокуВнутр.
Мог бы обойтись и АктивМД, но там какие-то косяки есть, чего-то не выдает, не помню уже.
В дальнейшем я использую эти идентификаторы для РасшМетаданных, непосредственно в Предприятии,
для синхронизации с метаданными и собственно для безошибочного доступа к ним из прикладных объектов.
И уже на базе РасшМетаданных я разворачиваю необходимый мне для работы функционал, например,
ПредопределенныеЭлементы, ПриоритетныеЭлементы, Подмножества, Словари и СловарныеСвязи, ТиповыеДокументы, ПериодическиеРеквизитыДокументов и тому подобные.

Так вот, ключевая мысль: всё, что я привношу в конфигурацию, оцениваю критерием необходимости и достаточности, не для меня любимого, а для абстрактного разработчика, возможного приемника.
Наследовать в общем-то и нечего, проблемы повторения кода нет, пара-тройка функций в глобальном модуле, и забыл.
Так стоит ли ради этой пары-тройки функций разворачивать defcls, и обрекать твоего преемника,
возможно совсем неподготовленного к таким абстракциям, на головные боли?

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

[Пиит]

"Понятно что здорово, но здорово непонятно!"

Будете смеяться, элементы концепции ООБД есть уже в семерке.
Вот, например, Документ хранится в общем случае с двух таблицах,
в одной Шапка, а в другой ТабличнаЧасть.
А мог бы лежать и в трёх таблицах, кроме таблицы-шапки и таблицы-табчасти, могла быть и общая таблица для всех документов, эдакая таблица Класса. В эту таблицу можно было бы положить ИД, НомерДок, ДатаДок и .. ОбщиеРеквизиты. Я подозреваю, что ЛюдиВЖелтом об этом думали, но по каким-то причинам отказались, и решили ОбщиеРеквизиты добавлять и синхронизировать по всем таблицам-шапкам.

Так вот, в случае реализации трех таблиц для документа, это вполне бы походило на первое приближение к ООБД, если не рассматривать табличную часть как отдельный класс.

[АЛьФ]

"Понятно что здорово, но здорово непонятно!"

Будете смеяться, элементы концепции ООБД есть уже в семерке.
Вот, например, Документ хранится в общем случае с двух таблицах,
в одной Шапка, а в другой ТабличнаЧасть.
А мог бы лежать и в трёх таблицах, кроме таблицы-шапки и таблицы-табчасти, могла быть и общая таблица для всех документов, эдакая таблица Класса. В эту таблицу можно было бы положить ИД, НомерДок, ДатаДок и .. ОбщиеРеквизиты. Я подозреваю, что ЛюдиВЖелтом об этом думали, но по каким-то причинам отказались, и решили ОбщиеРеквизиты добавлять и синхронизировать по всем таблицам-шапкам.

Так вот, в случае реализации трех таблиц для документа, это вполне бы походило на первое приближение к ООБД, если не рассматривать табличную часть как отдельный класс.

Есть такая таблица - 1SJOURN.

[Пиит]

Есть такая таблица - 1SJOURN.

Ну вот, садись, Эдик, 2!

Да, мозг уже не тот, я ж говорил, надо готовиться к урокам. (

Откуда мне приснилось две таблицы?
Теперь точно, можно смеяться.

[Злоп]

Откуда мне приснилось две таблицы?
Теперь точно, можно смеяться.

- товарищи солдаты, вода кипит при 90 градусах!
- тщ прпарощик, вода кипит при 100 градусах!
- а, точно.. это я с прямым углом перепутал...

[Djelf]

Садись, тебе двойка!
100 градусов работает на уровне моря (да и то это слегка колеблется в зависимости от давления, и это усредненная величина), на 3000м поднимись вверх и будет тебе кипение при 90 градусах.

А вот про крокодилов, которые низенько летают - все чётко сказано!