Единый семинар «1С» для бухгалтеров и руководителей

Немного полезного кода для программистов 1С

Программирование - Инструментарий

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Послесловие

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

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

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

См. также

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

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

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

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


ps Написал по памяти. Не проверял. Мог косякнуть.
pps Это типа универсальная общая процедура. Подходит не для всего конечно
11. Maxim Kolkin (the1) 290 26.09.17 14:31 Сейчас в теме
(10) Что за удивительная абстрактная фигня?
12. Александр Цуканов (tsukanov) 76 26.09.17 14:47 Сейчас в теме
(11) Эта фигня делает то, что хочет автор первого коммента. Я ответил на ваш вопрос?
13. Сергей Старых (tormozit) 4546 26.09.17 15:03 Сейчас в теме
(10) Лучше брать эту процедуру из модуля ирОбщий.ИнтерактивноЗаписатьВЭлементУправленияЛкс инструментов разработчика. https://infostart.ru/public/16985/
user600603_v.soldatova; +1 Ответить
14. Александр Цуканов (tsukanov) 76 26.09.17 15:10 Сейчас в теме
17. Сергей Смирнов (protexprotex) 147 27.09.17 12:11 Сейчас в теме
Было бы полезным если бы фирма 1С сделала как в C++ (например как в C++) - отделила бы определение функции от самой функции. Т.е. типа h и cpp файлов. По моему, удобно было бы.
18. Владимир Безфамильный (Vovan1975) 14 27.09.17 12:19 Сейчас в теме
(17) ну ну. Удобно ога. Добавил параметр в процедуру и незабудь еще в объявлении его зафигачить.
Было это на 7.7, никакого удобства нет
20. Сергей Смирнов (protexprotex) 147 27.09.17 12:26 Сейчас в теме
(18) На 7.7. это было сделано через клавиатуру :-). h - файлы нужны для экспортируемых функций - т.е. можно было хранить объявления функций в одном файле, а сами функции - в другом. И к своему проекту подсоединять только h - файлы - и если Вы используете функцию, то она только и компилится в проекте -> проект меньше и работает быстрее. А 1С при открытии модуля все это хозяйство переводит в байт - код -> вывод - ускорение было бы работы 1С.
19. Anatolii Karasev (KapasMordorov) 408 27.09.17 12:20 Сейчас в теме
21. Дмитрий Кинаш (Dementor) 131 28.09.17 15:27 Сейчас в теме
(17)
Т.е. типа h и cpp файлов. По моему, удобно было бы.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Показать


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

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

Тут дело в чем. Реализация всего этого - основывается в конечном счете на реляционную модель БД, которая в бэке 1С.
Тем не менее - искусственными подходами можно добиться и реализацию Классов и наследование и (боже мой) Полиморфизм. Это лишь вопрос: кто на что готов заморочится. Пока система не подразумевает такого подхода (платформоориентированного ООП) в своем продукте - надо использовать то что имеешь)
53. Павел Одинцов (Darklight) 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.
С применением ООП БСП и пр. типовые библиотеки и прикладные решения - упростятся радикально!
А если ещё выправить кривизну в директивах определения контекста выполнения - перенеся их в модулях на методы (процедуры, функции, свойства в т.ч. классов), как в УФ, только для всех модулей. Так вообще красота настанет. Незачем один и тот же алгоритм распределять по куче модулей, если отдельные его подпрограммы доллжны выполняться на сервере, отдлльные на клиенте, отдельны и там и там, отдельные требовать привилегированного режима, а отдельные кешироваться.

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

Второй момент - это все же концепция ORM (Объектно-реляционное отображение»), которая является суть 1С только без ООП - «технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования». 1С идет дальше предоставляя помимо подхода ORM, еще интерфейсные реализации, аналитические подходы, накопительные, расчетные и прочие элементы и подходы в проектировании систем. Думаю, для бизнес приложений - это более чем достаточно, а все остальные сложные участки (ГИС, Мультимедиа, сложная Криптография и тп.) должны реализовываться и подключаться как сторонние библиотеки, для обеспечения нужд и вызовов из БизнесПлатформы, что 1С делает на текущий момент вполне продуктивно.
Donpager; +1 Ответить
55. Murad K (karimov_m) 13.12.17 12:42 Сейчас в теме
По мне, так интересным новым расширением языка или механизмов платформы - было бы более мощный и производительный аналитический и статистический аппарат. Чтобы можно было оперировать данными так же, как например в языке R. Это было бы более выгодное направление в развитии платформы, чем внедрение ООП
56. Павел Одинцов (Darklight) 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. Murad K (karimov_m) 13.12.17 16:06 Сейчас в теме
(56)Как вы говорите - концепция ООП есть в 1С, да, но только в базовом случае. Есть только "подход" изначально взятый из объектного мира (но не из ООП программирования!) - что есть Класс объекта (Документы, Справочники и тп.) и их отдельный сущности (Докуемнт. Справочник и тп.). Вот и вся ООП в 1С.

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

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

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

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

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

Этак так и программисты скоро не нежны будут)
60. Павел Одинцов (Darklight) 13.12.17 18:01 Сейчас в теме
(59)просто в очередной раз изменится парадигма программирования. Как когда-то она изменилась от машинных кодов простых операций над числами к ассемблеру далее к императивному стилю - далее к функциональному или логическому стилю, далее ответвление на программирование на нейросетях, далее к метопрограммированию, затем к полному декларатативному стилю (что там будет с парадигмами программирования далекого будущего пока судит сложно - но, будет ещё не один качественный переход, покрайней мере, следующая парадигма будет основана на нечёткой логике, вероятностях значений, предсказаниях событий и непрерывных параллельных ветвящихся вычислениях с неполными известными). И спрос на программистов будет только повышаться пока они не разработают ИИ, который будет себя совершенствовать быстрее и лучше, любого человека... и настанет эпоха сингулярности развития науки и общеста!
61. Murad K (karimov_m) 13.12.17 19:02 Сейчас в теме
(60) ИИ уже делает другие ИИ лучше, чем человек )
71. Павел Одинцов (Darklight) 14.12.17 15:25 Сейчас в теме
(61)Формально да, но формально сейчас ещё нет полноценного ИИ - лишь его математические имитации.
72. Murad K (karimov_m) 14.12.17 15:52 Сейчас в теме
(71) ну это уже общее определение.
Тут вопрос, что в вашем понимании "полноценное ИИ"..
Отсылки к созданию ИИ общего назначения? Это в проектах, но и это будет. Квантовые вычисления этому поспособствуют..
74. Павел Одинцов (Darklight) 14.12.17 16:50 Сейчас в теме
(72)Думаю, полноценный ИИ это сознание, которое определяется через самосознание себя как живого/мыслящего существа/индивида (т.е. разум, не способный определить себя как искусственный); и через призму восприятия других существ/индивидов - которые не смогли бы в общении определить этот разум как искусственный. Ну, и добавлю, плюс способный создать новый разум, который аналогично воспринимал бы себя (причём, создатель по-прежнему не смог бы сам себя посчитать искусственным разумом, даже после того, как сам же создал новый искусственный разум, обладающий тем ми же качествами, т.е. в т.ч., не способный самостоятельно определить, что он искусственный, и способный далее создавать такой же). Сложно выразился, прошу прощение... наверное просто не в духе сейчас давать изысканные определения.
62. Sergey Andreev (starik-2005) 1225 13.12.17 19:08 Сейчас в теме
Интересное обсуждение, только вот не совсем понятно, зачем ООП мешать с объектами, хранимыми в БД? Ну пусть они там хранятся как набор определяемых в конфигураторе данных, а вот обработка этого набора - вот это и есть хранимые отдельно методы объектов. Данные - отдельно (в БД), методы - отдельно (в конфигурации БД). Зачем наследовать документ? Достаточно наследовать его программную реализацию, т.е. код. При необходимости создавать объект, наследующий программный интерфейс от другого объекта, часть методов которого нужно переопределить (например, заказ поставщику, поступление, заказ покупателя, реализация, ... - товарные документы, в которых общего кода достаточно). С другой стороны, все это реализуется через общие модули, экспортные процедуры которых могут быть переопределены в другом модуле - достаточно вызвать вместо метода "ЗаказПокупателя.МояПроцедура" метод "Реализация.МояПроцедура". Для реализации подобного поведения ничего не нужно толком, ибо вызывая "МойОбъект.МояПроцедура" можно автоматически получить тот самый полиморфизм, когда объект вызывает тот метод, который ему предназначен (т.е. фактически если есть стопиццот разных объектов с этим методом, то каждый из них вызовет тот метод, которые для него определен в его модуле).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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


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

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

Понимаю, скажите: нахрена иметь такую "возможность" - иметь разное количество ТЧ для одного и того же типа документа... Ну на это я только отвечу: я знаю для чего) Кому надо тот сможет воспользоваться этой фишкой. Пример ч ТЧ - это только пример, есть и другие интересные моменты как это можно использовать.
73. Павел Одинцов (Darklight) 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 - более удобен и универсален.
75. Murad K (karimov_m) 14.12.17 17:34 Сейчас в теме
(73)эм.. это Нургалиеву короче)) (и копию письма Бьёрну Страуструпу)
Оставьте свое сообщение