Подобие Объектно-ориентированного программирования в 1С (ПООПс)

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

Статья для тех кто знаком с ООП и опустил руки.

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

Для начала нам необходимо объединить данные и методы, этот процесс называется инкапсуляцией. Давайте посмотрим на текст следующего общего модуля:

Общий модуль "Класс_ФизическоеЛицо"

Функция Конструктор() Экспорт
        МойОбъект = Новый Структура("Фамилия, Имя, _Пол", "", "", "");
        МойОбъект.Вставить("ф", ЭтотОбъект);
        Возврат МойОбъект;
КонецФункции

Функция Обращение(МойОбъект) Экспорт
        Возврат МойОбъект.Фамилия+", "+МойОбъект.Имя;
КонецФункции

Функция Пол(МойОбъект, Пол="") Экспорт
        Если НЕ ПустаяСтрока(Пол) Тогда
                МойОбъект._Пол = Пол;
        КонецЕсли;
        Возврат МойОбъект._Пол;
КонецФункции

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

И так с инкапсуляцией мы разобрались. Теперь нам нужно решить вопрос с самым главным – наследованием. Смотрим следующий текст модуля:

Общий модуль "Класс_Сотрудник"

Функция КлассРодитель()
        Возврат Класс_ФизическоеЛицо.ЭтотОбъект;
КонецФункции

Функция Конструктор() Экспорт
        МойОбъект = КлассРодитель().Конструктор(); // Родительский конструктор
        МойОбъект.Вставить("Должность", ""); // Добавляем новое свойство
        МойОбъект.Вставить("ф", ЭтотОбъект); // Заменяем модуль набора методов
        Возврат МойОбъект;
КонецФункции

Функция ОбращениеПоШтатке(МойОбъект) Экспорт    // Новый метод этого класса
        Возврат МойОбъект.Должность+" - "+МойОбъект.Ф.Обращение(МойОбъект);
КонецФункции

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

Функция Обращение(МойОбъект) Экспорт    // Наследованный метод
        Возврат КлассРодитель().СтрокаФИО(МойОбъект);
КонецФункции

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

Но в результате мы получили объектный полиморфизм.

Давайте посмотрим, как будут работать наши классы в прикладном решении:

Использование в прикладном решении:

Сотрудник = Класс_Сотрудник.Конструктор();
Сотрудник.Фамилия   = "Иванов";
Сотрудник.Имя       = "Иван";
Сотрудник.Должность = "Программист 1С";

Клиент = Класс_ФизическоеЛицо.Конструктор();
Клиент.Фамилия   = "Петров";
Клиент.Имя       = "Петр";

Сообщить(Сотрудник.ф.Обращение(Сотрудник));     // Иванов, Иван
Сообщить(Клиент.ф.Обращение(Клиент));   // Петров, Петр

Сообщить(Сотрудник.ф.ОбращениеПоШтатке(Сотрудник));     // Программист 1С - Иванов, Иван

Сотрудник.ф.Пол(Сотрудник, "Н");        // Недопустимое значение при установке пола сотрудника!
Сотрудник.ф.Пол(Сотрудник, "М");
Сообщить(Сотрудник.ф.Пол(Сотрудник));   // М

Как видно из примера финальный код почти похож на стандартный ОПП (за исключением буквы «ф» перед методом и передачей самого объекта в качестве первого параметра) и такой подход можно смело назвать Подобием Объектно Ориентированного Программирования в 1С (ПООПс)

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

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

Комментарии

Избранное Подписка

1. Armando 1391 24.07.16 22:27 Сейчас в теме

Подписался

2. ётун 24.07.16 22:48 Сейчас в теме

А что произойдет при передаче такого "объекта" с клиента на сервер и обратно?

3. adam26 32 24.07.16 23:18 Сейчас в теме

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

4. ётун 24.07.16 23:55 Сейчас в теме

(3) Спасибо!
Отсюда вытекает шестой и фатальный недостаток этой схемы. В то время, как бизнес-логика целиком обрабатывается на стороне сервера (фоновые, вебсервисы и т.п.) играться с этим на только на клиенте нет смысла.

5. adam26 32 25.07.16 03:46 Сейчас в теме

(4) ётун, Не согласен. Общий модуль может быть клиентским и серверным. По клиентской части Вы попадаете в модуль, а по серверной части выполняйте работы на стороне сервера. Находясь в одном модуле можно же вызвать из клиентской части серверную. Например так:

&НаКлиенте
Функция ПрочитатьНаКлиенте(Мойобъект) Экспорт
        Мойобъект = ПрочитатьНаСервере(Мойобъект);
КонецФункции

&НаСервере
Функция ПрочитатьНаСервере(Мойобъект)
        //
        // Читаем данные из базы и присваиваем свойствам полученные значения
        //
        Возврат МойОбъект;
КонецФункции

Показать

6. ётун 25.07.16 08:10 Сейчас в теме

(5) Примените, пожалуйста, то, что вы сейчас нафантазировали к вашей же методике и посмотрите, что получится.

13. adam26 32 26.07.16 02:15 Сейчас в теме

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

 ф = МойОбъект.ф;
        МойОбъект.Удалить("ф");
        Класс_ФизическоеЛицо_Сервер.ПолучитьПервогоНаСервере(МойОбъект);
        МойОбъект.Вставить("ф", ф);

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

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

52. kote 500 07.03.17 15:12 Сейчас в теме

(3)

В документации написано и тест показал что на сервере свойство "ЭтотОбъект" общего модуля не доступно. Следовательно "Объект" будет работать только на стороне клиента.

Используйте модуль обработки - он доступен везде. Сам использую их в качестве псевдоклассов (без наследования) - очень удобно, IMHO

53. adam26 32 07.03.17 15:33 Сейчас в теме

(52) Спасибо, я с этим знаком.

7. ardn 95 25.07.16 08:40 Сейчас в теме

Вы приводите недостатки предложенного метода. А достоинства вообще есть?

8. pumbaE 628 25.07.16 08:58 Сейчас в теме

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

9. nixel 800 25.07.16 09:44 Сейчас в теме

(8) pumbaE, да, обработки решают часть проблем. Появляются статические методы, нет нужды передавать объект, так как он содержится в виде объекта или формы. Но остальные недостатки те же. Наследования нет, полиморфизма нет, об абстракции даже и думать нельзя. В итоге и остается, что более-менее нативно в 1с можно сделать только инкапсуляцию, а все остальное - только через неудобные костыли :(

10. Makushimo 154 25.07.16 09:44 Сейчас в теме

один вопрос: а зачем?

зачем пытаться сделать ООП из того, что как ООП не проэктировалось.
Вы не занимались в гараже тюнингом ВАЗ 2108, случайно?

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

Оно было придумано не для ООП а для конкретных задач бизнеса.

Для ООП есть тот же С++, на котором, если не ошибаюсь и написана 1С.
Учите его и пишите на нем, если так хочется ~~поездить на иномарке~~ поиграть в ООП.

17. JohnyDeath 295 26.07.16 23:34 Сейчас в теме

(10) Makushimo,

зачем пытаться сделать ООП из того, что как ООП не проэктировалось.
Вы не занимались в гараже тюнингом ВАЗ 2108, случайно?

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

Оно было придумано не для ООП а для конкретных задач бизнеса

Не скажи. В 1с 7.7 был и есть 1с++. Весьма полезная и удобная штука. Наследование часто снимало часть костылей, особенно в 7.7, где был только один глобальный (общий) модули ;)

24. Dementor 603 27.07.16 10:38 Сейчас в теме

(17) JohnyDeath, именно по этой причине в 8-ке добавили множество общих модулей, а когда поняли, что этого недостаточно, то добавили еще инкапсуляцию кода в рамках метаданных в модулях менеджеров объектов. Хотя, как показала БСП со своими сериями одноименных общих модулей для переопределения, этого все таки немного не хвататет...

20. ADirks 181 27.07.16 09:33 Сейчас в теме

(10) Я конечно далёк от восьмёрки, но таки немножко заглядывал в БСП. Между прочим, там как раз разработчики (из самой 1С) пытаются реализовать полиморфизм. Выглядит совершенно ужасно.

ООП не серебряная пуля конечно, но иногда очень полезно. Даже инкапсуляция - и то уже неплохо.

11. zqzq 17 25.07.16 10:55 Сейчас в теме

По примеру

Сотрудник = Класс_Сотрудник.Конструктор();
...
Сотрудник.ф.ОбращениеПоШтатке(Сотрудник)

Чем это лучще, чем поместить функцию ОбращениеПоШтатке в модуль объекта Справочник.Сотрудники и вызывать

Сотрудник = Справочники.Сотрудники.СоздатьЭлемент();
...
Сотрудник.ОбращениеПоШтатке()

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

upd: OK, тут нет привязки к метаданным, но обычно всё-таки есть задача сохранения в БД данных, и городить огород с прослойкой ООП сомнительно. Ну и если без наследования и полиморфизма и без сохранения в БД, то есть штатная возможность -- обработки, как уже отмечали.

upd2: Также, для любителей ООП есть внешние компоненты, но тут плохо знаком.

15. adam26 32 26.07.16 02:49 Сейчас в теме

(11) zqzq, Одно из достоинств ООП в том, что метод описанный в базовом классе (в нашем примере это "Обращение") описывается один раз. И если потомок его не изменяет, то он автоматически обрабатывается базовым классом. Если бы у Вас были два похожих справочника один из которых физические лица, а другой сотрудники то метод "Обращение" Вам пришлось бы прописывать в каждом из них. В моем примере это простые методы. Но представьте что у Вас метод из 200-500 строк. Представьте что у Вас есть еще 20-30 справочников с похожим функционалом. И Вам в каждом необходимо разместить такой метод. А если нужно изменить метод для всех одновременно? Или в одном из справочников выполнить дополнительные действия с объектом?
Вы сейчас начнете писать что создадите общий модуль и перенесете туда общий метод, но это другой подход к программированию.
В данном случае вопрос не в новом методе которого нет у предка, а в том как можно произвести наследование.

По вопросу привязки к метаданным я ответил (13), про внешние компоненты в (14).

16. Makushimo 154 26.07.16 05:57 Сейчас в теме

(15)
вот прям зудит подискутировать
но не буду ладно, раз автор не готов -)))
ухожу с этой темы.

18. kalimehtar 20 27.07.16 08:39 Сейчас в теме

(15)

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

Общий модуль Люди:
Процедура Обращение(Объект) Экспорт
   ...
   500 строк
  ...
КонецПроцедуры

Модуль справочника Физлица:
Процедура Обращение() Экспорт
   Люди.Обращение(ЭтотОбъект)
КонецПроцедуры

Модуль справочника Сотрудники:
Процедура Обращение() Экспорт
   Люди.Обращение(ЭтотОбъект)
КонецПроцедуры

Показать

Вообще-то все современные конфигурации 1С в таком стиле и написаны.

19. kalimehtar 20 27.07.16 08:58 Сейчас в теме

(15)

В данном случае вопрос не в новом методе которого нет у предка, а в том как можно произвести наследование.

Можно и "наследованием":

Справочник Сотрудник
  Реквизит
    Физлицо

Процедура Обращение() Экспорт 
   Физлицо.Обращение() 
КонецПроцедуры

21. adam26 32 27.07.16 09:56 Сейчас в теме

(19) kalimehtar, Вы считаете ЭТО наследованием? Если ЭТО

Справочник Сотрудник
  Реквизит
    Физлицо

Процедура Обращение() Экспорт 
   Физлицо.Обращение() 
КонецПроцедуры

наследование, то как обращаться к свойствам которые установлены в классе "ФизЛицо" из класса "Сотрудник"? При наследовании я бы обратился

Сотрудник.Фамилия

или

Сотрудник.Имя

. В том примере который описали Вы кроме как

Сотрудник.ФизЛицо.Фамилия

или

Сотрудник.ФизЛицо.Имя

других вариантов нет. И что будет с Вашим кодом если будет 4-6 наследников? Если говорить о вашем предыдущем комментарии про общий модуль "Люди" то вы путаете "брата" и "потомка".

40. zqzq 17 28.07.16 09:28 Сейчас в теме

(19) kalimehtar, вы сейчас описали не наследование, а "включение". Наследование = А является Б (базовый класс), включение = А содержит Б. Кстати, включение более просто по поддержке и лучше поддерживает сокрытие данных/реализации, т.к. доступен только внешний интерфейс включаемого класса.

23. ToTMoM 27.07.16 10:35 Сейчас в теме

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

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

В ООП же определение этих "базовых" аксиом ложится на КОНКРЕТНЫХ, зачастую МАЛОЧИСЛЕННЫХ людей в течение КОРОТКОГО исторического промежутка времени...Плюс строительство начинается не с самых общих понятий, как в математике, и которые тоже не всегда со временем оказываются действительно самыми общими, а с некоторого уровня абстракции...

Что увеличивает вероятность ошибки в выборе абстрактных обобщающих параметров, и т.п. И тут 2 проблемы:

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

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

26. ADirks 181 27.07.16 11:25 Сейчас в теме

(23) Дык это, если начальные посылки не верны, то с любым подходом потом придётся всё переделывать.

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

главное:
1. без фанатизма
2. думать головой, и не следовать слепо

а ещё заметил, что большинство ругающих ООП просто вообще ничерта в этом не понимает.

27. artbear 1159 27.07.16 11:40 Сейчас в теме

(26) ADirks,

а ещё заметил, что большинство ругающих ООП просто вообще ничерта в этом не понимает.

+1

PS Алексей, привет! Давно тебя не было слышно :)

30. ToTMoM 27.07.16 12:22 Сейчас в теме

(26) ADirks, тут то и важно, откуда идешь. Если идешь от корней к листьям, то при неправильно предсказанном корне надо не просто "трансформировать", а иногда и полностью выкинуть весь последующий код, так ты предположил - а жизнь оказалась другой. Если ты идешь от листьев (наблюдаемых экспериментов, как в подходе физики), то завтра, если у тебя появился новый листик, то с следующими от них "общими" ветками может случиться лишь:
- надо две ветки 1 уровня "срастить" в более "толстую" ветку второго уровня... т.е. вынести обобщение
- надо ветку текущего(и если надо по цепочке далее) уровня сделать "потолще", т.е. расширить состав свойств, реквизитов... Вчера у вас например был "Красный листик" И "Зеленый листик" и у нас было только свойство Цвет. Завтра мы нашли другой листик, он оказался другим по Форме, добавляем еще свойство Форма и все.

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

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

35. ADirks 181 27.07.16 13:53 Сейчас в теме

(30) Ну я снова спрашиваю: причём тут ООП? Проектирование снизу вверх, и сверху вниз ну никак не связано с ООП. Если модель целевой системы построена неправильно, то при любой реализации будут проблемы. Если в ходе жизни целевая система кардинально изменилась, то и модель надо кардинально менять. Это свойственно любой модели, и избежать этого невозможно.

37. ToTMoM 27.07.16 17:07 Сейчас в теме

(35) ADirks, так и я о том, причем тут ООП! Что тогда по вашему ООП? Для меня парадигма программирования = определенный взгляд на организацию обмена и обработки данных. А не "полезные приемы структурирования кода"...Структура кода - это одно, взгляд на "организацию процесса" - другое. Первое должно решаться средствами компиляторов, синтаксис-анализаторов и т.п.

Теперь я просто оставлю еще и это здесь:
https://habrahabr.ru/company/hexlet/blog/303754/
http://rainman-rocks.livejournal.com/122876.html

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

И ничего про наследование. Это не тот ООП, который мы знаем сегодня:
Мне жаль, что давным давно я использовал термин «объект» для этой темы, потому что из-за этого многие люди фокусируются на меньшей из идей.
Большая идея это «сообщения». Ключ к созданию хороших масштабируемых систем это проработка механизмов общения модулей, а не проработка их внутренних свойств и поведения.

Вот вам пример.
Есть объект:

Прямая

У объекта Прямая есть 2 "разъема":

Прямая.Начало
Прямая.Конец,

куда может "подключится" любой объект, удовлетворяющий правилам:

при получение запроса "Сообщи свои координаты, N = 5, Формат = double" от объекта Прямая объект, подключенный в "разъем" Прямая.Начало/Конец должен ответить N числами типа double.

Допустим в нашей задаче N - размерность пространства в котором расположен объект Прямая. Все.

Любой объект, какой бы структурой и функционалом он не обладал, может подключиться к нашему объекту Прямая в "разъем" желаемый разъем и исполнять роль составного компонента объекта Прямая, если он удовлетворяет заданному объектом Прямая условию. Это может быть объект Многоугольник, который по запросу предоставит координаты какой-нибудь своей вершины , это может быть ГенераторСлучайныхЧисел, возвращающий по запросу N случайных чисел, это неважно, важно что требуемые условия выполняются.

Если изменятся требования объекта Прямая, то:

Если составной компонент продолжает удовлетворять условиям - работаем дальше
Если нет - тогда в объекте Прямая описано дальнейшее поведение.

Вот это и есть ООП. Не "шаблоны и иерархия для структурирования и мнимых красоты и удобства кода", а реальные сущности-объекты, взаимодействующие между собой.

А то что вы подразумеваете под ООП как алгоритмы структурирования кода и удобства разработки - это не ООП.

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

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

Хотя иногда объектно-ориентированный код действительно годится для повторного использования, таким его делает вовсе не объектно-ориентированность, а программирование в стиле „снизу вверх“. Возьмём, например, библиотеки: их можно подгружать и повторно использовать сколько угодно, потому что, по сути, они представляют собой отдельный язык. И при этом, совсем неважно, написаны ли они в объектно-ориентированном стиле или нет.

12. BigB 178 25.07.16 14:11 Сейчас в теме

(0) Без обид, но это бред какой то

14. adam26 32 26.07.16 02:32 Сейчас в теме

Уважаемые читатели, я не готов дискутировать на тему зачем ООП в 1С. Тем более что ВСЕ кто кодит в 1С используют "Lite" версию ООП в своей работе. Так например Любой справочник (например Организации) который вы создаете, является потомком класса Справочники у которых есть общие свойства и методы. Но вот сделать своего потомка от готового справочника у Вас увы не получится. Что касается других языков программирования, то написание на них модулей в стиле ООП действительно помогает, но встроить их в 1С можно только как внешние модули, а для некоторых решений с точки зрения политики безопасности и администрирования это не допустимо.
И последнее, те кто обратил внимание только на "Недостатки" должны попробовать полноценный ООП для того что бы понять его достоинства.

22. ToTMoM 27.07.16 10:10 Сейчас в теме

(0) Я просто оставлю это здесь...
https://habrahabr.ru/post/141505/
https://habrahabr.ru/post/141477/

25. adam26 32 27.07.16 10:48 Сейчас в теме

(22) ToTMoM, Смешно! Однако когда у Вас возникает вопрос о том как нарезать хлеб, батон, торт, пирог, пиццу, и так далее вы наверно задумаетесь как реализовывать этот процесс. Делать универсальную Резку или для каждого вида хлебобулочных изделий описать свой способ этого процесса (или наследовать его от предка). Вопрос ведь в том что резать можно так: Изделие.Нарезать() и не важно какое это изделие хлеб, батон, торт и так далее. А можно так как: УниверсальнаяРезка(Изделие). Это разные подходы к программированию.
Мне вот интересно как бы вы реализовывали с помощью "УниверсальныхРезалок" работу с графикой? Где есть такие различные фигуры как круг, прямоугольник, многоугольник и так далее. Вы бы тоже делали "УниверсальныйЗакрашиватель()" , "УниверсальныйРасчетПлощади()", "УниверсальныйРасчетВерхнегоЛевогоУгла()" и так далее?!...

28. ToTMoM 27.07.16 11:51 Сейчас в теме

(25) Дело в том, что изначально объекты в ООП задумывались не как "полиморфизм, наследование, инкапсуляция", а как типа реальные объекты, которые посылают друг другу потоки данных и т.п. Т.е. как есть внутренности(как и у человека), и есть внешний интерфейс, и посредством внешнего интерфейса они общаются...Все. Просто есть процессы, привязанные к объекту, осуществляемые самим(!) объектом, типа Кошка.Прыгнуть()... А есть процессы, которые КТО-ТО ДРУГОЙ выполняет НАД объектом...

Вы же не делаете микроволновку к каждому виду продукта...У вас есть продукты, есть микроволновка и есть алгоритм их взаимодействия. Т.е. вы должны у для конкретного Овощ описать ИНСТРУКЦИЮ для приготовления (в нашем случае для разогрева), а нагревать Овощ должна Микроволновка...
Микроволновка.Нагреть(ЭтотОвощ,ЭтотОвощ.ПолучитьИнструкциюПриготовления("НагревВМикроволновке")).

Т.е. должно быть:
Внешние интерфейсы описывают, какие данные и в каком формате можно передать Объекту и что он вернет назад в соответствии с полученными данными. Плюс, так как объекты должны быть независимыми, то один объект может отдавать инструкции в одном формате, а другой в другом, то еще нужно контролировать конвертацию данных, отдаваемых одними объектами в данные, принимаемые другими объектами.
В итоге поток данных должен быть таков:
Овощ.ВнутренниеДанные<->Овощ.ВнешнийИнтерфейс->ПереводчикИнструкций.ВнешнийИнтерфейс<->ПереводчикИнструкций.ВнутренниеДанные<->ПереводчикИнструкций.ВнешнийИнтерфейс->Микроволновка.ВнешнийИнтерфейс<->Микроволновка.ВнутренниеДанные<->Микроволновка.ВнешнийИнтерфейс-> Приготовленный Овощ

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

Вот есть например Точка, есть Прямая, это два независимых объекта. Объект Прямая объявляет: я могу состоять из двух объектов, которые подадут мне по моему запросу n-чисел типа double, где n = текущей размерности пространства, в котором я Прямая нахожусь. Если такие объекты есть и они выполняют наши договоренности - то я могу делать то-то и то-то. Если они не выполняют - то я могу делать только то-то, например сообщить об ошибке или еще что-то. Но это не родитель и предок, это один независимый объект, и второй объект, имеющий в составе другие объекты и зависящий от их поведения...

29. ToTMoM 27.07.16 12:03 Сейчас в теме

(25) что касается вопроса ОРГАНИЗАЦИИ ТЕКСТА КОДА и работы с ним, то тут нужно именно средство ОРГАНИЗАЦИИ ТЕКСТА КОДА.

Т.е. если методы повторяются, то явно в коде они не должны дублироваться, но ДЛЯ ПРОГРАММИСТА при желании они должны отображаться как дублированные. И программист, меняя метод ИЗ ЛЮБОГО МЕСТА ПРОГРАММЫ, включив режим "Отображение дублирования" указывает, меняет ли он поведение САМ МЕТОД, т.е. для всех, или он меняет ПОВЕДЕНИЕ этого метода для этого конкретного Объекта либо группы Объектов.

В итоге средство анализа синтаксиса САМО должно создать новую вторую, измененную процедуру и заменить вызовы у указанных объектов и в указанных местах. А иногда и далее САМО проанализировать код этих двух процедур, найти ОБЩУЮ часть, вынести её в новый метод и обернуть первые две процедуры, посредством вызовов третьей с разными параметрами либо еще как-нибудь...И все.

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

Вынесение общих процедур, наследование методов и дублирование кода - всем этим должно заниматься средство анализа, а не программист. Цель работы программиста - в работающем алгоритме, а организацию и удобство внесения изменений в код, структурирование обобщением и обертками должно выполнять специально обученное средство.
А суть ООП в данном случае - как классно что можно повесить все это на программиста! ...

31. vadim1011985 70 27.07.16 12:46 Сейчас в теме

тут то и важно, откуда идешь. Если идешь от корней к листьям, то при неправильно предсказанном корне надо не просто "трансформировать", а иногда и полностью выкинуть весь последующий код, так ты предположил - а жизнь оказалась другой

А можно просто в нужном классе переопределить или скрыть нужные методы что существенно сокращает время работы )) В этот и удобство ООП.

33. ToTMoM 27.07.16 13:09 Сейчас в теме

(31) vadim1011985, например, у тебя был класс Двигатель, у него были некоторые конструктивные внутренние части и механизмы работы с ними, например датчики температур, система подачи топлива и т.д.
Теперь у тебя появляется ЭлектроДвигатель. В принципе в данном случае можно расширить доступные типы Топлива, доопределить механизм работы "Системы подачи топлива" с учетом нового типа топлива "Электричество", но а во всем остальном? Просто добавить новых конструктивных элементов присущих ЭлектроДвигателю и скрывать другие части в зависимости от типа? Типа если это ЭлектроДвигатель, то явно я у него не увижу цилиндров и поршней, но по факту они есть? мдя...

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

И так каждый раз)

34. vadim1011985 70 27.07.16 13:31 Сейчас в теме

(33) ToTMoM,

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

Не совсем если на примере то можно объяснить так например есть класс TPoint c полями f_X f_Y и F_Color и Методом Paint (X,Y) и свойство SetColor который по заданным координатам закрашивает точку по заданному цвету

От него наследуется Класс TLine первоначально все методы и свойства этого класса открыты но например я не хочу что бы линия меняла цвет поэтому метод setColorя помещаю в секцию Privat и уже для класса TLine Этот метод недоступен. т.е. а Метод Paint (X,Y) переопределяем таким образом что он строит линию закрашивает точки от одной координаты до другой - таким образом образуя линию

Инкапсуляция

Инкапсуляция (encapsulation) - это механизм, который объединяет данные и код, манипулирующий зтими данными, а также защищает и то, и другое от внешнего вмешательства или неправильного использования. В объектно-ориентированном программировании код и данные могут быть объединены вместе; в этом случае говорят, что создаётся так называемый "чёрный ящик". Когда коды и данные объединяются таким способом, создаётся объект (object). Другими словами, объект - это то, что поддерживает инкапсуляцию.

Внутри объекта коды и данные могут быть закрытыми (private). Закрытые коды или данные доступны только для других частей этого объекта. Таким образом, закрытые коды и данные недоступны для тех частей программы, которые существуют вне объекта. Если коды и данные являются открытыми, то, несмотря на то, что они заданы внутри объекта, они доступны и для других частей программы. Характерной является ситуация, когда открытая часть объекта используется для того, чтобы обеспечить контролируемый интерфейс закрытых элементов объекта.

32. v3rter 27.07.16 12:50 Сейчас в теме

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

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

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

36. puzakov 27.07.16 15:48 Сейчас в теме

А чем, собственно, ООП будет полезно в рамках 1с?

38. karapuzzzz 63 28.07.16 02:01 Сейчас в теме

Зачем так издеваться над собой? 1С придумана для удешевления готового продукта. В SAP есть чистый ООП. Но стоимость внедрения/владения 1С в разы меньше. И именно такими жесткими мерами и был достигнут такой результат. "Дорогие" программисты на с++ создали продукт, который позволить делать готовые решения используя более "дешевых" программистов.

Не надо пытаться прикрутить к велосипеду пятое колесо. Тем более, что не получится от этого получить хоть какую-то выгоду.

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

39. vadim1011985 70 28.07.16 09:09 Сейчас в теме

(38) karapuzzzz, я бы сказал что 1с это результат ООП . Про наследование я бы поспорил, так как при создании справочника вы создаете очередной объект класса "Справочник" которому присуще свои поля (Наименование и код) , методы (НайтиПоКоду , НайтиПоНаименованию и т.д) и свои свойства о наследовании тут речи нет. Тоже касается и структур и соответствий вы создаете объекты некоторых классов и работаете с ними.

41. v3rter 28.07.16 13:43 Сейчас в теме

(38) karapuzzzz,

1С придумана для удешевления готового продукта.

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

42. puzakov 29.07.16 06:00 Сейчас в теме

(41) v3rter,

Не думаю. Стоимость продукта зависит от платежеспособности целевой аудитории.

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

43. adam26 32 01.08.16 01:51 Сейчас в теме

Все это время не было возможности писать ответы, но читал с большим удовольствием. Многое было переосмыслено (за это Огромное спасибо ToTMoM).

Жаль, что обсуждение данного поста переросло в обсуждение полезности и бесполезности ООП.
Исходя из всех комментариев к данной теме, можно обобщить:

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

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

44. Артано 663 01.08.16 02:06 Сейчас в теме

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

45. [email protected] 174 01.08.16 21:42 Сейчас в теме

да не надо для учетной системы ООП!
не надо!

46. el-gamberro 54 22.08.16 08:19 Сейчас в теме

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

ЗЫ Я видел приложения на андроид/джава после процедурщиков.
С точки зрения ООП жуть берет. Писать на джава в духе процедур это тоже известная проблема.

47. Артано 663 22.08.16 09:03 Сейчас в теме

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

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

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

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

48. [email protected] 174 29.08.16 14:03 Сейчас в теме

(47) Артано,

Ню-ню... высшая каста прямо программисткая...
..."не постигших суть ОПП"....
:))))

49. Артано 663 30.08.16 02:37 Сейчас в теме

(48) Нет, я всего лишь двигаюсь в направлении первичности понимания принципов, над отдельными фактами. И это не только к программированию относится. Использование любого инструмента, будь то методика анализа, среда разработки, даже лопата, в конце концов, без понимания фундаментальных принципов просто сведется к запоминанию "куда надо нажать чтобы заработало".

50. [email protected] 174 01.09.16 13:49 Сейчас в теме

(49) Артано,
"в направлении первичности понимания принципов, над отдельными фактами" :)))) - 1С не лучший помощник в этом!
Вы не в ту сторону двигаетесь! (уж извините) :))

некоторым очень не хватает умения: "куда надо нажать чтобы заработало"!
:)))

51. Aphanas 138 16.02.17 09:30 Сейчас в теме

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

54. v3rter 09.03.17 11:19 Сейчас в теме

При процедурном подходе полиморфизм невозможен.

Почему невозможен? Если доступен eval() | Выполнить(), то очень даже возможен, другое дело, что со скоростью интерпретатора. И даже когда eval недоступен, доступны гигантские CASE | ЕСЛИ ИНАЧЕЕСЛИ ИНАЧЕЕСЛИ ... КОНЕЦЕСЛИ, то есть возможен, но с "костылями". ООП перекладывает это на уровень компилятора. А вот написание кода в стиле описания объектов и переопределения методов изначально было побочным эффектом, который настолько всем понравился, что превратился в основной, оброс идеологией, методологией и вошел в учебники )

Оставьте свое сообщение

E-mail:

См. также

Регистры бухгалтерии. Общая информация 111

Статья Программист Нет файла v8 v8::БУ БУ Бесплатно (free) Практика программирования Математика и алгоритмы Разработка

Общая информация о внутреннем устройстве регистров бухгалтерии.

05.09.2019 6701 YPermitin 22

"Хочу универсально!" [Часть 1] 65

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Математика и алгоритмы Практика программирования Разработка

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

02.09.2019 4902 SeiOkami 35

Иерархия без "В ИЕРАРХИИ" 117

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

Говорится о том, как эффективно представлять иерархию в СУБД, как получать и использовать эти представления при решении задач в запросной технике. Уточняются и дополняются запросы из статьи "Уровни, глубина, прародители, циклы и аналоги запросом" [https://infostart.ru/public/160707/].

22.08.2019 4913 ildarovich 16

EnterpriseData – часть 3. Загрузка данных, идентификация объектов 62

Статья Программист Нет файла v8 v8::УФ 1cv8.cf ОС Бесплатно (free) Практика программирования Математика и алгоритмы Перенос данных из 1C8 в 1C8 Разработка

Основные этапы загрузки данных через EnterpriseData. Идентификация объектов загружаемых полностью и по ссылке. Приведены схемы процессов загрузки данных. Описание основных операций и обработчиков. Перечень процедур БСП, используемых при загрузке данных, структура «КомпонентыОбмена».

22.08.2019 4231 ids79 7

Обработчики событий при записи объектов. Зачем и что за чем? 202

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

Программисту, имеющему немного опыта на платформе 1С 8.3, бывает сложно разобраться: ПередЗаписью, ПриЗаписи, ПослеЗаписи, на сервере, на клиенте, в модуле формы, в модуле объекта.... Эта шпаргалка была создана в процессе обучения и реального опыта с целью разложить всё по полочкам, чтобы было четкое понимание в каком случае какой обработчик нужно использовать и в какой последовательности они запускаются при записи и проведении документов. Данная статья будет полезна в большей степени начинающим разработчикам. Но и опытным позволит освежить информацию, упорядочить её.

25.07.2019 12802 4 AlbinaAAA 23

Как проводятся документы в типовых конфигурациях от 1С 137

Статья Программист Нет файла v8::ОУ ERP2 УТ11 Россия УУ Windows Бесплатно (free) Математика и алгоритмы Практика программирования Разработка

В свое время, когда только начинал шаги в 1С и изучал, как проводятся документы в конфигурациях на платформе 1С по книге "Разработка управляемого интерфейса" (Хрусталева Е.Ю.), и там были представлены примеры совсем далекие от того, как сейчас проводятся документы в современных конфигурациях от 1С.

24.07.2019 16075 skv_79 32

FizzBuzz на 1С. Чем короче, тем веселее. Варианты принимаются... 8

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Математика и алгоритмы Разработка

Мне было скучно, я не мог себя заставить написать ничего полезного. И читал статью на Хабре. Потом я читал комментарии, а потом... нет я не ушел смотреть котиков на ютюбе. Я решил сделать несколько решений задачки FizzBuzz на 1С, с целью "чем короче, тем лучше". Прошу сильно не пинать, это просто развлечение для вечера.

24.07.2019 2864 vandalsvq 16

Управление качеством кода 136

Статья Программист Руководитель проекта Нет файла v8 Бесплатно (free) Математика и алгоритмы Рефакторинг и качество кода

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019 8233 Stepa86 29

Что делает "В ИЕРАРХИИ" в запросе? 94

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

Описание действий платформы 1С при использовании конструкции "В ИЕРАРХИИ" в запросах.

16.07.2019 8183 YPermitin 34

Создание отчетов с помощью СКД - основные понятия и элементы 208

Статья Программист Нет файла v8 v8::СКД Бесплатно (free) Практика программирования Математика и алгоритмы

Основные принципы работы СКД. Понятия схемы компоновки и макета компоновки. Описание основных элементов схемы компоновки: наборы данных, поля, вычисляемые поля, ресурсы, параметры.

25.06.2019 20983 ids79 17

Реализуем Стек, Очередь и Приоритетную очередь в 1С 52

Статья Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Практика программирования Математика и алгоритмы Разработка

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

24.06.2019 7804 RonX01 63

Организация хранения промежуточных данных 3

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

Организация хранения промежуточных данных в процедуре сверки.

29.05.2019 1954 scientes 1

Вычисление 200 тысяч знаков числа pi 73

Статья Программист Нет файла v8 Россия Бесплатно (free) Математика и алгоритмы

В статье рассматриваются возможности платформы выполнять сверхточные вычисления без использования сложных алгоритмов и внешних компонент на примере вычисления числа pi.

28.05.2019 3983 Oleg_nsk 93

Регистры накопления. Виртуальные таблицы. Часть №1: Обороты 84

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Практика программирования Математика и алгоритмы Разработка

Описание работы платформы 1С:Предприятие 8.2 с виртуальной таблицей "Обороты" регистров накопления.

20.05.2019 11073 YPermitin 5

Даем названия переменным: как префиксы экономят наше время 10

Статья Программист Стажер Внешняя обработка (ert,epf) v8 Бесплатно (free) Практика программирования Математика и алгоритмы Разработка

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

06.05.2019 3214 Designer1C 69

Заметки по SQL: Срез последних - аналог запроса 15

Статья Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Практика программирования Математика и алгоритмы

В статье описывается создание среза последних данных средствами классического языка запросов. Причем метод построения запроса был разработан еще во времена, когда автор работал с СУБД Oracle 9i и программировал на PL SQL. Основная идея заключается преобразовании запроса с подзапросом, в запрос без подзапроса (в примерах описывается преобразование до двух вложенных подзапросов). Запросы тестировались на реальных базах данных. Платформа - 1С:Предприятие 8.3 (8.3.10.2561).

15.01.2019 6318 IVC_goal 5

Разработка и сценарное тестирование с Vanessa-ADD. Концепция, теория и сквозной пример создания сценария 222

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Математика и алгоритмы

Первая часть цикла публикаций, посвященных Vanessa-ADD

09.01.2019 27568 Vladimir Litvinenko 69

Многопоточное восстановление последовательностей 41

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Математика и алгоритмы Универсальные функции

Универсальный алгоритм многопоточного фонового восстановления любой последовательности.

05.12.2018 7250 _ASZ_ 29

Автоматические и управляемые блокировки применительно к типовым конфигурациям 1С 127

Статья Программист Нет файла v8 v8::blocking 1cv8.cf Бесплатно (free) Математика и алгоритмы Практика программирования

Основные принципы работы с режимами автоматических и управляемых блокировок в 1С Предприятие 8. Теория и применение в типовых конфигурациях: БП, УТ, ЕРП

10.11.2018 22248 ids79 40

Основные понятия и механизмы оптимизации клиент-серверного взаимодействия в 1C 147

Статья Программист Нет файла v8 Россия Бесплатно (free) Математика и алгоритмы Практика программирования

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

23.08.2018 22870 Rain88 42

Теорема номер тринадцать 15

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

Использование математических методов для языка запросов.

15.03.2018 9358 vasilev2015 24

Введение в CI для 1С 87

Статья Программист Нет файла v8 Россия Бесплатно (free) Математика и алгоритмы

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

21.11.2017 19332 real_MaxA 22

Как работает серверный вызов в 1С 459

Статья Программист Нет файла v8::УФ Бесплатно (free) Математика и алгоритмы

Клиент-серверная архитектура заложена в платформе изначально — со времен «1С:Предприятие 8.0». Однако при разработке на 8.0 и 8.1 о разделении кода на клиентскую и серверную часть можно было не заботиться, поскольку на клиенте (на толстом клиенте) был доступен тот же функционал, что и на сервере. Всё изменилось с выходом платформы «1С:Предприятие 8.2», когда появился тонкий клиент. Теперь на клиенте доступен один функционал, на сервере — другой. Клиент и сервер «общаются» между собой с помощью серверного вызова. Конечно, это усложнило процесс разработки, но с другой стороны – можно создавать более оптимальные (быстрые) решения, поскольку все сложные задачи выполняются на сервере.

18.11.2017 44247 pahich 77

#Область ВНЕШНИЕ_ВЫЗОВЫ или MVC в 1С, библиотечность и упрощение интеграции кода 43

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Математика и алгоритмы Универсальные функции

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

12.10.2017 14810 for_sale 58

Групповая разработка конфигураций в крупном холдинге 68

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

О чем мы сегодня поговорим? • О становлении и развитии групповой разработки конфигураций 1С в крупном холдинге с использованием хранилища конфигураций. • Обсудим практически все аспекты использования хранилища в командной разработке. • Я расскажу про те методы и идеи, которые мы пробовали использовать, какие используем до сих пор, от каких отказались и почему.

15.08.2017 17545 stas_ganiev 15

Автоматизация процесса 1С-разработки 91

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

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

07.06.2017 23029 ekaruk 9

Пишем игру Минер. Обработка событий ActiveX в 1С 29

Статья Программист Нет файла v8 Россия Windows Бесплатно (free) Практика программирования Математика и алгоритмы

Пример демонстрирует обработку событий генерируемых компонентой ActiveX в 1С.

29.05.2017 12732 user621724_Dimav1979 11

Как я доступ на kb.1c.ru получал 91

Статья Программист Нет файла v8 Россия Бесплатно (free) Решение задач на 1С:Специалист Математика и алгоритмы

kb.1c - база знаний по технологическим вопросам крупных внедрений и не только. В этой базе знаний собираются методики и решения технологических проблем эксплуатации 1с, check-list'ы и инструкции по настройке ПО на серверах. Какие-то из размещенных статей дублируются на ИТС. Когда я искал пути получения доступа к нему я столкнулся с проблемой: мало кто доподлинно знает как получить доступ к нему, не работая у франчайзи 1с. Я опишу путь, который прошёл я, как физическое лицо.

01.05.2017 22536 ikekoval 33

Улучшение стандарта "Структура модуля" 6

Статья Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Математика и алгоритмы

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

26.03.2017 12325 o.nikolaev 23

"Распределение в запросе" или "избавляемся от перебора" 185

Статья Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Математика и алгоритмы Универсальные функции

Хороший перебор - это отсутствие перебора. Рассмотрим пример замены полного перебора запросом.

16.12.2016 28631 alexandersh 48

Планы обмена. Квитировать или гарантировать? 24

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Практика программирования Математика и алгоритмы

Планы обмена предлагают использовать две стратегии удаления обработанных изменений: квитирование и гарантированная доставка сообщений. Как сделать правильный выбор?

12.12.2016 14558 zhichkin 9

Некоторые принципы оптимизации запросов 1С (+SQL) 115

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

Разработка нового функционала часто связана с созданием новых таблиц в базе и написанием запросов. Собственно, размышляя о запросах, мы и формируем в голове содержание таблиц, индексы и количество таблиц и индексов. Заранее можно уверенно рассуждать о том, какая нужна архитектура, если задачу удалось понять. На этом этапе важно привлекать свой опыт. Что же делать, если его нет? Как рассуждать о запросах и формате хранения?

17.11.2016 8898 ture 40

Использование git для доработки типовых конфигураций 1С 230

Статья Программист Нет файла v8 Беларусь Украина Россия Бесплатно (free) Математика и алгоритмы

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

11.10.2016 188459 pumbaE 31

Оптимизация запросов 1С:Предприятие – от теории к практике 116

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Математика и алгоритмы

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

07.10.2016 32080 bpc222 20

Регистры сведений 1С. Как это устроено. 729

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

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

05.08.2016 151050 Sergey.Noskov 155

Переводим расширения на 8.3.8. Памятка. 79

Статья Программист Нет файла v8 Россия Бесплатно (free) Практика программирования Математика и алгоритмы

Типовые конфигурации переходят на новую платформу 8.3.8 без режима совместимости. А значит нужно переделывать расширения под эти условия. В статье небольшая памятка о переводе расширения на 8.3.8

29.07.2016 39711 mrXoxot 12

Опыт практического применения методики BDD на 1С. Написание сценариев 121

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Математика и алгоритмы

Эта статья открывает цикл публикаций, в которых я хочу поделиться опытом использования методики BDD при разработке на 1С. В этой статье речь пойдёт о написании сценариев.

03.07.2016 20335 oleynik.dv 132

Заметки про запросы. Последовательность. 110

Статья Программист Нет файла v8 Windows Бесплатно (free) Математика и алгоритмы Практика программирования

Рассуждения, основанные на контрпримерах. Определяем последовательность операций с помощью одной только консоли запросов. Версия 2.

27.05.2016 29631 vasilev2015 31

Оптимизация планирования доставки грузов. Алгоритм кластеризации k-means (метод K-средних). 26

Статья Программист Нет файла v8 УТ10 УПП1 Windows Бесплатно (free) Математика и алгоритмы

Что такое кластеризация? Это объединение объектов в непересекающиеся группы, называемые кластерами, на основе близости значений их атрибутов (признаков). В результате в каждом кластере будут находиться объекты, похожие по своим свойствам друг на друга и отличающиеся от тех, которые расположены в других кластерах. При этом, чем больше подобие объектов внутри кластера и чем сильнее их непохожесть на объекты в других кластерах, тем лучше кластеризация.

10 стартмани

09.02.2016 26528 mi1man 4

Контур.EDI изнутри, или история командной разработки тиражного продукта на 1С 174

Статья Программист Нет файла v8 Россия УУ Windows Оптовая торговля Бесплатно (free) Интеграция Практика программирования Математика и алгоритмы

“Система - больше, чем просто совокупность ее элементов”; “Несколько разработчиков - это еще не команда разработки”. Расскажу, как мы прочувствовали эти очевидные утверждения на своей шкуре.

17.11.2015 36045 skif47 88

Порядок записи движений регистров при проведении документа 95

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Математика и алгоритмы

Когда-то была программа 1С седьмой версии, и все программисты знали: если нужно проанализировать и/или исправить движения документа - смотри модуль документа, процедура ОбработкаПроведения(). В 1С 8 все гораздо сложнее. Кроме модуля проведения есть еще подписки на события, а также движения документа может "создавать" не сам документ. Эта статья о том, как происходит проведение и в какой момент записываются движения документа по регистрам.

13.11.2015 80529 triton_tver 8

.NET(C#) для 1С. Динамическая компиляция класса обертки для использования .Net событий в 1С через ДобавитьОбработчик или ОбработкаВнешнегоСобытия 51

Статья Программист Нет файла v7.7 v8 Windows Бесплатно (free) Разработка внешних компонент Математика и алгоритмы

Динамическая компиляция класса обертки для использования .Net событий в 1С через ДобавитьОбработчик или ОбработкаВнешнегоСобытия, а так же генерация модулей на C# и 1С для подключения к событиям. Использование DynamicMethod и ILGenerator. Представлены примеры для использовании событий System.IO.FileSystemWatcher (Ожидает уведомления файловой системы об изменениях и инициирует события при изменениях каталога или файла в каталоге.) и SerialPort (обработка сканера штрих кода подключенного к COM порту). Обертка позволяет использовать классы .Net только на языке 1С. Реализация 1C Messenger описанного здесь http://infostart.ru/public/434771/

12.11.2015 42188 Serginio 35

Три способа получить дерево элементов иерархического справочника 52

Статья Программист Нет файла v8 Бесплатно (free) Математика и алгоритмы

Рассматривается применимость и недостатки следующих способов получения дерева 1) Запрос с использованием итогов по иерархии 2) Формирование дерева обходом выборки с упорядочиванием по иерархии 3) Формирование иерархии по списку элементов транзитивным замыканием

11.11.2015 63125 32ops 9

Распределение суммы по базе 48

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Математика и алгоритмы

Или еще одна попытка изобрести велосипед )))

08.11.2015 27732 starik-2005 19

Мультиинструментальный Brute Force 4

Статья Программист Нет файла v8 Windows Бесплатно (free) Математика и алгоритмы

Решение задачи из Project Euler с помощью 1С, а также дополнительных программ, серверов и прочих хитростей.

30.10.2015 10443 scientes 4

1С с "плюсами" 74

Статья Программист Нет файла v8 Бесплатно (free) Разработка внешних компонент Математика и алгоритмы Универсальные функции

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

14.10.2015 19970 IntelInside 47

Знакомство с технологией Automation-сервер на примерах 33

Статья Программист Нет файла v8 Windows Бесплатно (free) Математика и алгоритмы

В статье рассмотрены принципы работы технологии Automation-сервер на конкретных примерах.

28.09.2015 26193 niko11s 10

Критерии отбора 83

Статья Программист Нет файла v8 1cv8.cf Windows Бесплатно (free) Математика и алгоритмы

Статья посвящена объекту конфигурации - критерий отбора. Поговорим о сущности этого объекта и о методах работы с ним.

24.09.2015 49480 niko11s 13

По ссылке или по значению? Ключевое слово Знач и с чем его едят 196

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Математика и алгоритмы

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

12.08.2015 37186 Evil Beaver 239