Полезный код для программистов 1С (часть 1). Управление свойствами элементов формы. Хранение копии данных реквизитов

05.10.19

Разработка - Инструментарий разработчика

У каждого программиста за время работы накапливается полезный инструментарий, которым он привык пользоваться. Естественно и у меня он тоже имеется. И вот решено было немного поделиться с сообществом. Возможно идеи не новые. Более того, допускаю, что реализованы они не самым оптимальным образом. Но ведь для этого сообщество и существует, чтобы делиться с ним, получая обратную связь.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
Шаблон + общие модуля
.zip 4,42Kb
23
23 Скачать (1 SM) Купить за 1 850 руб.

У каждого программиста за время работы накапливается полезный инструментарий, которым он привык пользоваться. Естественно и у меня он тоже имеется. И вот решено было немного поделиться с сообществом. Возможно идеи не новые. Более того, допускаю, что реализованы они не самым оптимальным образом. Но ведь для этого сообщество и существует, чтобы делиться с ним, получая обратную связь.

Содержание

Управление видимостью, доступностью и просмотром реквизитов формы

Преамбула. Еще в бытность работы в 7.7, а далее и в первых конфигурациях на 8.х совершенно точно не нравились процедуры и функции вроде "УстановитьВидимость" или "УстановитьДоступность" и т.п. В них собирались все элементы, по различным условиям устанавливалась видимость. Как правило в них условия выставлялись по бизнес-логике редактирования документа, например проверка по видам операций, различным условиям заполненности и т.д. В итоге один и тот же элемент мог встречаться несколько раз и конечные условия "почему он виден или доступен" приходилось вникать во всю логику. Но не сразу пришло понимание, как должно быть, как будет удобно. Были различные варианты. Но вот некоторое время назад, мы совместно с нашей командой остановились на представленном ниже варианте.

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

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

    Если НЕ Обработано.Найти(ИмяРеквизита) = Неопределено Тогда
        Возврат;
    КонецЕсли;
    Обработано.Добавить(ИмяРеквизита);

    Элементы    = Форма.Элементы;
    Объект        = Форма.Объект;

    #Область Наборы
    
    Если ИмяРеквизита = "Реквизиты" ИЛИ ПустаяСтрока(ИмяРеквизита) Тогда
        УстановитьУсловноеОформлениеРеквизита(Форма, Обработано, "Реквизит1");
        УстановитьУсловноеОформлениеРеквизита(Форма, Обработано, "Реквизит2");
    КонецЕсли;

    #КонецОбласти
    
    #Область Элементы
    
    Если ИмяРеквизита = "Ответственный" ИЛИ ПустаяСтрока(ИмяРеквизита) Тогда
        ОбщегоНазначенияКлиентСервер.УстановитьСвойствоЭлементаФормы(Элементы,
            "Ответственный", "ТолькоПросмотр", ЗначениеЗаполнено(Объект.Ответственный));
    КонецЕсли;

    #КонецОбласти 
    
    #Область ТабЧасть_Имя
    
    Если ИмяРеквизита = "ИмяТабличнойЧастиОтветственный" ИЛИ ПустаяСтрока(ИмяРеквизита) Тогда
        ОбщегоНазначенияКлиентСервер.УстановитьСвойствоЭлементаФормы(Элементы,
            "ИмяТабличнойЧастиОтветственный", "ТолькоПросмотр", ЗначениеЗаполнено(Объект.Ответственный));
    КонецЕсли;

    #КонецОбласти
    
    #Область Команды
    
    Если ИмяРеквизита = "КомандаЗаполнить" ИЛИ ПустаяСтрока(ИмяРеквизита) Тогда
        ОбщегоНазначенияКлиентСервер.УстановитьСвойствоЭлементаФормы(Элементы,
            "ТаблицаФормыЗаполнить", "Видимость", НЕ Объект.Проведен);
    КонецЕсли;

    #КонецОбласти 
    
КонецПроцедуры

&НаКлиентеНаСервереБезКонтекста
Процедура УстановитьУсловноеОформление(Форма, знач ИменаРеквизитов = "")

    Если ТипЗнч(ИменаРеквизитов) = Тип("Строка") Тогда
        Если ПустаяСтрока(ИменаРеквизитов) Тогда
            МассивИмен = Новый Массив;
            МассивИмен.Добавить("");
        Иначе
            МассивИмен = СтроковыеФункцииКлиентСервер.РазложитьСтрокуВМассивПодстрок(ИменаРеквизитов, ",");
        КонецЕсли;
    ИначеЕсли ТипЗнч(ИменаРеквизитов) = Тип("Массив") ИЛИ ТипЗнч(ИменаРеквизитов) = Тип("ФиксированныйМассив") Тогда
        МассивИмен = ИменаРеквизитов;
    Иначе
        Возврат;
    КонецЕсли;
 
    //Форма.ТолькоПросмотр = (Форма.СостоянияЗаблокировано.Найти(Форма.СведенияОЗаявкеСостояние) <> Неопределено);

    Обработано = Новый Массив;
    Для Каждого ИмяРеквизита Из МассивИмен Цикл
        УстановитьУсловноеОформлениеРеквизита(Форма, Обработано, СокрЛП(ИмяРеквизита));
    КонецЦикла;

КонецПроцедуры

// как использовать
УстановитьУсловноеОформление(ЭтотОбъект, "ИмяРеквизита");

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

Проверка изменений значений реквизитов формы

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

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

В примере приведен только код для формы, все общие модули в прикрепленном файле.

// Описание использования
//
//    1. Разместить команды из процедуры ИнициализацияФормы в соответствующую по смыслу процедуру формы (или вызвать метод из ПриСозданииНаСервере, ПриЧтенииНаСервере)
//    2. Добавить все сохраняемые реквизиты в процедуре СнятьКопиюОбъекта
//    3. Назначить обработчики ПриИзменении на сохраняемые реквизиты (см. ИмяРеквизитаПриИзменении)
//

&НаСервере
Процедура ИнициализацияФормы()
    
    РаботаСФормами.СоздатьРеквизитХраненияКопииДанныхФормы(ЭтаФорма);
    
    // прочие обработки
    <?>
    
    СнятьКопиюОбъекта(ЭтаФорма);
    
КонецПроцедуры

&НаКлиенте
Процедура ИмяРеквизитаПриИзменении(Элемент)
    Если СравнитьСКопиейОбъекта(ЭтаФорма, "Объект.ИмяРеквизита") Тогда
        Возврат;
    КонецЕсли;
    
    // прочие обработки
    
    СнятьКопиюОбъекта(ЭтаФорма);
КонецПроцедуры

#Область СлужебныеПроцедурыИФункции_КопияДанныхФормы

&НаКлиентеНаСервереБезКонтекста 
Процедура СнятьКопиюОбъекта(Форма)
    МассивРеквизитов = Новый Массив;
    МассивРеквизитов.Добавить("Объект.Дата");
    МассивРеквизитов.Добавить("Объект.Организация");
    МассивРеквизитов.Добавить("ИмяРеквизита");
    
    РаботаСФормамиКлиентСервер.СкопироватьДанныеФормы(Форма, МассивРеквизитов);
КонецПроцедуры

&НаКлиентеНаСервереБезКонтекста 
Функция СравнитьСКопиейОбъекта(Форма, ИмяРеквизита)
    Возврат РаботаСФормамиКлиентСервер.СравнитьСКопиейДанныхФормы(Форма, ИмяРеквизита);
КонецФункции

&НаКлиентеНаСервереБезКонтекста 
Функция ЗначениеИзКопииОбъекта(Форма, ИмяРеквизита)
    Возврат РаботаСФормамиКлиентСервер.ЗначениеИзКопииДанныхФормы(Форма, ИмяРеквизита);
КонецФункции

#КонецОбласти

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

Послесловие

На самом деле оригинального и сверхумного ничего в представленном коде нет, да и быть не может. Что придумал один человек, второй всегда повторит. Я с удовольствием выслушаю критику и внесу изменения. Надеюсь, код подкажется полезным кому-либо. И кстати, может уже кто-то трудится над созданием репозитория с "полезным" кодом? Используйте на здоровье, модифицируйте и т.д.
Версионирование данных инструментов на текущий момент не ведется. Пока не вижу смысла. Жизнь покажет.
На картинке изображен детский набор инструментов "Fisher-Price Disney's Handy Manny Talking Tool Box". Вдруг кому интересно )))).

инструментарий программиста программирование алгоритмы полезный код

См. также

SALE! 15%

Инструментарий разработчика Роли и права Запросы СКД Программист Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

10000 руб.

02.09.2020    159417    872    399    

861

SALE! 15%

Инструментарий разработчика Чистка данных Свертка базы Инструменты администратора БД Системный администратор Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Россия Платные (руб)

Инструмент представляет собой обработку для проведения свёртки или обрезки баз данных. Работает на ЛЮБЫХ конфигурациях (УТ, БП, ERP и т.д.). Поддерживаются управляемые и обычные формы. Может выполнять свертку сразу нескольких баз данных и выполнять их автоматически без непосредственного участия пользователя.

8400 7140 руб.

20.08.2024    7769    55    22    

66

Инструментарий разработчика Программист Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Инструмент для написания и отладки кода в режиме «1С:Предприятие». Представляет собой консоль кода с возможностью пошаговой отладки, просмотра значений переменных любых типов, использования процедур и функций, просмотра стека вызовов, вычисления произвольных выражений на встроенном языке в контексте точки останова, синтаксического контроля и остановки по ошибке. В консоли используется удобный редактор кода с подсветкой, контекстной подсказкой, возможностью вызова конструкторов запроса и форматной строки.

9360 руб.

17.05.2024    23434    68    45    

117

SALE! 15%

Инструменты администратора БД Инструментарий разработчика Роли и права Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

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

10000 8500 руб.

10.11.2023    10420    36    22    

61

SALE! 15%

Пакетная печать Печатные формы Инструментарий разработчика Программист Платформа 1С v8.3 Запросы 1С:Зарплата и кадры бюджетного учреждения 1С:Конвертация данных 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Платные (руб)

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

22200 19980 руб.

06.10.2023    15398    35    7    

70

SALE! 35%

Инструментарий разработчика Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Россия Платные (руб)

Универсальный инструмент программиста для администрирования конфигураций. Сборник наиболее часто используемых обработок под единым интерфейсом.

4800 3120 руб.

14.01.2013    187979    1138    0    

912

SALE! 15%

Инструментарий разработчика Программист 8.3.14 1С:Конвертация данных Россия Платные (руб)

Расширение для конфигурации “Конвертация данных 3”. Добавляет подсветку синтаксиса, детальную контекстную подсказку, глобальный поиск по коду.

15000 12750 руб.

07.10.2021    17303    6    32    

42

Инструментарий разработчика Программист Платные (руб)

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

1800 руб.

21.02.2023    7694    8    35    

23
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. pm74 203 24.09.17 21:43 Сейчас в теме
небольшая "подстава" от 1с , при программном изменении значений реквизитов в форме событие "приизменении" не вызывается
healplease; Светлый ум; +2 5 Ответить
2. vandalsvq 1587 24.09.17 23:15 Сейчас в теме
(1) ну это понятно, в таком случае обработка изменения уже забота программиста
Dementor; +1 Ответить
3. pm74 203 25.09.17 07:18 Сейчас в теме
(2) я просто имел в виду , было бы неплохо , если бы 1с случае любого локального события формы , генерировало какое то событие изменения данных формы которое можно было отловить
rpgshnik; +1 Ответить
4. Xershi 1555 25.09.17 07:40 Сейчас в теме
(3) Флаг модифицированность для этого!
5. pm74 203 25.09.17 07:50 Сейчас в теме
(4) и ? в какой момент его считывать ?
rpgshnik; +1 Ответить
9. Xershi 1555 25.09.17 09:30 Сейчас в теме
(5) какой алгоритм заложите такой и будет!
6. spacecraft 25.09.17 07:54 Сейчас в теме
(3) какое такое событие изменения реквизитов формы нужно отдельно отлавливать? Если программно изменяете реквизит, то и программно нужно запустить нужные обработчики, при необходимости.
Perfolenta; Dementor; +2 Ответить
7. pm74 203 25.09.17 08:04 Сейчас в теме
(6) автор правильно указал на проблему , если вы меняете реквизит у вас нет старого значения реквизита ,даже если он фактически не изменился генерируется событие при изменении
8. spacecraft 25.09.17 08:07 Сейчас в теме
(7) не ответили на вопрос. Какое событие нужно отлавливать отдельно? Если меняете программно реквизит, значит можете предусмотреть обработку логики изменения этого реквизита.
16. air_mike 25 27.09.17 08:59 Сейчас в теме
(7) Старое значение не куда не денется из базы, пока вы его не записали в базу. Согласен с (6).
В УФ специально убрали процедуры ПриВыводеСтроки и ОбновлениеОтображение, т.к. по уму они не нужны и приводят только к тормозам.
15. azhilichev 214 27.09.17 04:57 Сейчас в теме
(3) Как раз наоборот это правильное поведение. Не зря ПриОткрытии(), ПриИзменении() и т.п. называются обработчиками событий.
29. Darklight 33 04.12.17 11:40 Сейчас в теме
(2)Это большая подстава. Во-первых это очень неудобно - об этом нужно помнить и, в общем-то, проектировать сам код обработчиков тоже нужн особым образом - усложняя его - вынося обработчик изменения в ещё одну процедуру.
А во вторых - допустим форма была в другу функцию, не расположенную в модуле формы - и реквизит изменился там - то тот алгоритм, во-первых, ничего не знает об обработчиках этого реквизита в форме, во-вторых, даже если бы знал, с вероятностью близко к 100% не сможет сам вызвать этот обработчик - т.к. в 1С все процедуры в модулях по умолчанию не экспортные (private) и не могу быть вызваны из другого модуля, а программисты редко заботятся о том, как их алгоритм может использоваться другими алгоритмами вне модуля, где он написан. Даже алгоритмы в типовом коде об этом не думают - поэтому часто при переопределении алгоритма одной типовой процедуры - приходится либо выносить в отдельные модули копии ряда связанных, не изменяемых, но не экспортных типовых процедур, либо изменять их внутри типового кода - делая их экспортными.

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

Ну и все элементы модулей алгоритмов надо делать по умолчанию экспортными (public) - чтобы скрытыми их делал программист только тога - когда оно действительно должно быть скрыто!
1giga; ixijixi; karimov_m; +3 Ответить
10. tsukanov 25.09.17 13:49 Сейчас в теме
(1) Попробуйте это:
Процедура УстановитьЗначениеИнтерактивно(Значение, Элемент, Форма)
	Перем ВладелецФормы, ЗакрыватьПриВыборе;

	ВладелецФормы = Форма.ВладелецФормы;
	ЗакрыватьПриВыборе = Форма.ЗакрыватьПриВыборе;
	
	Форма.ВладелецФормы = Элемент;
	Форма.ЗакрыватьПриВыборе = Ложь;
	
	Форма.ОповеститьОВыборе(Значение);
	
	Если Форма.ВладелецФормы = Элемент Тогда
		Форма.ВладелецФормы = ВладелецФормы;
	КонецЕсли;
	
	Если Не Форма.ЗакрыватьПриВыборе Тогда
		Форма.ЗакрыватьПриВыборе = ЗакрыватьПриВыборе;
	КонецЕсли;  
	
КонецПроцедуры // УстановитьЗначениеИнтерактивно()
Показать


ps Написал по памяти. Не проверял. Мог косякнуть.
pps Это типа универсальная общая процедура. Подходит не для всего конечно
11. ixijixi 1913 26.09.17 14:31 Сейчас в теме
(10) Что за удивительная абстрактная фигня?
12. tsukanov 26.09.17 14:47 Сейчас в теме
(11) Эта фигня делает то, что хочет автор первого коммента. Я ответил на ваш вопрос?
13. tormozit 7229 26.09.17 15:03 Сейчас в теме
(10) Лучше брать эту процедуру из модуля ирОбщий.ИнтерактивноЗаписатьВЭлементУправленияЛкс инструментов разработчика. https://infostart.ru/public/16985/
seperblunt2; user600603_v.soldatova; +2 Ответить
14. tsukanov 26.09.17 15:10 Сейчас в теме
(13) Да, ваш вариант лучше.
79. monkbest 114 13.05.19 12:40 Сейчас в теме
(1) и правильно, иначе попадете в рекурсию в 99% случаев обработки события
17. protexprotex 139 27.09.17 12:11 Сейчас в теме
Было бы полезным если бы фирма 1С сделала как в C++ (например как в C++) - отделила бы определение функции от самой функции. Т.е. типа h и cpp файлов. По моему, удобно было бы.
18. Vovan1975 13 27.09.17 12:19 Сейчас в теме
(17) ну ну. Удобно ога. Добавил параметр в процедуру и незабудь еще в объявлении его зафигачить.
Было это на 7.7, никакого удобства нет
20. protexprotex 139 27.09.17 12:26 Сейчас в теме
(18) На 7.7. это было сделано через клавиатуру :-). h - файлы нужны для экспортируемых функций - т.е. можно было хранить объявления функций в одном файле, а сами функции - в другом. И к своему проекту подсоединять только h - файлы - и если Вы используете функцию, то она только и компилится в проекте -> проект меньше и работает быстрее. А 1С при открытии модуля все это хозяйство переводит в байт - код -> вывод - ускорение было бы работы 1С.
19. KapasMordorov 428 27.09.17 12:20 Сейчас в теме
21. Dementor 1035 28.09.17 15:27 Сейчас в теме
(17)
Т.е. типа h и cpp файлов. По моему, удобно было бы.

Ага, так это удобно, что мои знакомые программисты сишники на небольших проектах все фигачат сразу в *.hpp файлы :)


(20)
А 1С при открытии модуля все это хозяйство переводит в байт - код -> вывод - ускорение было бы работы 1С.

Ради ускорения на незаметные глазу микросекунды вы предлагаете увеличить время на работу программиста и расширить возможности допустить ошибки?

Я тут на днях решил таки легендарного Брукса почитать. Так он в своей статье про использование современных ЯП (на те годы это были APL, Algol, Fortran и прочие) говорит, что не смотря на некоторое увеличение времени на компиляцию все же, в общем итоге, выгодно использовать ЯП высокого уровня, так как это в разы экономит программистам их время, уменьшает затраты на разработку, а оптимизацию выполнения может на себя взять компилятор. Это я к чему вспомнил? Главное удобство программиста при разработке, а в продакшине (сервер или файловая уже не важно) все равно будет крутится закешированный байт-код.
22. protexprotex 139 28.09.17 15:36 Сейчас в теме
(21)
Это не просто удобно. Это нужно. Т.к. если Вы захотите импортировать в свой проект чужие наработки, то hpp файлы не импортируют, а импортируют именно h - файлы - заголовки->lib - ы и т.д. А то что знакомые сишники все hpp файлы "фигачат", так это не относится к языку программирования. Т.к. если они пишут проекты типа Hello World - то да - тут не спорю. А если это распределенный проект между командой разработчиков, то руководитель проекта вас за такие вот вольности по головке не погладит. Но к 1С это все равно не относится.
24. Dementor 1035 28.09.17 16:43 Сейчас в теме
(22)
Т.к. если они пишут проекты типа Hello World - то да - тут не спорю. А если это распределенный проект между командой разработчиков, то руководитель проекта вас за такие вот вольности по головке не погладит.

Нет, они писали более сложные программы - решение транспортных задач для разнородного транспортного парка с десятками ограничений и графом дорог, который являлся функцией от самих машин (тонажа, наличия прицепов, купленных разрешений на проезды в закрытые части городов) и от времени (часто грузовики в города пускают только ночью, а днем можно пикапиками и газельками возить, а про работу мостов по часам я уже вообще молчу - не успел проскочить на второй берег, уже считай полдня потерял), а так же программы прогнозирования спроса и прочие математические модели.
Нет, у руководителя проекта никаких возражений не было. Общие *.hpp для разных проектов отлично компилировались в промежуточные *.a файлы, которые далее уже больше не пересобирались без надобности и использовались в линковке различных бинарников. Вся магия в правильно настроенных мейк-файлах.
Да, к 1С не относится и слава Богу :)
27. eugeniezheludkov 45 29.09.17 09:27 Сейчас в теме
(22) вот я понимаю зачем нужен интерфейс в ООП языках типа ява, шарп, но вот зачем нужно дублировать информацию при помощи .h не понимаю! пока разрабатываешь без ТЗ, сигнатуру метода класса перепишешь миллион раз и каждый раз нужно лезть в этот .h и переписывать его там причем не так как в cpp файле, честно - это ужасно.
конечно тут все дело в волшебных ИДЕ которые должны сами лезть и исправлять все в .h , но например ArduinoIDE, vi , nano к таким не относится (((
28. protexprotex 139 29.09.17 09:37 Сейчас в теме
(27) h - файлы нужны для линкования ваших разработок со сторонними проектами. Делаете include "My.h" и все. И это определение делаете во всех модулях в которых используется функции из My.cpp. И линковщик соберет все. А если без h - файла, то cpp - файл Вы не сможете объявить во всех модулях. Так устроено.
46. karimov_m 11.12.17 17:56 Сейчас в теме
(28) Мягко говоря это не так)
h или hpp файлы нужны в первую очередь для удобства программистов.
В них описывается модель (классы, шаблоны) в то время как в cpp пишется основной функционал, создается их (классов) реализация.
Это становиться более очевидным, когда речь идет именно о С++ где есть парадигма шаблонов и шаблонных-классов.
В С - .h и .с файлы просто разделяли логику описательную и саму реализацию. В контексте линковщика - в целом, без разницы в каких фалах все находиться (хоть в .hppst расширение закинь) - он просто имеет понимание что необходимо протрассить вначале (определения и типы) чтобы в дальнейшем исполняемых код имел все данные для корректного компилирования.
52. protexprotex 139 11.12.17 18:40 Сейчас в теме
(46) Тут написано в контексте основного отличия применения h-файлов от применения функции Далее (как в 1С 7.7)
23. protexprotex 139 28.09.17 15:36 Сейчас в теме
(21) А по поводу ошибок - там синтаксический контроль есть. Он об таких ошибках сообщит.
25. Dementor 1035 28.09.17 16:48 Сейчас в теме
(23) Есть такой. Помню как-то запустил синтаксический контроль по типовой торговле - насыпалась куча ошибок про отсутствие назначенных обработчиков и прочая мелочь. А ведь это писала "элита 1С" :) Рассматривайте визуальную часть формы как заголовочный файл, где в событиях прописаны названия функций и предопределен состав реквизитов. Вот как сейчас платформа позволяет делать ошибки, так и с внедрение еще одного промежуточного слоя ничего не изменится!
26. protexprotex 139 28.09.17 17:17 Сейчас в теме
(25) Ну, может быть. В общем, для 1С (пока) это не надо. Но именно создатель С++ очень трепетно относился к такому разделению :-)
30. Darklight 33 04.12.17 11:48 Сейчас в теме
(17)Ой, не надо нам в XX век, пожалуйста. В XXI веке для этого есть ООП, свойства, интерфейсы (объектов) и паттерны MVP и MVVM (на худой конец MVC или даже "MVPVM") для отделения визуального представления от реализации.
31. protexprotex 139 04.12.17 12:25 Сейчас в теме
(30) Все новое - хорошо забытое старое :-)
32. Darklight 33 04.12.17 12:32 Сейчас в теме
(31)Не всё; ну, или, порой, оно уж настолько старое, что уже из ряда "никто не помнит - никогда не было"
33. protexprotex 139 04.12.17 12:56 Сейчас в теме
(32) Ну это Вы слишком. Например, с++ builder 6 - хоть и был выпущен в 2005 году, но все же в 21-ом веке. Это примеру. Ну а C++ Builder 10.1 - я Вам по секрету скажу - вообще недавно. И там и там есть и такой порядок написания кода. Или тоже никто не помнит этого, хотя полно народу на этих системах пишет? :-) Ну и майкрософт - тоже в их системах программирования есть и h и cpp файлы. Или Вы другого мнения? - их там нет?
34. Darklight 33 04.12.17 13:53 Сейчас в теме
(33)Вы о чём - тут не IDE обсуждается, а парадигма программирования. Что нового в парадигму архитектуры кода привнеси Вами упомянутые IDE, да ещё такого, что бы Вы так хотели увидеть в конфигураторе 1C (или в EDT)? заголовочные файлы появились во второй половине XX века, к концу которого - была кульминация расцвета разделения кода от его интерфейса - на фоне возникших COM технологий (OLE, ActiveX, DCOM, CORBA...). В XXI веке во всех новых языках программирования от заголовочных файлов отказались как, от пережитка прошлого. Думаю, основными двигателями тут стали языки Java и C# - продвигающие иные модели cross-app взаимодействия и подключения библиотек, а, заодно активно продвигая в массы, технологию ООП и, в частности, интерфейсов, а так же рефлексию! И это было подхвачено и развито далее другими языками. А в С++ интерфейсов нет (там есть аналог - абстрактные классы и множественное наследование - но это очень усложнило язык, хоть и добавило ему большей гибкости).

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

В этом мире уже нет места ни классическому процедурному программирвоанию (но есть - функциональному) - нет места заголовочному программированию (но есть место контрактному, совмещённому с метопрограммированием и встроенным юнит-тестированием), нет места прямому управлению памятью (но есть место сборке мусора, кодогенерерации, автоконструируемым типам и рефлексии), нет места строгому указанию типов (особенно возвращаемых значений) но есть место выведению типов, нет места строгим структурам переменных и методов (инкапсуляция), но есть место динамическим классам и реализации множества интерфейсов, определение только свойств (без определения полей), нет места абстрактным классам и множественному наследованию (есть интерфейсы, в т.ч. частично реализованные интерфйесы (трейты), и сервисы), нет места виртуальным методам (но теперь все методы переопределяемы в наследнике, а так же есть события и подписки обработчиков на события), , и почти не осталось места синхронному программированию (зато декларативное программирование и асинхронная обработка вызовов - набирает обороты, думаю со времён появления LINQ/PLINQ и TASKS в C#); вот и визуальная разработка форм уже давно стремится к другим моделям, чем были во времена царствования С++ и Delphi - теперь тут рулит XAML и вёрстка форм в стиле WEB-страниц, и отделение не только кода обработки данных от интерфейса и самих данных - а разделение этой обработки на клиентский и серверный контекст. А заголовочные файлы.... да кому они сейчас нужны!
Kosstikk; +1 Ответить
35. alex_sh2008 5 04.12.17 13:59 Сейчас в теме
(34)
А заголовочные файлы.... да кому они сейчас нужны!

Тем кто работает на кодом в 10млн строк
36. Darklight 33 04.12.17 14:14 Сейчас в теме
(35)Надо полагать Вы имели в виду 10мл строк только заголовочных файлов :-D

Кстати, забыл добавить, что, скажем, C# имеет возможность оформлять частичные классы (с частичными методами) - где описание и реализацию одного класса можно разделить на разные файлы, причём подчёркиваю, не только отделить реализацию метода от их определения в классе - но и само определение класса разбить на разные файлы. Это как раз сделано для тех Гениев, что не настолько талантливы, чтобы редуцировать свои идеи до более компактных абстракций, что комплексно собирались бы из разных классов, но уже настолько сумасшедшие, чтобы мыслить единой логикой API в 10млн строк.

Главное что такой подход не нужен всем - это только для избранных, остальных к лишнему усложнению принуждать не надо. Вот пусть эти избранные им и пользуются. Уверен, что алгоритмы 1С никогда не дорастут до таких потребностей - не надо нам такого безобразия! Но если вдруг надо будет - разработчики C# уже давно это придумали (хотя не уверен, что это первым делом появилось именно в C# но это не важно, кто был первым).

И ещё. я языах программирования, включая 1С уже давно появилось сворачивание реализаций (частей кода) в строку (код-фолдинг), включая создание своих произвольных областей сворачивания - это тоже эффективно позволяет скрывать с глаз долой алгоритмы и определения, которые будут громоздки для быстрого восприятия.
38. protexprotex 139 04.12.17 14:25 Сейчас в теме
(36) Вообще - то h - файлы не для сворачивания кода используются, а для подключения внешних библиотек к своему коду. У 1С такая парадигма - давайте все что нужно/не нужно соберем в среду разработки -> и получается, что инсталлятор самой 1С-ки получается такой, что в пору терабайтники уже скоро покупать, и памяти надо гигов 8 и т.д. А вот в (например) в C++ builder - там другая парадигма - например, надо Вам работать с http - подключите head (h) файл соответствующего компонента - и работайте с ним. А если Вам не нужен компонент indy - то и не подключайте его. И память не занимает и др. Но тут 1С-кам деваться некуда - у них язык - интерпретатор. Их код 1С выполняется на стековой машине - без самой 1С - он и не запуститься. Это не exe-файл.
40. Darklight 33 04.12.17 14:33 Сейчас в теме
(38)Тогда это больше походит на холивор что лучше Java или Assembler(C++) или что лучше - Платформа высокого уровня абстракции доступа к данным, или - куча библиотек начиная от низкоуровневого доступа к памяти и диску, заканчивая алгоритмами визуализации и обработки коллекций....
42. protexprotex 139 04.12.17 14:46 Сейчас в теме
(40)
Assembler - классная штука! - Это просто лебединая песня программирования. Писать на нем - одно удовольствие. В некоторых школах программирования даже учат только на ассемблере. Ну а так - к каждой области - свой язык программирования. На 1С никто не будет писать текстовый редактор. Для этого 1С не предназначена. На Assembler никто не будет писать интерфейс к базе данных. Для этого есть 1С, c++ builder, delhi и пр. А по поводу h- файлов - так это было просто теоретическое предложение. Не концентрируйтесь на этом уж больно сильно.
49. karimov_m 11.12.17 18:17 Сейчас в теме
(38) Это тоже частный случай (подключение внешних библиотек)

В целом - разделение на несколько файлов - суть модульная архитектура - для избежания повторного определения структур данных, из быстрого изменения (изменил/дополнил в заголовочном файле - ты точно знаешь, что теперь данная структура доступна и корректна во всех файлах реализации, куда подключен данный заголовочный файл)
43. alex_sh2008 5 04.12.17 15:14 Сейчас в теме
(36)Заголовочный файлы есть во всех языках программирования, назвать их можно по разному но суть останется, это декларирование функций, классов, интерфейсов. Если конечно вы пишите грамотно структурированный код, который позволит вам поддерживать большое приложение.
44. Darklight 33 04.12.17 15:47 Сейчас в теме
(43)Разные методы декларирования API (в т.ч. описанные мной выше) и конкретная реализация, пришедшая, по большей части ещё с процедурного программирования, в виде отдельного заголовочного файла - это вещи разных плоскостей, разного уровня. В исходном комментарии автор насаждал идею, что выделение определения API в отдельный заголовочный файл - это хорошо и надо в возвращаться к корням. На что я возразил - что сейчас, в XXI веке, для достижения цели формирования API используются уже совсем иные методики. Далее разговор стал скатываться в области технологий взаимодействия разных библиотек и разных приложений друг с другом; и в проблемы оформления гигантских классов, где я пояснял как сейчас идёт развитие идей программирования в других языках, без какой-либо возврата в каменный век. Да, платформа 1С и IDE (включая EDT) почти ничего из этого не умеет, а жаль... но будем надеяться - когда-нибудь и платформа 1С будет иметь высокоразвитую и современную среду разработки, позволяющую поддерживать большое приложение.

Кстати, с приходом в императивный стиль программирования идей из функциональных языков - в императивных языках появились анонимные функции и лямбда-выражения - они вообще не имеют декларации в полном смысле этого слова - только, в лучшем случае, список входных/выходных параметров - да тело алгоритма. А используемые переменные вообще могут захватываться из вызывающего их кода. Такие функции вообще не определяются нигде, кроме места их передачи в другой алгоритм. Или же код инициализации/получения/установки значения свойств объектов может быть написан по месту определения этих свойств, без декларирования отдельных функций, и даже без указания типа этих свойств - он будет выведен из выражения геттера или инициализатора. Собственно, наверное это и побудило отказаться от пережитков прошлого - отдельных заголовочных файлов - уж больно много стало скрытой кодогенерации, на основе выражений и программного кода, который стал размещаться сразу по месту определения структуры или месту применения.

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

А модели пострения форм MVVM - алгоритмы могут размещаться прямо в элементах формы (как это было в 1С 7.7).

Но это всё так.... мелочи...
45. alex_sh2008 5 04.12.17 19:49 Сейчас в теме
(44)В языке 1С есть все что нужно для написания того уровня приложений для которых он предназначен, единственный недостаток, устаревшие алгоритмы трансляции кода, и соответственно медленное исполнение кода.
37. protexprotex 139 04.12.17 14:20 Сейчас в теме
(34) Вам уже ответил Александр alex_2h2008. Мне добавить нечего.
48. karimov_m 11.12.17 18:10 Сейчас в теме
(34) кому нужны? Расскажите это программистам которые пишут код для спутников, телекоммуникационного оборудования, военной и аэрокосмической отрасли. Там все так же рулят процедурное (прямое) программирование + функциональное. Реализация алгоритмов на ПЛИС, создание алгоритмов Цифровой обработки сигналов и т.д. итп..
47. karimov_m 11.12.17 18:03 Сейчас в теме
(33) Это просто дань языку, в частности С++. В паскале есть модули (что фактически тоже самое) можно подключить его так: $I file.inc
39. Kosstikk 87 04.12.17 14:32 Сейчас в теме
Хм.. слишком упрощенный паттерн..

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

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

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

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

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
.....

РаботаСФормами.Согласование_ПриСозданииНаСервере(ЭтаФорма);
//РаботаСФормами.СоздатьСлужебныеРеквизиты_Согласование(ЭтаФорма);
//РаботаСФормами.СоздатьПодпискиСогласования_Согласование(ЭтаФорма);

КонецПроцедуры


Процедура ОбработатьСобытия_Согласование(Параметр1 = Неопределено, Параметр2 = Неопределено, Параметр3 = Неопределено)
    Если Параметр1.Имя = Дата_ПриИзменении Тогда
        УправлениеДоступом_Согласование_ДатаПриИзменении(ЭтаФорма);
        //Лучше оптимизировать и передавать только нужные данные
    КонецЕсли;
    ....
КонецПроцедуры

Показать


И знаете что )) в последних БСП вижу активное использование определяемых типов для включения наследования ))
т.е. мы можем наш код сделать стандартным для всех объектов и проверять включение блока через вхождения в определяемый тип.

А теперь вдумайтесь.. как было бы круто, если мы просто бы могли использовать несколько уровней наследования, делать наш подкласс документ_согласования, наследовать его от стандартного документа, а уже от документа_согласования - создавать конечные документы (т.е. сейчас 1С не умеет делать иерархию наследования, все документы наследуются от стандартного класса документ и всячески параллельно пришлепываются функции.. в этом есть очень много недостатков (но зато все просто и понятно и быстро для 1сников).
41. Darklight 33 04.12.17 14:40 Сейчас в теме
(39)Знаем мы вас: сначала захотите наследование, затем полиморфизм, а там уже, вам, и множественное наследование подавай....
karimov_m; +1 Ответить
51. karimov_m 11.12.17 18:26 Сейчас в теме
(41)Да да! и побольше! И перегрузку операторов нативную хотим и передачу кода как параметра функции (лямбда) =)
50. karimov_m 11.12.17 18:24 Сейчас в теме
В целом понятие и реализацию наследования можно было бы прикрутить в 1С. Как-то: определение базового документа и ключевых реквизитов (который фактически есть на платформенном уровне (в виде Стандартных реквизитов) и его основных методов (при создании, при закрытии и тп.)

Тут дело в чем. Реализация всего этого - основывается в конечном счете на реляционную модель БД, которая в бэке 1С.
Тем не менее - искусственными подходами можно добиться и реализацию Классов и наследование и (боже мой) Полиморфизм. Это лишь вопрос: кто на что готов заморочится. Пока система не подразумевает такого подхода (платформоориентированного ООП) в своем продукте - надо использовать то что имеешь)
53. Darklight 33 12.12.17 13:52 Сейчас в теме
(50)Не вижу никаких проблем в реализации ООП в платформе 1С, в реляционной модели БД. На других платформах, хоть, скажем, на Аксапте, ООП есть изначально - и никто не парится по поводу того, что в итоге всё хранится в плоских таблицах реляционных БД. Сама платформа 1С (её приклданой API) практически объектно ориентированный (хоть и ограничено, но всё же). Так что ничего не мешает в 1С: Предприятие 9 определять:
а. Классы и интерфейсы в модулях объектов, как обычные процедуры и функции (такое определение класса не подразумевает использования таких классов как типообразующих, хотя сериализацию тут можно было бы задействовать, в т.ч. работающую по умолчанию).
б. Классы и интерфейсы, определяемые в дереве метаданных - такие классы могли бы быть типообразующими, как используемыми в качестве отдельных ссылочных объектов, сохраняемых в БД (как обычный справочник или документ; хотя можно было бы реализовать и сохранение в качестве регистра сведений); так и используемые в качестве типов реквизитов (в т.ч. в описании типов), если такой класс применялся бы в реквизите, скажем справочника, то можно предложить три схемы хранения в БД (на выбор разработчика):
1. Как обычная объектная ссылка
2. Как составной реквизит-структура, просто разворачиваемый в набор полей-реквизитов (а вложенные таблицы значений разворачиваются в отдельные таблицы как табличные части)
3. Сериализуемый в бинарный/строковой объект memo-поля данного реквизита (по заданному, в классе или в реквизите, провайдеру сериализации).
При этом кажый вложенный реквизит-класс может сохраняться по своему методу (а. или б. как будет настроен; метод в - всегда производил глубокую сериализацию всех вложений).

При этом, наследование может учитываться по трём схемам:
1. Классы наследники - самостоятельные классы - при сохранении предка - его данные распределяются по таблицам классов наследников (не лучший вариант решения).
2. Классы предки- чистая формальность - в конченый объект класса просто переносится их содержимое - и его можно просто привести к интерфейсу предка. Сохраняется такой класс как цельный объект, ничего не знающий о предках.
3. Прямого наследования нет - только гибкоуправляемое оборачивание классов-потомков как членов конструируемого класса, с переносом их API в класс предок-обёртку-прокси). Тут уже в настройках таких полей решается как они будут сохраняться - в отдельные таблицы или как составной набор полей. Мне это решение нравится больше вссго. Оно, кстати даёт и гибкое и чёткое мультинаследование - если нужно будет.

Вместо наследования справочников и объектов (и пр.) - наследование классов, которые далее используются внутри реквизитов справочников и объектов (как составные наборы реквизитов). Т.е. всё через классы, в которых реализуется полноценный ООП, со свойствами, инкапсуляцией, наследование и полиморфизмом, и даже с событиями.

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

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

Поддержка , не только классов, но и интерфейсов - позволила бы приводить API взаимодействия с разными объектами к единым форматам. Проверять объекты на поддержку того или иного подхода работы с ним (а не конкретного типа). Реализацию и приведение к интерфейсу можно было бы прикрутить не только к классам, но и к объектам метаданных - чтобы, например, у обработки или документа можно было бы проверить или получить заранее определённый единый интерфейс API-доступа к этому объекту. Причём у него таких интерфейсом может быть очень много - каждый для своих целей. Уровень интеграции решений 1С: Платформы вырос бы колоссально. Особенно если интерфейсы ещё и сделать почти-строго типизированными (всё же в рамках одного интерфейса типы выходных и выходных параметров обычно уже заранее все известны, с учётом использования ООП и вложенных интерфейсов-типов, не привязанных к конкретному типу-класса, но гарантирующих строгий API доступ к его объекту).

P.S.
Напоследок скажу. Больше половины из того, что я выше написал - можно было бы построить как расширение 1С EDT с трансляцией в более примитивную архитектуру платформы 1С: Предприятие 8.Здесь нет ничего трансендентного - обычное транслирование структурированных данных в более линейные (на типовые объекты метаданных платформы 1С Предприятие 8), как в дереве метаданных, так и в алгоритмах модулей. Без обратной совместимости (т.е. без поддержки работы алгоритмов, написанных вне такого проекта EDT). Я уже видел такие расширения языков, которые изначально не были ООП - а умельцы их допиливали через препроцессор и редактор - чтобы в них появился ООП подход. Было сделано очень круто!
Так что всё это реализуемо (с разной степенью сложности) в рамках даже платформы 1С: Предприятие 8.

P.P.S.
С применением ООП БСП и пр. типовые библиотеки и прикладные решения - упростятся радикально!
А если ещё выправить кривизну в директивах определения контекста выполнения - перенеся их в модулях на методы (процедуры, функции, свойства в т.ч. классов), как в УФ, только для всех модулей. Так вообще красота настанет. Незачем один и тот же алгоритм распределять по куче модулей, если отдельные его подпрограммы доллжны выполняться на сервере, отдлльные на клиенте, отдельны и там и там, отдельные требовать привилегированного режима, а отдельные кешироваться.

А вот сами модули хорош бы сделать иерархическими, как подсистемы, чтобы алгоритмы можно было распределять по подмодулям, при этом либо каждый такой модуль является самостоятельным, либо все вложенные подмодули как бы являются единой часть корневого модуля (всё содержимое доступно во всех подмодулях),либо можно сделать более гибкую настройку экспорта и видимости содержимого. Тогда, например, дополняя типовой модуль это дополнение можно было бы разместить во вложенном подмодуле, не трогая типовой, но видя всё его содержимое (в т.ч. не экспортируемое).
kote; nazirovramzil; +2 Ответить
54. karimov_m 13.12.17 12:40 Сейчас в теме
(53) много текста) Суть - если очень захотеть, можно к Марсу полететь. Конечно все это можно сделать. Но вот уровень ошибок (как логических там и платформенных) - будет много больше. Это немного другой уровень программирования, грубо говоря, для "Бизнес-программирования" - это излишне (в большинстве случаев).

Второй момент - это все же концепция ORM (Объектно-реляционное отображение»), которая является суть 1С только без ООП - «технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования». 1С идет дальше предоставляя помимо подхода ORM, еще интерфейсные реализации, аналитические подходы, накопительные, расчетные и прочие элементы и подходы в проектировании систем. Думаю, для бизнес приложений - это более чем достаточно, а все остальные сложные участки (ГИС, Мультимедиа, сложная Криптография и тп.) должны реализовываться и подключаться как сторонние библиотеки, для обеспечения нужд и вызовов из БизнесПлатформы, что 1С делает на текущий момент вполне продуктивно.
Donpager; +1 Ответить
55. karimov_m 13.12.17 12:42 Сейчас в теме
По мне, так интересным новым расширением языка или механизмов платформы - было бы более мощный и производительный аналитический и статистический аппарат. Чтобы можно было оперировать данными так же, как например в языке R. Это было бы более выгодное направление в развитии платформы, чем внедрение ООП
56. Darklight 33 13.12.17 14:38 Сейчас в теме
(55)Ну и что такого даст R для 1С кроме пары функциональных фишек. Там вся суть в библиотеках и нескольких встроенных команд-функций. Да и задачи статистического учёта в 1С решаются не так уж част - кому надо - есть прикладной обеъкт "АнализДанных". Всё остальное в R - это некоторый набор синтаксического сахара, пара фич из функциональных языков (которыми не удивить ни один современный язык программирования) и набор библиотек (кому надо - импортируйте их хоть сейчас в 1С - тормозить только будут - но в этом не виноват язык 1С - в этом виновата его стековая машина исполнения).

Про то, что прикладные задачи нужно решать библиотеками - я согласен - только в платформе 1С Предприятие 8 ограниченное взаимодействие из языка 1С с внешним миром и не 1С компонентами и библиотеками. Конечно, доступ можно обеспечить через подключаемые внешние компоненты - но они могут быть заблокированы политико безопасности. Это уже совсем другой вопрос, как взаимодействовать "с внешними библиотеками". Его тоже, вполне бы стоило проработать в платформе 1С: Предприятие 9 (как контролируемо подключать к решениям на платформе внешние библиотеки (и компоненты)).

По поводу ORM - это есть сейчас уже много где, кроме 1С (лет так 10-20 уже развивается эта концепция в других языках и платформах). И она как есть в 1С так пусть и останется и даже ширится и универсализируется. А концепция ООП - в платформе 1С Предприятие 8 и так есть (и даже в 7-ке была) - но объекты лишь встроенные - расширять их создавать свои классы не дают. Нет полиморфизма, нет наследования, нет инкапсуляции. Зато есть жуткий монстр БСП, которой без ООП так запутан и сложен, что чёрт голову сломит в нём разбираться. То же касается и концепции построения типовых конфигураций для управляемого приложения - кругом напрашивается ООП и элементы функционального программирования, и без этого всё тоже очень усложнено - от того и куча багов, как в типовых решениях, так и при их доработках. Уж не говоря о том, в какой ад превращаются эти доработки.

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

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

- Требования данных: Запросы на получение из источников каких-либо выборок (наборов полей, с фильтрами), учитывающие возможность получение данных из нескольких источников, связанных через указанные маркеры сущностный.

Это всё декларатотивное указание платформе, указывающее что и от куда, в каком виде нужно выбрать. А платформа уже на основе такого описания выстраивает оптимальные запросы - к реальным таблицам. Стараясь выбрать из СУБД всё что нужно за один раз (но не порождая сложных запросов к СУБД), а потом просто распихав по требованиям в нужном формате с нужным условием полученные данные. Формально, даже при десятке требований - все данные могут быть в нескольких таблицах - а каждое требование просто имеет свой особый доступ к этим таблицам - выборку, перебирающую только нужные строки и нужные колонки.

Во многом такой подход напоминает СКД. Но тут все источники и требования разом консолидируются и оптимизируются, для наиболее эффективной выборки из СУБД; и всё описывается текстовыми командами (хотя вызовами методов тоже можно и даже нужно).

Схема такая: например, при проведении документа сначала разные блоки подалгоритмов задают добавляют описания источников данных (или используют базовые - автоматически получаемые из метаданных). Затем добавляют свои требования по выборке данных, которые им будут нужны. Затем происходит выполнение: платформа на основе источников, маркеров и требований выстраивает запросы к СУБД - получает только требуемые данные (без повторного обращения к одним и тем же таблицам), распределяет по требованиям, затем каждый подалгоритм получает уже полностью прочитанные результаты своих требований. Всё просто и очень эффективно (всю сложную работу по оптимизации выборки на себя берёт платформа - и тут не паханное поле для постоянного усовершенствования этого алгоритма).

Для отчётов всё аналогично: только там можно настраивать нужные отчёты из блоков - источников данных, которые автоматически связываются друг другом через маркеры сущностей - не нужно думать как реально данные распределены по таблицам в СУБД. Всё оперируется только бизнес-сущностями. Почти как в СКД, только с более высоким уровнем абстракции (ближе к бизнесу), и более высоким уровнем использования заранее настроенных конфигураций источников и выборок.

И, замечу, ни одной временной таблицы (платформа сама их сделает там где надо - при построении итоговых запросов, правильным образом их проиндексирует).
57. karimov_m 13.12.17 16:06 Сейчас в теме
(56)Как вы говорите - концепция ООП есть в 1С, да, но только в базовом случае. Есть только "подход" изначально взятый из объектного мира (но не из ООП программирования!) - что есть Класс объекта (Документы, Справочники и тп.) и их отдельный сущности (Докуемнт. Справочник и тп.). Вот и вся ООП в 1С.

- Определение источников данных:

ну т.е. реализовать DDL инструкции языка SQL.. опять же, это повышает порог входа и изучения. Необходимо помнить - о многопользовательской архитектуре системы и множества связей объектов между собой. Трудно представить такую необходимость.. в конечном счете это будет ТаблицаЗначений. Если надо временное создание источника данных - есть временный таблицы для решения локальных задач вычисления. Конструировать в рантайме сколько нибудь долгих по времени использования источников данных (таблиц и тп.) - можно в режиме проектирования системы. Реализовать изменяющиеся во времени составы данных (типа расширение состава ТЧ) - решаются созданием связкой и отношением нескольких таблиц (регистров) и одного справочника.

- Маркеры сущностей и - Требования данных
это какая-то специфика реализации.. но не направление развития..

Сейчас тренд идет на машинное обучение и, в частности, умных индексов, которые сами себя создают, основываясь на анализе запросов, их частоты и существующих данных, выбираемых этими запросами. И все это динамически - какие запросы Нынче и какие данные - такие и индексы ML строит на них и модифицирует их.
Плюс анализ самых частых обращений к модулям, самых сложных по весу операций переброски Сервер-Клиент и т.п. На основании этого выделять обработку таких вызовов на отдельные компоненты сервера предприятия - вплоть до создания "inmemory DB" и кэширования таких сложных запросов/вызовов ней, после чего все что накопилось потихоньку мэппить в SQL и раскладывать по табличкам. При этом надо учитывать параллельные транзакции к тем же данным.

Вот это было бы круто.. и реальный прирост скорости. Конечно никто не отменяет умение строит архитектуру системы..
58. Darklight 33 13.12.17 16:22 Сейчас в теме
(57)Дело не только в приросте скорости. Дело в повышении уровня абстракции, через повышение декларатативного стиля программирования (и использования). То есть должно быть больше таких понятий как "у меня есть", "тут есть связь", "я хочу", "посчитай", "преобразуй к виду", "совмести". Которые уже транслируются к оптимальному набору машинных операций и выборок данных, без повторений. Именно повышения уровня декларатативности ведёт к повышению возможностей машины самой решать как ей лучше делать и как ей это всё делать параллельно и без блокировок!
59. karimov_m 13.12.17 17:03 Сейчас в теме
(58) ну это в иделе. Суть такого подхода будет стремиться к следующему выражению: "1с, а 1с - а сделай выборку всех незаблокированных договоров (справочник) контрагента ООО Ромашка и верни таблицу взаиморасчетов по дебиторке в разрезе этих договоров, только той дебиторке, что критически просроченная, которая образовалось более 80 дней назад. Описание возвращаемых полей данных возьми в справочнике "состав полей отчета ДЗ" "

Этак так и программисты скоро не нежны будут)
60. Darklight 33 13.12.17 18:01 Сейчас в теме
(59)просто в очередной раз изменится парадигма программирования. Как когда-то она изменилась от машинных кодов простых операций над числами к ассемблеру далее к императивному стилю - далее к функциональному или логическому стилю, далее ответвление на программирование на нейросетях, далее к метопрограммированию, затем к полному декларатативному стилю (что там будет с парадигмами программирования далекого будущего пока судит сложно - но, будет ещё не один качественный переход, покрайней мере, следующая парадигма будет основана на нечёткой логике, вероятностях значений, предсказаниях событий и непрерывных параллельных ветвящихся вычислениях с неполными известными). И спрос на программистов будет только повышаться пока они не разработают ИИ, который будет себя совершенствовать быстрее и лучше, любого человека... и настанет эпоха сингулярности развития науки и общеста!
61. karimov_m 13.12.17 19:02 Сейчас в теме
(60) ИИ уже делает другие ИИ лучше, чем человек )
71. Darklight 33 14.12.17 15:25 Сейчас в теме
(61)Формально да, но формально сейчас ещё нет полноценного ИИ - лишь его математические имитации.
72. karimov_m 14.12.17 15:52 Сейчас в теме
(71) ну это уже общее определение.
Тут вопрос, что в вашем понимании "полноценное ИИ"..
Отсылки к созданию ИИ общего назначения? Это в проектах, но и это будет. Квантовые вычисления этому поспособствуют..
74. Darklight 33 14.12.17 16:50 Сейчас в теме
(72)Думаю, полноценный ИИ это сознание, которое определяется через самосознание себя как живого/мыслящего существа/индивида (т.е. разум, не способный определить себя как искусственный); и через призму восприятия других существ/индивидов - которые не смогли бы в общении определить этот разум как искусственный. Ну, и добавлю, плюс способный создать новый разум, который аналогично воспринимал бы себя (причём, создатель по-прежнему не смог бы сам себя посчитать искусственным разумом, даже после того, как сам же создал новый искусственный разум, обладающий тем ми же качествами, т.е. в т.ч., не способный самостоятельно определить, что он искусственный, и способный далее создавать такой же). Сложно выразился, прошу прощение... наверное просто не в духе сейчас давать изысканные определения.
78. webester 26 09.05.19 19:35 Сейчас в теме
(59)
Этак так и программисты скоро не нежны будут)

Я бы не сказал, что и сегодня они особо нежны
vandalsvq; +1 Ответить
62. starik-2005 3087 13.12.17 19:08 Сейчас в теме
Интересное обсуждение, только вот не совсем понятно, зачем ООП мешать с объектами, хранимыми в БД? Ну пусть они там хранятся как набор определяемых в конфигураторе данных, а вот обработка этого набора - вот это и есть хранимые отдельно методы объектов. Данные - отдельно (в БД), методы - отдельно (в конфигурации БД). Зачем наследовать документ? Достаточно наследовать его программную реализацию, т.е. код. При необходимости создавать объект, наследующий программный интерфейс от другого объекта, часть методов которого нужно переопределить (например, заказ поставщику, поступление, заказ покупателя, реализация, ... - товарные документы, в которых общего кода достаточно). С другой стороны, все это реализуется через общие модули, экспортные процедуры которых могут быть переопределены в другом модуле - достаточно вызвать вместо метода "ЗаказПокупателя.МояПроцедура" метод "Реализация.МояПроцедура". Для реализации подобного поведения ничего не нужно толком, ибо вызывая "МойОбъект.МояПроцедура" можно автоматически получить тот самый полиморфизм, когда объект вызывает тот метод, который ему предназначен (т.е. фактически если есть стопиццот разных объектов с этим методом, то каждый из них вызовет тот метод, которые для него определен в его модуле).

Т.е. ООП в плане работы с прикладными объектами 1С не особо нужен - все в нем уже есть. А вот реализация самих объектов, отделенных от данных, также передаваемых в качестве аргументов функций (типа "СделатьЧтоТо(@ФункцияДеланияЧегоТо)") и прочие интересные конструкции - вот это было бы к месту.
63. karimov_m 13.12.17 19:30 Сейчас в теме
(62) Всё так, согласен.
Но наследовать можно (и нужно иногда) не только программный код класса (документа) но и его данные (реквизиты).
Фактически, если мы наследуем только код, то мы объявляем интерфейс и его возможные реализации.
64. starik-2005 3087 13.12.17 19:37 Сейчас в теме
(63)
но и его данные (реквизиты)
Фактически при таком наследовании либо создается новая таблица в БД для новых данных (или Вы думаете, что для разных экземпляров объектов, унаследованных от базового, можно иметь разное количество колонок в реляционной базе? Это не так - тогда уж нужно использовать объектные базы, и получите все эти веселые штуки с типом экземпляра, версией, самим объектом, который внезапно оказался немного не тем, а код снова унаследовался - тут достаточно копирования объекта в конфигураторе и добавлении к скопированному нужных колонок, или просто регистр по типу допреквизитов с характеристиками в запросе, которые и так работают, а если сильно что-то надо - есть расширения, которые колонки могут к объекту добавить - но там и проблем с этим масса).

Смысл наследовать что-то, кроме кода, я, например, не вижу. По крайней мере в реляционной модели данных.
65. karimov_m 13.12.17 19:50 Сейчас в теме
(64) Вот, и тут мы подходим к тому, что вы писали выше
зачем ООП мешать с объектами, хранимыми в БД?
))
Суть не в наследовании "данных" как таковых. А в наследовании их структуры, а во множественном наследовании - это суть строительство нужных классов/объектов (документов) из базы.
- Вот тут у нас класс с данными по "базовым данным" (дата. время ввода, код, еще какой-то признак (пометка))
- Вот тут у нас класс с функционалом открытия формы (причем любой формы), ее позиционирования и других действий
- Вот тут есть класс (неплохой такой) - он внедряет возможность иметь объекту Табличную часть!
- Воу! Продолжим наследовать/миксовать - вот класс такой: писать в таблицу/регистр и методы/код - и вот наш Новый Класс - почти что документ, который может делать проводки, иметь ТЧ. От него я буду создавать все остальные документы.

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

Примерно в таком направлении можно думать об ООП. Но в 1С нет ООП, в нем можно программировать подходами ООП
66. starik-2005 3087 14.12.17 11:04 Сейчас в теме
(65)
А если мне понадобиться расширить функционал Класса ТабличаняЧасть ? Например методом "Свернуть" ?
А где тут привязка к БД? Табличная часть - это объект со своими методами, набор колонок - это лишь коллекция, которая просто для разных данных будет содержать разные значения. Наследовать содержимое этой коллекции бессмысленно.
67. karimov_m 14.12.17 11:23 Сейчас в теме
(66) Еще раз. Наследование кода - это одно. Наследование данных как описание их структуры - это совсем другое. Посмотрите - есть "базовая структура" ТЧ - состоящая из колонок (шапка таблицы - это и есть описание структуры) и потенциальных строк (в каждом конкретном экземпляре объекта). Например "Номер строки" - это колонка, суть описание структуры данных ТЧ, он то и наследуется. А какие там потенциальные "значения", которые будут храниться в памяти, описано этой структурой - это уже будет известно при выделении конкретного объекта и его жизни.

Про жесткую привязку к БД никто не говорит) Тем не менее, если мы говорим о потенциальном внедрении ООП (настоящего) в платформу 1С, не брать в расчет, что все данные так или иначе хранятся в БД - нельзя. Это к вопросу о сложности такой системы.
68. starik-2005 3087 14.12.17 13:16 Сейчас в теме
(67)
Наследование данных как описание их структуры - это совсем другое.
А примеры будут?
70. karimov_m 14.12.17 14:47 Сейчас в теме
(68) примеры чего?) Повествовательная часть моего высказывания уже пример)
Я же не контрагрументирую - а веду беседу, чтобы развить мысль.

Я не сторонник отстаивания мнения ради самого процесса отстаивания..
76. starik-2005 3087 15.12.17 11:38 Сейчас в теме
(70)
Я же не контрагрументирую - а веду беседу, чтобы развить мысль.
Мне просто интересно, как бы это выглядело на языке 1С и что бы при этом происходило в базе данных (ну чтобы лучше понимать то, о чем тут беседа идет).

Т.е. вот, допустим, есть у нас некий объект БД, который мы, допустим, определили програмно как-то так:

ТЧ = Новый ТабличнаяЧасть;
ТЧ,Колонки.Добавить("Колонка1", Новый ОписаниеТипов("Строка"));

Т.е. тут мы описали какую-то табличную часть, которую можем использовать в каком-то объекте. Допустим, как-то так:
Док = Новый Документ;
Док.ТабличныеЧасти.Добавить(ТЧ);

Дальше мы можем, допустим, унаследовать данные от этого объекта и развить что-то, да? Ну, например, так:
Док1 = Новый Документ(Док);
Док1.ТабличныеЧасти.Добавить(ТЧ1);

Но тут, как мы видим, никакого ООП в общем-то нет - просто мы используем методы объектов, конструируя отдельно табличную часть, отдельно документ, можем создать новый объект на основании старого....

Если говорить об ООП, то придется написать все иначе. Т.е. как-то так:
Объект Документ1 От Документ
НачалоОписанияОбъекта
  Перем ТабличныеЧастиДополнительные; // как бы указать, что это коллекция табличных частей...
  Перем НомерВходящегоДокумента; // как бы указать, что это строка
  Записать(РежимЗаписиДокумента Режим); // тут мы переопределяем метод "Записать()".

КонецОписанияОбъекта;

Процедура Документ1 .Записать()
  // что-то как-то иначе записываем...
КонецПроцедуры
Показать

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

Т.е. хотелось бы конкретного примера с обоснованием, зачем это нужно.

Вот чисто ООП было бы некоторым образом полезным элементом 1С, когда из какой-то библиотеки базовых объектов (прототипов) можно было бы получить через наследование (в идеале - множественное) получить объект с расширенным набором функций.
77. karimov_m 15.12.17 15:35 Сейчас в теме
(76) Да, все так.
Если мыслить терминами 1С - то это не совсем удобно.
Согласен, что для документа - если подразумевается иметь более 1 ТЧ - "можно" сделать коллекцию с типами элементов БазовыйКлассТЧ
В случае, если документы "в целом", должны иметь как минимум одну ТЧ (жестко прошитую с определенной структурой) И "возможность иметь" доп.ТЧ в рантайме, тогда можно написать так:

Класс БазоваяТабличнаяЧасть От ТаблицаЗначений
{
   БазоваяТабличнаяЧасть() //конструктор
   {
      ЭтотОбъект.Колонки.Добавить("НомерСтроки", Новый ОписаниеТипов("Число"));
      ЭтотОбъект.Колонки.Добавить("УникальныйИдентификатор", Новый ОписаниеТипов("УникальныйИдентификатор")); //да я знаю что так нельзя с УникальнымИдентификатором..
   }
};
Класс ТабличныеЧасти От КоллекцияЗначений;  //да такого типа КоллецияЗначений нет.. ну можно написать что-то вида СписокЗначений.. но он тоже избыточен..
Показать


Далее, примерно так же:


Объект Документ 
НачалоОписанияОбъекта
Перем ПостояннаяТЧ Как БазоваяТабличнаяЧасть;
 
КонецОписанияОбъекта

Объект Документ1 От Документ
НачалоОписанияОбъекта
  
  Перем ТабличныеЧастиДополнительные Как ТабличныеЧасти; //потенциальная коллекция ТЧ
  Перем НомерВходящегоДокумента; // как бы указать, что это строка
  Записать(РежимЗаписиДокумента Режим); // тут мы переопределяем метод "Записать()".

КонецОписанияОбъекта;
Показать


Т.е. каждый документ будет иметь в своем составе обязательно одну ТЧ с указанным описанием полей.
Данное описание делается ОДИН раз и все.
Но, т.к. есть конфигуратор - по сути, это описывается в нем.
Но различие вот в чем. По умолчанию - каждый документ имеет только одну ТЧ (которая описана в типе Документ), это как бы и есть, что мы называем, создать через конфигуратор. Но есть всегда возможность (это обусловлено описанием переменной ТабличныеЧастиДополнительные в Документ1) - добавить ТЧ в любой ОБЪЕКТ типа Документ1 в рантайме. Т.е. каждый экземпляр типа Документ1 имеет такую потенциальную возможность.

Соответсвенно, чтобы это реализовать на уровне системы - при компилировании такого кода, система должна создать соответствующие таблицы в БД, для поддержания такой возможности (типа Таблица "ТабличныеЧастиДокументаТипаДокумент1" - где строки будут иметь логические связи с таблицей Описательной для ТЧ и содержательной., т.е. многие-ко-многим через промежуточную таблицу)

Понимаю, скажите: нахрена иметь такую "возможность" - иметь разное количество ТЧ для одного и того же типа документа... Ну на это я только отвечу: я знаю для чего) Кому надо тот сможет воспользоваться этой фишкой. Пример ч ТЧ - это только пример, есть и другие интересные моменты как это можно использовать.
73. Darklight 33 14.12.17 16:44 Сейчас в теме
(68)Выше я предполагал добавление двух моделей классов в 1С:
1. Чисто программная модель: по факту "Структура" (для не тонкого клиента ещё можно сравнить с объектом обработки), но расширенная функциями, методами, свойствами и событиями (ну и с наследованием и с полимофизмом - но это всё решается на стадии работы конструктора объекта класса; и интерфейсами) . Как раз такой вариант его расскалдывается на просто "структуру" с данными и "общий модуль" с методами.
2. Типообразующая модель: по факту, что то близкое к "справочнику" или "документу", но несколько шире, т.к. я предложил три режима модели сохранения:
1) Ссылочная - тогда класс - это просто обычный ссылочный тип (я даже предложил все остальные ссылочные типы убрать - оставив только классы, наследуемые от разных базовых классов). Естественно, в БД сохраняются только данные.
2) Структурная - тогда класс - это почти тоже самое, что в 1. только определяет структурный тип - новое понятие для типа: тип, который состоит из структуры реквизитов; ну и дополнен методами, свойствами, событиями, и имеет наследование (структуры и методов), включая полиморфизм. Такой тип может быть назначен у любого реквизита (формы или, например, справочника) - при сохранении такой реквизит попросту разворачивается в набор полей - которые сохраняются в составе всей структуры объекта владельца в БД.
3) Сериализуемая - простао иная реализация режима 2) при сохранении в БД - объект не сохраняется как структура полей - а сохраняет свои данные в сериализованном виде, в MEMO поле БД своего реквизита владельца.

Аналогично происходит и сериализация владельца в реквизите-класса: 1) - будет ключ-ссылка; 2) - будет структура реквизитов; 3) будет строка сериализованного объекта.

Какие поля класса сохраняются в БД или сериализуются - настраивается в свойствах этих полей. В модели ООП вообще есть свойства классов - которые сами по себе нигде не хранятся - а лишь получают и передают данные в другие реквизиты и методы. Я тоже предложил отказаться от классических реквизитов-полей - оставить только свойства, которые, при необходимости, генерируют поля хранения данных, исходя из своего применения (это новая мода такая в мире ООП началась).

Ещё я говорил про интерфейсы: которые можно было бы назначать реквизитам и даже объектам метаданных - чтобы можно было получать унифицированные реализации API доступа к их данным и методам. Причём разные реализации - целые наборы. И проверять что такой-то объект имеет такую-то поддержку и его можно таким-то образом использовать. Это целый универсальный маркер для ветвления алгоритмов.


Соответственно, если конструировать объекты метаданных (любые), где нужно наследование и полиморфизм, то хорошо как раз применять классы вида "2.2)". То есть структурные. Когда часть реквизитов помещается в другой реквзит - структурный класс. В БД они все сохранятся как и ранее. Но Можно будет использовать иерархию наследуемых классов - расширяя набор реквизитов и методов вне места их применения. Наследовать напрямую объекты метаданных друг от друга я не предлагал (если только не отказаться от ссылочных метаданных - оставив только классы вида "2.1)".

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

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

1. Импорт расширения на весь модуль "#ИмпортироватьРасширение Модуль1.РасширениеТабличнойЧастиТоварыСправочникаНоменклатура" - размещается в модуле использования - тогда в нём (но только в этом модуле) у всех табличных частей "Справочник.Номенклатура.Товары" будут доп. методы из расширения.

2. Использование в локальной области алгоритма модуля, ограниченный скобками: "Расширение Модуль1.РасширениеТабличнойЧастиТоварыСправочникаНоменклатура Подключить ПеременнаяТЧТовары Использовать некоторый код, использующий расширение КонецРасширения" - расширений может быть несколько - через запятую, переменных может быть несколько - через запятую, код внутри любой - целый программный блок.

3. Через "приведение к интерфейсу" (расширение): "ПеременнаяТЧТоварыРасш = ПеременнаяТЧТовары Расширить Модуль1.РасширениеТабличнойЧастиТоварыСправочникаНоменклатура". Переменная "ПеременнаяТЧТоварыРасш " будет иметь так же методы и свойств расширения (и свои тоже останутся).


4. Использовать при создании объекта класса (не годится - если объект не создаётся): НекоторыйОбъектРасш = Новый НекоторыйКласс() Расширить Модуль1.РасширениеНекоторогоКласса".

Варианты 1. и 3. вместе - наиболее интересны. Хотя можно было бы иметь и все 4. Ибо, 1 и 2 - схожи но со своими плюшками, 3 и 4 тоже схожи, хотя, 3 - более удобен и универсален.
nazirovramzil; +1 Ответить
75. karimov_m 14.12.17 17:34 Сейчас в теме
(73)эм.. это Нургалиеву короче)) (и копию письма Бьёрну Страуструпу)
80. user922183 19.11.19 10:18 Сейчас в теме
Оставьте свое сообщение