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

Публикация № 677396

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

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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Послесловие

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

+143 –

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

Наименование Файл Версия Размер
Шаблон + общие модуля
.zip 4,42Kb
24.09.17
17
.zip 4,42Kb 17 Скачать

Специальные предложения

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

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

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

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


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

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


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

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

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

Нет, они писали более сложные программы - решение транспортных задач для разнородного транспортного парка с десятками ограничений и графом дорог, который являлся функцией от самих машин (тонажа, наличия прицепов, купленных разрешений на проезды в закрытые части городов) и от времени (часто грузовики в города пускают только ночью, а днем можно пикапиками и газельками возить, а про работу мостов по часам я уже вообще молчу - не успел проскочить на второй берег, уже считай полдня потерял), а так же программы прогнозирования спроса и прочие математические модели.
Нет, у руководителя проекта никаких возражений не было. Общие *.hpp для разных проектов отлично компилировались в промежуточные *.a файлы, которые далее уже больше не пересобирались без надобности и использовались в линковке различных бинарников. Вся магия в правильно настроенных мейк-файлах.
Да, к 1С не относится и слава Богу :)
+ – Ответить
27. eugeniezheludkov 32 29.09.17 09:27 Сейчас в теме
(22) вот я понимаю зачем нужен интерфейс в ООП языках типа ява, шарп, но вот зачем нужно дублировать информацию при помощи .h не понимаю! пока разрабатываешь без ТЗ, сигнатуру метода класса перепишешь миллион раз и каждый раз нужно лезть в этот .h и переписывать его там причем не так как в cpp файле, честно - это ужасно.
конечно тут все дело в волшебных ИДЕ которые должны сами лезть и исправлять все в .h , но например ArduinoIDE, vi , nano к таким не относится (((
+ – Ответить
28. protexprotex 123 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 123 11.12.17 18:40 Сейчас в теме
(46) Тут написано в контексте основного отличия применения h-файлов от применения функции Далее (как в 1С 7.7)
+ – Ответить
23. protexprotex 123 28.09.17 15:36 Сейчас в теме
(21) А по поводу ошибок - там синтаксический контроль есть. Он об таких ошибках сообщит.
+ – Ответить
25. Dementor 675 28.09.17 16:48 Сейчас в теме
(23) Есть такой. Помню как-то запустил синтаксический контроль по типовой торговле - насыпалась куча ошибок про отсутствие назначенных обработчиков и прочая мелочь. А ведь это писала "элита 1С" :) Рассматривайте визуальную часть формы как заголовочный файл, где в событиях прописаны названия функций и предопределен состав реквизитов. Вот как сейчас платформа позволяет делать ошибки, так и с внедрение еще одного промежуточного слоя ничего не изменится!
+ – Ответить
26. protexprotex 123 28.09.17 17:17 Сейчас в теме
(25) Ну, может быть. В общем, для 1С (пока) это не надо. Но именно создатель С++ очень трепетно относился к такому разделению :-)
+ – Ответить
30. Darklight 22 04.12.17 11:48 Сейчас в теме
(17)Ой, не надо нам в XX век, пожалуйста. В XXI веке для этого есть ООП, свойства, интерфейсы (объектов) и паттерны MVP и MVVM (на худой конец MVC или даже "MVPVM") для отделения визуального представления от реализации.
+ – Ответить
31. protexprotex 123 04.12.17 12:25 Сейчас в теме
(30) Все новое - хорошо забытое старое :-)
+ – Ответить
32. Darklight 22 04.12.17 12:32 Сейчас в теме
(31)Не всё; ну, или, порой, оно уж настолько старое, что уже из ряда "никто не помнит - никогда не было"
+ – Ответить
33. protexprotex 123 04.12.17 12:56 Сейчас в теме
(32) Ну это Вы слишком. Например, с++ builder 6 - хоть и был выпущен в 2005 году, но все же в 21-ом веке. Это примеру. Ну а C++ Builder 10.1 - я Вам по секрету скажу - вообще недавно. И там и там есть и такой порядок написания кода. Или тоже никто не помнит этого, хотя полно народу на этих системах пишет? :-) Ну и майкрософт - тоже в их системах программирования есть и h и cpp файлы. Или Вы другого мнения? - их там нет?
+ – Ответить
34. Darklight 22 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 4 04.12.17 13:59 Сейчас в теме
(34)
А заголовочные файлы.... да кому они сейчас нужны!

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

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

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

И ещё. я языах программирования, включая 1С уже давно появилось сворачивание реализаций (частей кода) в строку (код-фолдинг), включая создание своих произвольных областей сворачивания - это тоже эффективно позволяет скрывать с глаз долой алгоритмы и определения, которые будут громоздки для быстрого восприятия.
+ – Ответить
38. protexprotex 123 04.12.17 14:25 Сейчас в теме
(36) Вообще - то h - файлы не для сворачивания кода используются, а для подключения внешних библиотек к своему коду. У 1С такая парадигма - давайте все что нужно/не нужно соберем в среду разработки -> и получается, что инсталлятор самой 1С-ки получается такой, что в пору терабайтники уже скоро покупать, и памяти надо гигов 8 и т.д. А вот в (например) в C++ builder - там другая парадигма - например, надо Вам работать с http - подключите head (h) файл соответствующего компонента - и работайте с ним. А если Вам не нужен компонент indy - то и не подключайте его. И память не занимает и др. Но тут 1С-кам деваться некуда - у них язык - интерпретатор. Их код 1С выполняется на стековой машине - без самой 1С - он и не запуститься. Это не exe-файл.
+ – Ответить
40. Darklight 22 04.12.17 14:33 Сейчас в теме
(38)Тогда это больше походит на холивор что лучше Java или Assembler(C++) или что лучше - Платформа высокого уровня абстракции доступа к данным, или - куча библиотек начиная от низкоуровневого доступа к памяти и диску, заканчивая алгоритмами визуализации и обработки коллекций....
+ – Ответить
42. protexprotex 123 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 4 04.12.17 15:14 Сейчас в теме
(36)Заголовочный файлы есть во всех языках программирования, назвать их можно по разному но суть останется, это декларирование функций, классов, интерфейсов. Если конечно вы пишите грамотно структурированный код, который позволит вам поддерживать большое приложение.
+ – Ответить
44. Darklight 22 04.12.17 15:47 Сейчас в теме
(43)Разные методы декларирования API (в т.ч. описанные мной выше) и конкретная реализация, пришедшая, по большей части ещё с процедурного программирования, в виде отдельного заголовочного файла - это вещи разных плоскостей, разного уровня. В исходном комментарии автор насаждал идею, что выделение определения API в отдельный заголовочный файл - это хорошо и надо в возвращаться к корням. На что я возразил - что сейчас, в XXI веке, для достижения цели формирования API используются уже совсем иные методики. Далее разговор стал скатываться в области технологий взаимодействия разных библиотек и разных приложений друг с другом; и в проблемы оформления гигантских классов, где я пояснял как сейчас идёт развитие идей программирования в других языках, без какой-либо возврата в каменный век. Да, платформа 1С и IDE (включая EDT) почти ничего из этого не умеет, а жаль... но будем надеяться - когда-нибудь и платформа 1С будет иметь высокоразвитую и современную среду разработки, позволяющую поддерживать большое приложение.

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

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

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

Но это всё так.... мелочи...
+ – Ответить
45. alex_sh2008 4 04.12.17 19:49 Сейчас в теме
(44)В языке 1С есть все что нужно для написания того уровня приложений для которых он предназначен, единственный недостаток, устаревшие алгоритмы трансляции кода, и соответственно медленное исполнение кода.
+ – Ответить
37. protexprotex 123 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 86 04.12.17 14:32 Сейчас в теме
Хм.. слишком упрощенный паттерн..

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

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

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

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

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

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

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


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


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

А теперь вдумайтесь.. как было бы круто, если мы просто бы могли использовать несколько уровней наследования, делать наш подкласс документ_согласования, наследовать его от стандартного документа, а уже от документа_согласования - создавать конечные документы (т.е. сейчас 1С не умеет делать иерархию наследования, все документы наследуются от стандартного класса документ и всячески параллельно пришлепываются функции.. в этом есть очень много недостатков (но зато все просто и понятно и быстро для 1сников).
+ – Ответить
41. Darklight 22 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 22 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 22 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 22 13.12.17 16:22 Сейчас в теме
(57)Дело не только в приросте скорости. Дело в повышении уровня абстракции, через повышение декларатативного стиля программирования (и использования). То есть должно быть больше таких понятий как "у меня есть", "тут есть связь", "я хочу", "посчитай", "преобразуй к виду", "совмести". Которые уже транслируются к оптимальному набору машинных операций и выборок данных, без повторений. Именно повышения уровня декларатативности ведёт к повышению возможностей машины самой решать как ей лучше делать и как ей это всё делать параллельно и без блокировок!
+ – Ответить
59. karimov_m 13.12.17 17:03 Сейчас в теме
(58) ну это в иделе. Суть такого подхода будет стремиться к следующему выражению: "1с, а 1с - а сделай выборку всех незаблокированных договоров (справочник) контрагента ООО Ромашка и верни таблицу взаиморасчетов по дебиторке в разрезе этих договоров, только той дебиторке, что критически просроченная, которая образовалось более 80 дней назад. Описание возвращаемых полей данных возьми в справочнике "состав полей отчета ДЗ" "

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

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

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

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

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

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

Про жесткую привязку к БД никто не говорит) Тем не менее, если мы говорим о потенциальном внедрении ООП (настоящего) в платформу 1С, не брать в расчет, что все данные так или иначе хранятся в БД - нельзя. Это к вопросу о сложности такой системы.
+ – Ответить
68. starik-2005 2021 14.12.17 13:16 Сейчас в теме
(67)
Наследование данных как описание их структуры - это совсем другое.
А примеры будут?
+ – Ответить
69. minimajack 60 14.12.17 13:35 Сейчас в теме
(68)
наследование данных
http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#entity-inheritance
mixins
http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#embeddables

есть такое
karimov_m; +1 – Ответить
70. karimov_m 14.12.17 14:47 Сейчас в теме
(68) примеры чего?) Повествовательная часть моего высказывания уже пример)
Я же не контрагрументирую - а веду беседу, чтобы развить мысль.

Я не сторонник отстаивания мнения ради самого процесса отстаивания..
+ – Ответить
76. starik-2005 2021 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 22 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 Сейчас в теме
Спасибо. Помогло
+ – Ответить
Оставьте свое сообщение

См. также

Управление состоянием для шаблона MVC и работы с данными объекта
+29 –

Статья Программист Архив с данными v8 1cv8.cf Абонемент ($m) Работа с интерфейсом

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

1 стартмани

18.03.2020    1515    1    kalyaka    31       

DevOps для 1С. Онлайн-курс проходит с 16 апреля по 11 июня 2020 года. Промо

Данный онлайн-курс предусматривает изучение процессов DevOps, их применение при разработке на платформе 1С. В результате прохождения онлайн-курса вы сможете: настроить ПО необходимое для проведения проверок и тестирования, создавать сценарии тестирования и объединять их в комплексные процессы, создавать скрипты для автоматизации процессов DevOps.

12000 рублей

Вам нравятся запросы в 1С?
+19 –5

Инструменты и обработки Программист Конфигурация (md, cf) v8 v8::Запросы 1cv8.cf Абонемент ($m) Практика программирования Разработка

Речь не только о том, что простейший запрос с "легальным" оформлением растянется на пол-экрана, речь еще обо всем, что нужно написать "в нагрузку" к тексту запроса. Все эти "Новый Запрос", "УстановитьПараметр" и последующие пляски с обработкой результата... Пора с этим заканчивать!

1 стартмани

03.07.2019    14718    4    m-rv    86       

Модель объекта
+11 –

Инструменты и обработки Программист Конфигурация (md, cf) v8 Абонемент ($m) Инструментарий разработчика

Подсистема позволяет описать модель данных объекта, где описана зависимость между реквизитами, и затем использовать эту модель в разных сценариях работы с объектом. Версия платформы: 8.3.6 и выше. С небольшими доработками будет работать на 8.2.

1 стартмани

30.06.2019    7484    1    vadim1980    4       

Онлайн-курс «Практические аспекты внедрения регламентированного учета и расчета себестоимости в 1С:ERP на крупных промышленных предприятиях» с 20 апреля по 15 мая 2020 года. Промо

Курс рассчитан для подготовки экспертов по регламентированному учету и учету затрат для внедрения на крупных промышленных предприятиях с «исторически сложившимся» учетом

9000 рублей

Безопасная работа с транзакциями во встроенном языке
+197 –

Статья Программист Конфигурация (md, cf) v8 1cv8.cf Абонемент ($m) Практика программирования

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

1 стартмани

25.03.2019    24100    9    tormozit    44       

Редактор объектов информационной базы 8.3
+73 –

Инструменты и обработки Программист Пользователь Внешняя обработка (ert,epf) v8 v8::УФ 1cv8.cf Россия Windows Абонемент ($m) Инструментарий разработчика Универсальные обработки

Универсальная внешняя обработка для редактирования реквизитов и табличных частей объектов информационной базы, редактирование движений документов. Доступ ко всем реквизитам объектов, есть возможность выгрузки и загрузки данных (объекты и движения документов) через XML. Платформа 8.3, управляемые формы. Версия 1.1.0.43 от 31.03.2020

2 стартмани

23.01.2019    18519    224    ROL32    33       

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

Конструктор мобильного клиента Simple WMS Client: способ создать полноценный ТСД без мобильной разработки. Теперь новая версия - Simple UI (обновлено 14.11.2019)
+191 –

Инструменты и обработки Программист Архив с данными v8 v8::Mobile БУ УУ Android Оптовая торговля Производство готовой продукции (работ, услуг) Розничная торговля Учет ОС и НМА Учет ТМЦ Абонемент ($m) Инструментарий разработчика Сканер штрих-кода Терминал сбора данных Мобильная разработка

Simple WMS Client – это визуальный конструктор мобильного клиента для терминала сбора данных(ТСД) или обычного телефона на Android. Приложение работает в онлайн режиме через интернет или WI-FI, постоянно общаясь с базой посредством http-запросов (вариант для 1С-клиента общается с 1С напрямую как обычный клиент). Можно создавать любые конфигурации мобильного клиента с помощью конструктора и обработчиков на языке 1С (НЕ мобильная платформа). Вся логика приложения и интеграции содержится в обработчиках на стороне 1С. Это очень простой способ создать и развернуть клиентскую часть для WMS системы или для любой другой конфигурации 1С (УТ, УПП, ERP, самописной) с минимумом программирования. Например, можно добавить в учетную систему адресное хранение, учет оборудования и любые другие задачи. Приложение умеет работать не только со штрих-кодами, но и с распознаванием голоса от Google. Это бесплатная и открытая система, не требующая обучения, с возможностью быстро получить результат.

5 стартмани

09.01.2019    32379    246    informa1555    200       

Навигатор по конфигурации базы 1С 8.3
+136 –

Инструменты и обработки Программист Пользователь Внешняя обработка (ert,epf) v8 v8::УФ 1cv8.cf Россия Windows Абонемент ($m) Инструментарий разработчика Универсальные обработки

Универсальная внешняя обработка для просмотра метаданных конфигураций баз 1С 8.3. Отображает свойства и реквизиты объектов конфигурации, их количество, основные права доступа и т.д. Отображаемые характеристики объектов: свойства, реквизиты, стандартные рекизиты, реквизиты табличных частей, предопределенные данные, регистраторы для регистров, движения для документов, команды, чужие команды, подписки на события, подсистемы. Отображает структуру хранения объектов базы данных, для регистров доступен сервис "Управление итогами". Платформа 8.3, управляемые формы. Версия 1.1.0.57 от 31.03.2020

3 стартмани

28.10.2018    24861    247    ROL32    67       

Онлайн-курс «Автоматизация процессов управления МТО: методика сбора и формализации требований» с 1 апреля по 13 мая 2020 года. Промо

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

40000 рублей

Работа с публикациями "Инфостарт"
+15 –

Инструменты и обработки Программист Архив с данными v8 УУ Абонемент ($m) Практика программирования О сообществе WEB

Работа с рублевыми публикациями на сайте "Инфостарт": ведение клиентов, заказов, обновление файлов публикации, рассылка обновлений.

1 стартмани

13.09.2018    14051    12    RocKeR_13    16       

Позиционирование в помещении с помощью нейросети по сигналу Wi-Fi. Интерактивная карта склада в 1С с показом позиции
+67 –

Инструменты и обработки Программист Бизнес-аналитик Приложение (apk) v8 Windows Абонемент ($m) Инструментарий разработчика Практика программирования

Данная публикация содержит в себе редактор и интерактивную карту склада или иного помещения, на которой в реальном времени отображается позиция устройства, координаты которого вычисляются по уровням сигнала нескольких роутеров Wi-Fi. В статье и приложенным к ней разработкам предлагаются инструменты и методика для реализации вычисления точной геопозиции внутри помещений с помощью нейронной сети. Конфигурация написана на релизе 1С:Предприятие 8.3.12.1412, клиентское приложение имеет минимальный уровень совместимости SDK -16.

5 стартмани

09.08.2018    21384    25    informa1555    26       

Подборка программ для взаимодействия с ЕГАИС Промо

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

Полезный код для программистов 1С (часть 2). Помощник заполнения.
+79 –

Инструменты и обработки Системный администратор Программист Конфигурация (md, cf) v8 Абонемент ($m) Практика программирования

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

1 стартмани

20.07.2018    14018    15    vandalsvq    14       

Работа с данными выбора
+49 –1

Инструменты и обработки Программист Архив с данными v8 Россия Абонемент ($m) Практика программирования Работа с интерфейсом

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

1 стартмани

17.07.2018    32390    17    kalyaka    16       

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

ВСТАВИТЬ В Справочник.Номенклатура (Код, Наименование) ЗНАЧЕНИЯ ("001", "Новый товар")
+105 –

Инструменты и обработки Программист Внешняя обработка (ert,epf) v8 v8::Запросы 1cv8.cf Абонемент ($m) Практика программирования

Вас не обманывают ваши глаза, это запрос на изменение данных! И это работает без прямого доступа к БД, регистрации и смс.

1 стартмани

01.06.2018    23922    86    m-rv    57       

БСП: Дополнительная обработка (Регламенты), примеры от простого к сложному
+255 –

Статья Программист Внешняя обработка (ert,epf) v8 1cv8.cf Абонемент ($m) Практика программирования БСП (Библиотека стандартных подсистем)

Очень много попадается странных решений, которые можно решить через БСП:Дополнительные отчеты и обработки. Я бы вообще БСП из-за этой подсистемы переименовал в «Большое Спасибо Программистам». Поработаем с подсистемой в части написания регламентных заданий.

1 стартмани

10.05.2018    36091    31    dsdred    36       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Как выполнить отчет на СКД через COM и получить данные отчета?
+89 –

Статья Программист Архив с данными v8 УПП1 Россия Windows Абонемент ($m) Практика программирования

Для чего это нужно. Например, нужно в одной базе получить какой-либо показатель из другой базы. Этот показатель вычисляется в каком-либо сложном отчете, который написан на СКД. Можно, конечно, "скопипастить" текст запроса из другой базы, немного подправить его и выполнять в том же COM подключении. Но с этим теряется гибкость: если отчет изменился, то нужно помнить о том, что где-то есть его "немного модифицированная" копия. В статье будет рассмотрен пример получения данных из базы ЗУП.

2 стартмани

08.05.2018    21907    11    wowik    3       

Работа со схемой запроса
+182 –1

Статья Программист Конфигурация (md, cf) v8 v8::Запросы Абонемент ($m) Инструментарий разработчика Практика программирования

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

1 стартмани

24.04.2018    36236    81    kalyaka    34       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Регистры правил [Расширение]
+14 –

Инструменты и обработки Системный администратор Программист Расширение (cfe) v8 v8::Права УТ11 Абонемент ($m) Инструментарий разработчика Информационная безопасность

Регистры правил - права доступа, запрет редактирования, автоподстановка реквизитов и т.д.

10 стартмани

15.03.2018    14040    29    33lab    1       

Заполняем по шаблону (по умолчанию)
+70 –

Инструменты и обработки Программист Архив с данными v8 v8::УФ 1cv8.cf Абонемент ($m) Практика программирования

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

1 стартмани

08.02.2018    21456    20    mvxyz    17       

Время учиться: до 3 апреля скидки на курсы до 40%! Промо

Для тех, кто решил провести самоизоляцию с пользой, Инфостарт запускает акцию «Время учиться». С 30 марта до 3 апреля 2020 года наши курсы и видеозаписи докладов INFOSTART EVENT 2019 INCEPTION продаются со скидкой!

Бесплатная проверка контрагентов в ФНС (общий модуль с алгоритмом). На примере выводим статус в список справочника контрагентов
+127 –

Статья Программист Конфигурация (md, cf) v8 1cv8.cf Абонемент ($m) Практика программирования

Если вам интересно проверить контрагенте в ФНС, вам поможет данная публикация. Весь алгоритм работы строится на основе данных, полученных с сервиса http://npchk.nalog.ru совершенно бесплатно.

1 стартмани

01.02.2018    30011    64    rpgshnik    48       

Расширение возможностей печати: Вывод произвольного нижнего и верхнего колонтитула
+9 –

Отчеты и формы Программист Внешняя обработка (ert,epf) v8 1cv8.cf Абонемент ($m) Печатные формы документов Практика программирования Универсальные функции

Расширяем функционал вывода нижнего / верхнего колонтитула. Стандартно 1С имеет достаточно ограничений по выводу и наполнению колонтитулов содержимым, взять хотя бы такие, как вывод только текста и отсутствие ограничения на номер конечной страницы. А при разработке кода сталкиваешься с тем, что свой блок с нижним колонтитулом нужно прижимать к низу страницы. Казалось бы быстро решаемый вопрос, но и в нем есть нюансы. Сейчас я расскажу о том, как решалась эта задача. UPD 15.02.2018. Добавлен вывод верхнего колонтитула; Вывод колонтитулов на первой и последней странице управляется параметрами; Научился считать страницы: Добавлено заполнение переменных аналогичных стандартным из колонтитулов; Задаются форматы даты и времени. Ограничения прежние: 1. Повторно сформировать табличный документ после смены параметров страницы интерактивно.; 2. Передавать данные для более плотной печати как можно более мелко нарезанными кусками.

1 стартмани

29.12.2017    30592    25    agent00mouse    0       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Печатная форма, сделанная как расширение конфигурации для БП 3.0. Новые возможности БСП
+26 –

Инструменты и обработки Программист Расширение (cfe) v8 БП3.0 Абонемент ($m) Практика программирования Универсальные печатные формы

Печатные формы на внешних обработках скоро канут в лету. На смену им приходят ПФ, реализованные в виде расширений конфигурации. Не нашел на сайте примеров таких расширений. Привожу пример подобного расширения для БП 3.0.

1 стартмани

06.12.2017    22250    52    kwazi    6       

Программное формирование форматированной строки в стиле html+inline CSS
+59 –

Инструменты и обработки Программист Внешняя обработка (ert,epf) v8 1cv8.cf Абонемент ($m) Работа с интерфейсом Инструментарий разработчика

Если вам приходилось работать с форматированными строками программно, то вы знаете, какая это боль. Данное решение облегчает программное формирование таких строк.

1 стартмани

18.11.2017    24918    29    bonv    9       

Базовый курс для начинающих 1С-программистов. Онлайн-интенсив со 2 июня по 2 июля 2020 г. Промо

Данный онлайн-курс является начальной ступенью по изучению базовых принципов программирования в системе “1С:Предприятие” и предназначен для обучения 1С-программированию “с нуля”.

4500-9500 рублей

Расширения конфигураций 1С: учимся перехватывать методы
+121 –

Инструменты и обработки Программист Расширение (cfe) v8 v8::УФ 1cv8.cf Абонемент ($m) Практика программирования

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

1 стартмани

30.05.2017    104161    14    signum2009    45       

Многопоточность. Универсальный «Менеджер потоков» (фреймворк) с отслеживанием зависимости объектов
+181 –

Статья Программист Архив с данными v8 1cv8.cf Россия Абонемент ($m) Практика программирования Математика и алгоритмы Универсальные функции Производительность и оптимизация (HighLoad)

Восстановление партий, расчет зарплаты, пакетное формирование документов или отчетов - теперь все это стало доступнее. * Есть желание повысить скорость работы медленных алгоритмов! Но... * Нет времени думать о реализации многопоточности? * о запуске и остановке потоков? * о поддержании потоков в рабочем состоянии? * о передаче данных в потоки и как получить ответ из потока? * об организации последовательности? Тогда ЭТО - то что надо!!!

26.05.2017    43535    171    DarkAn    86       

Базовый курс по обмену данными в системе 1С:Предприятие. Онлайн-интенсив с 12 по 28 мая 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, обеспечивающих обмен данными между различными прикладными 1С-решениями и взаимодействие с другими информационными системами. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”.

5500 рублей

Набор подсистем "Умные таблицы"
+64 –

Инструменты и обработки Системный администратор Программист Архив с данными v8 Беларусь Россия Казахстан Абонемент ($m) Инструментарий разработчика

Данный набор подсистем – прикладная библиотека, призванная помочь программисту 1С быстрее решать ряд типовых задач бизнес-логики, таких как: ведение статусов объектов, отправка почтовых сообщений в определенное время, ведение произвольных таблиц с возможностью редактирования, сохранения и группировки, ориентированные на расчет бюджетных таблиц (план продаж, ретробонусы B2C, проценты по договорам B2B и договорные условия по КАМ), расчет коммерческой политики для бюджетных таблиц, исполнение произвольных алгоритмов с хранением кода в информационной базе, определение рабочих баз, хранение файлов во внешних СУБД (Postgre SQL, MS SQL и MongoDB) и выполнение произвольного кода после изменений ссылочного объекта вне транзакции изменения.

1 стартмани

22.05.2017    28346    99    Silenser    33       

Простой способ индексирования интервалов
+186 –

Статья Программист Конфигурация (md, cf) v8 Абонемент ($m) Практика программирования

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

1 стартмани

28.09.2016    35836    41    ildarovich    22