Первое что меня поразило при знакомстве с 1С – это отсутствие ООП. Никаких классов, наследований, закрытых методов. А ведь любой код должен быть логически структурирован. А классы — это то, что позволят это сделать с наименьшими нервами.
Потом, поработав с 1С, понял, что объекты конечно есть. Одни предопределенные (вроде «Документы», «Регистр сведений»), а другие зависят от фантазии программиста («Обработки»). Конечно, нет полиморфизма, нет наследования, но объектную модель построить можно.
Только есть другая проблема: большинство 1С-программистов все пишут в «процедурном стиле». Язык сам по себе толкает создать общий модуль. Потом поместить в этот модуль кучу процедур для обработки данных и поддерживать все это «спагетти» из вызова процедур.
Похожая проблема наблюдается в Delphi. Там тоже программист может ничего не знать про ООП и писать приложения. Никакого разделения на классы, весь код зачастую помещается в модуль формы. Но плюс Delphi в том, что с опытом все приходит, т.к. в книжках объектная модель пропагандируется.
Рассмотрим 1С в объектно-ориентированном подходе. Предопределенные объекты (Документ, Регистр,..) содержат код 3-х типов:
- «Модуль объекта» — Код отвечает за конкретный экземпляр объекта, а вернее обработку данных этого объекта.
- «Модуль формы» — Код отвечает за обработку действий пользователя.
- «Модуль менеджера» — Код отвечает за операции над определенным типом объекта, без привязки к конкретному экземпляру. В обычных языках это зовется «статические методы»
Все процедуры и функции в этих модулях можно воспринимать как методы класса. Область видимости процедур или функций регламентируется ключевым словом «Экспорт» (здравствуй инкапсуляция). Правда, реквизиты нельзя сделать закрытыми, но это обходится созданием глобальных переменных в самом модуле.
А существование «модуля формы» — это вообще фишка 1С, которой можно гордиться. Этот модуль позволяет отделить код отвечающий за обработку действий пользователя и код который обрабатывает данные (Ни дать ни взять MVC).
Только проблема в том, что большинство разработчиков в модуль формы «суют» код, отвечающий за общую логику работы с данными. Сам грешен. По-моему, разработчикам платформы 1С не мешает в «модуль формы» добавить быстрый вызов «модуля объекта» (например через контекстное меню).
Теперь про объекты, созданные самим программистом. На infostart встречал различные статьи о эмуляции объектно-ориентированной модели. Но согласитесь, манипуляция со структурами для хранения данных – занятие муторное и неинтуитивное. Я считаю, что лучшее решение, это воспринимать «обработки» как описание собственных классов.
Наглядный пример. В «Списке значений» мне не нравится диалог, вызываемый методом «ОтметитьЭлементы». Не хватает кнопок, которые выделяли (или снимали выделение) со всех пунктов. И вот обработка СписокЗначенийРас как раз и дает такой диалог. Добавляем обработку в конфигуратор, а потом вызываем:
СписокЗначенийРас = Обработки.СписокЗначенийРас.Создать();
СписокЗначенийРас.Добавить(«Пример1»);
СписокЗначенийРас.Добавить(«Пример2»);
Если СписокЗначенийРас.ОтметитьЭлементы() тогда
СписокЗначенийРас.Данные.ОтметитьЭлементы(); // а это стандартный диалог
КонецЕсли;
К сожалению, наследования в 1С нет. Поэтому методы и свойства которые есть у СпискаЗначений надо либо дублировать в обработке или обращаться к реквизиту который хранит оригинальный список значений (в моем случае это СписокЗначенийРас.Данные)
Теперь переходим в конфигуратор. Находим обработку СписокЗначенийРас и, вызвав на нем контекстное меню, переходим в «модуль менеджера». Добавляем следующую функцию.
// Устанавливает или снимает (интерактивно) пометки у элементов списка значений.
// Заголовок — Заголовок окна диалога
// РабочиеДанные — список значений
Функция ОтметитьЭлементы(Заголовок=Неопределено, РабочиеДанные) Экспорт
Результат = Ложь;
ФормаОЭ = ПолучитьФорму(«ФормаОтметитьЭлементы»);
ФормаОЭ.ПрочитатьДанные(РабочиеДанные);
ФормаОЭ.ЧитатьДанныеПриОткрытие = Ложь;
Если Заголовок <> Неопределено тогда
ФормаОЭ.Заголовок = Заголовок;
КонецЕсли;
РезультатФормы = ФормаОЭ.ОткрытьМодально();
Результат = (РезультатФормы = КодВозвратаДиалога.ОК);
Возврат Результат;
КонецФункции
Теперь мы можем вызвать диалог еще проще.
сзДанные = Новый СписокЗначений;
сзДанные.Добавить(«Пример_1»);
сзДанные.Добавить(«Пример_2»);
Обработки.СписокЗначенийРас.ОтметитьЭлементы(«Заголовок»,сзДанные);
Чем не статический класс?
В подходе использования обработок как классов есть несколько недостатков.
- Нет наследования. Хочется возможности указывать родителем хотя бы простейшие типы (СписокЗначений, ТаблицаЗначений, Дата, Строка…)
- Класс-обработка показывается в общем списке обработок. Хотелось бы отдельный тип объектов.
На этом пока все. Надеюсь, заметка позволила вам разглядеть в 1С зачатки ООП 🙂
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
полезная очень статья. Автору спасибо 🙂
Не кажется ли вам, сударь, что в 1С ООП и не нужно? ИМХО, язык программирования — это просто инструмент и для своих целей язык 1С вполне подходит. 1С настолько популярна не в последнюю очередь из-за дешевизны поддержки. Можно посадить студента какого-нибудь биологического факультета с небольшим наличием мозга, дать желтые книжки, и он рано или поздно сможет разобраться в коде. А вы предлагаете усложнять код, созданием дополнительных обработок без описания с неявным и не совсем понятным предназначением… Тем более непонятным человеку, не знающему фундаментальных основ ООП. Зачем это нужно?
(2) a-novoselov, полностью согласна с замечанием, зачем мешать мух и котлет, 1С вполне выполняет свои функции в данном диапазоне. Не хватает возможностей, нужно наследование и т.п., есть куча других языков программирования. У каждого своя сфера применения
(2) a-novoselov, может нужно потому что делает жизнь легче?)
Большинство людей ведь хранят вещи аккуратно сложенными у себя в шкафу т.к. легче их найти. Да и если другой что то захочет взять то ему легче разобраться.
Хороший пример, это «Универсальный обмен данными XML». Ее кончено можно использовать как внешнюю обработку, а можно вызвать ее из своего кода и весь функционал будут доступен. При этом не надо лезть внутрь обработки и смотреть как все работает. Обработка как «черный ящик». На входе получает данные, а при запуске отдает результат.
А можно было сделать в виде функций и процедур. И тогда надо было бы понять какие функции нам нужны, разбираться с параметрами, смотреть что возвращает, понимать последовательность запроса функций.
ООП на самом деле не сложная штука. И если человек закончил биологический факультет — он разберется)
Мне несколько неясен вообще повод для возникшей здесь дискуссии. Кто-то говорит, что не нужно мешать мух с котлетами, кто-то говорит, что в шкафу аккуратно вещи хранить удобнее. В статье обо всем этом уже написано. Как такового объявления классов там нет, но оно и не нужно. В 1С уже хватает необходимых полочек, чтобы хранить вещи в аккуратном виде и каждую вещь на своем месте. Каждый объект в системе 1С предназначен для каких-то своих целей, будь это регистр накопления (очень удобный для накопления данных и получения остатков) или регистр расчета (для хранения данных о периодических расчетах и удобного получения необходимых данных из виртуальных таблиц соответствующих). И если вам необходимо создать нечто свое уникальное — есть обработки. Что опять таки было описано в статье. На выходе универсальная система для решения учетных и управленческих задач на предприятиях. В итоге получается, что все кто писал выше правы, каждый по своему, и для каждого есть возможность реализовать желаемое в 1С 🙂
(4) Да, согласен, что сложные вещи нужно делать с применением основ ООП. И так это, в основном, и делается.
(4) согласен полностью, объектный подход необходим, но только будьте добры, если разрабатываете свои классы, не забывайте писать документацию, без этого никакой пользы от них для других программистов не будет, только лишние проблемы в виде кучи потраченного времени, чтобы разобраться, как с вашими объектами работать.
Какое ключевое преимущество для конечного потребителя (заказчика) даст ООП в 1С ?
(5) ViteG, в 1С нет наследования, а это, пожалуй, основное преимущество объектной модели. Скажем, вам нужно было бы сделать копию типового документа, но с расширенными под себя свойствами. Как вы делаете это сейчас? Копируете типовой документ, добавляете свои процедуры и функции, переопределяете функционал, либо лезете в типовой документ и меняете всё там (чего лучше не делать). В первом случае после типового обновления ваш функционал может перестать работать, скажем, если поменяют какой-то реквизит в регистре, куда ваш документ делал движения. Во-втором, обновление тупо просто затрет ваш функционал, либо вы потратите много времени на саму процедуру обновления, чтобы разобраться, что поменяли в 1С и как теперь с этим жить. Так вот в объектной модели вам не нужно на эту тему волноваться, вы просто создали бы экземпляр класса типового документа, содержащий весь заложенный в него функционал и добавили бы свои методы и свойства, причем каждый раз при обновлении типовой функционал бы обновлялся вместе с стандартным документом и ваш экземпляр класса типового документа не потерял бы актуальности, а ваш код не был бы затронут. Это не единственное преимущество объектной модели и попытки реализовать ее подобие в 1С уже давно идут, взять, хотя бы универсальный отчет, обмен данными XML и т.д. Проблема в том, что не хватает хорошей документации по этим объектам. А с появлением управляемых форм ситуация еще более усугубилась в этом плане.
(8) розница.net,
Код легче поддерживать и развивать. Теоретически будет меньше «костыликов» в коде, а значит и стабильней.
Новому человеку будет легче разобраться в вашем коде.
(9) s.sintsov, согласен. С наследованием в 1С проблема.
(9) Проблема с обновлением конфигурации после изменений есть и очень актуальна.
Насколько я знаю в Аксапте это решено при помощи так называемых слоев, а 1С ограничилась тем что есть конфигурация разработчика и основная конфигурация (ну и конфигурация БД), но это не совсем то что нужно в данном случае. Аналог наследования очень был бы полезен в данном случае.
Интересен тон некоторых комментариев: мол, и без ООП прекрасно проживем. Это покруче, чем у того парня, что удивился, узнав, что говорит прозой. Здесь же неприятие какое-то: не будем говорить прозой, и все тут.
Возможно, и в самом деле наследование не очень-то нужно в рассматриваемой прикладной области (хотя в зачаточном состоянии оно существует). Но уж инкапсуляция данных священна. Без этого сколько-нибудь объемный код становится абсолютно неуправляемым.
«Ты хоша мне и подруга, но порядок быть должОн»…
А теперь самое интересное. Имеем 8.2 на Управляемых формах. Доступность Модуля менеджера (как и модуля объекта): Сервер, толстый клиент, внешнее соединение. Таким образом приведенный вами код не будет работать на тонком клиенте.
(14) JohnyDeath, Вероятно. Я на толстом все делаю.
Не понимаю, как наследование может быть не полезным? Это же сэкономленное время разработки и исправления ошибок.
Спасибо за статью, тема действительно актуальная.
(15), (16)
Тема актуальна, но для УФ совсем не жизнеспособна, т.к. «объекты» можно создавать только на Сервере (или в толстом клиенте), а таких конфигураций скоро будет подавляющее большинство. А ООП «только не сервере», когда объект класса надо сохранять в некотором сеансе (на клиенте), крайне геморойная и неблагодарная затея, которая перечеркивает все плюсы ООП на корню.
(17) Причем тут тонкий клиент. Если бы было реализовано хотя бы некое подобие наследия, это облегчило бы рутинную разработку, правку и поддержку конфигураций.
Позвольте и мне вставить свои 5 копеек. Предположим, что Вам нужно сделать документ Приходный кассовый ордер, который очень похож на типовой, но имеет некий дополнительный реквизит, и имеет некие особенности при проведении. При использовании ООП можно было бы поступить примерно так (простите, приходится на ходу придумывать свой псевдоязык):
1. Создаём документ МойПриходник. В свойстве НаследуетсяОт указываем ПриходныйКассовыйОрдер (предположим, что все объекты 1С имеют свойство НаследуетсяОт, где указывается типовой объект — родитель вновь создаваемого объекта)
2. В объекте МойПриходник создаём реквизит МойРеквизит. В модуле формы и модуле объекта пишем, как мы работаем с этим реквизитом. Болше ничего не пишем, поскольку весь функционал документа-родителя сохраняется (если мы сознательно не его не переписываем).
3. Проведение документа пишем примерно так:
Процедура ОбработкаПроведения()
ОбработкаПроведения(); // вызывается обработка проведения из родительского класса
….. // теперь наши действия
КонецПроцедуры
Ну вот приблизительно так. А теперь прикиньте, как бы вы стали решать поставленную задачу сейчас, без использования ООП. Или вносить исправления в существующий приходник (проблемы при обновлениях). Или создавать свой приходник, копируя типовой, и добавляя функционал.
Теперь предположим, поменялось законодательство, приходники стали в чём-то другими. При использовании ООП изменения в родительском классе наследуются в дочерний, и Вам в документе МойПриходник, возможно, вообще ничего не придётся переделывать (конечно, если изменения законодательства не революционны). А без использования ООП придётся писать ручками (или копировать изменившиеся процедуры из типового приходника).
Надеюсь, понятно рассказал.
(18) при том что в модуле менеджера нельзя «ОткрыватьФорму», и вообще создавать объект обработки или вызывать «статические» методы на клиенте.
Про наследование в v8: — разработка 2009 года!
(16),(18) — не понимаю, зачем заявлять такие вещи бездоказательно.
Это — в данном виде — только лозунги, вроде политических или религиозных.
Лично я думаю, что никакая вещь не может быть полезной «вообще», то есть всегда и всюду.
А рутинную разработку может облегчить дисциплина программирования, безотносительно к трем священным словам.
автору зачет. само дерево конфигурации невозбранно намекает, что в 1С применяется ООП. это дерево я бы сравнил с .h-файлом для C/C++, например
а кроме того, в 1С мы видим ORM (объекты Регистр Накопления, Регистр Сведений и т.п.) и если лезть дальше — то и MVC.
должен заметить так же, что для усиления эффекта от вброса повидла в вентилятор рекомендую следующие шаги:
1) листинги кода переписать на английском языке;
2) добавить файл внешней обработки или замастырить ролик на ТыТрубе с заголовком «Я гарантирую это»;
3) разместить статью на Хабре =)
В средневековые времена программирования, к данным мы применяли функции. Для того, чтобы нарезать хлеб, брали структуру «хлеб» и передавали ее как параметр функции «нарезать»:
нарезать(хлеб);
Потом пришла эпоха объектно-ориентированного программирования. И вместо функии «нарезать», нам надо попросить «хлеб» нарезать себя — вызываем метод «нарезать» у объекта «хлеб»:
хлеб.нарезать();
Очевидно, что это значительное улучшение.
В настоящее время объектно-ориентированное программирование стало еще изысканнее. Сначала мы создаем объект «хлеборезка» и затем просто передаем ему «хлеб» для «нарезки»:
Хлеборезка хлеборезка = new Хлеборезка();
хлеборезка.нарезать(хлеб);
Прогресс налицо.
(23) В той статье более интересны обсуждения, чем сама статья. Например вот этот пост:
(19) «Не надейтесь.» Если «некие» особенности при проведении МойПриходника не перекрывают, а чисто дополняют стандартный функционал ПКО, то подпиской на события к стандартному документу можно обойтись. Добавится программный модуль, и для хранения некого реквизита — некий регистр, а документ-то новый зачем?
Так что мне такая полуконкретизация непонятна. Да, я чего-то не знаю про ООП, я чего-то не понимаю в ООП, но я что, должен просто на слово поверить, что ООП в 1С лучше, чем 1С без ООП?
Совершенно очевидно, что без наследования нет ООП. Все разговоры о каком-то ООП в 1С абсолютно беспочвенны. Да, можно условно считать «полочки» типа документов, регистров и тд абстрактными классами, но это НИЧЕГО не даёт ни для программиста, ни для пользователя. Потому как нет наследования. Полочки — есть, а наследования — нет. Представьте себе эдакое Дельфи с формами, событиями, но без наследования… — Невозможно, ибо абсурд.
(26)
VBA?
Кстати, функции модуля менеждера это класс-методы, уж если на то пошло. Как можно вообще называть что-то «статическим» если «динамического» на горизонте даже не видать ???
(27) gaglo, Именно, и-мен-но ! Это скрипт. В том виде, в котором он есть в 7 и 8 — это скриптовый язык манипулирования данными. Он даже и компилируется-то не полностью. Какое уж тут наследование, в каше модулей бы не потонуть !
(29) Ну да, скрипт… Но: все-таки возможно. И даже не совсем абсурд?
Я даже согласен обозвать программирование на этом скрипте процедурным, а ни разу не объектно-ориентированным. Но ведь работает зараза?
Лично мне статья нравиться. Хорошо написана. В ООП есть много полезного, 1С этого явно не хватает
(30) gaglo, конечно, имея объект манипулирования скрипт не бесполезен. Но вот пустая объектная Дельфа без наследования — абсурд однозначный.
Наследование самое важное что нужно для ООП в 1с. Зачем что то еще не знаю…но наследование документов различных и т.д. сократит код в разы и будет проще работать. А так лучше оставить все как есть, а если хотите программировать ООП, то программисты C# C++ и т.д. тоже требуются)
А на тему наследования…
Все объекты «Документ.*» наследуют свойства и методы (типа .Записать() и т.п.) объекта дерева конфигурации «Документы». Чем не наследование?!
(31) WKBAPKA, да никто не спорит, что не хватает. Конечно лучше быть богатым и здоровым. Но повода считать таковой 1С-овскую модель никакого нет, имхо. Есть определённая схожесть некоторых черт и не более. Дерево метаданных оно, а не объектная модель. Возможно, когда-нибудь, в 9 версии… 😉
(34) Stamper, ага, а констркуции вида Выборка.Следующий отнесём к механизму RTTI ;)) Не смешно ?
(2) a-novoselov, Чем проще, тем лучше, согласен на все 100! Кстати, я считаю, что компьютер для бухгалтера — излишество, которое ведет к беспрерывной игре в косынку и питью чаев. Ручка, бумага и калькулятор. И можно садить в бухгалтерию любого человека. Любой разберется. 😉
(21) gaglo, Товарищи! Так, «сектантов ООП» уже посрамили давно и окончательно:
(26), (28) sergathome, Без наследования тоскливо и «костыли» не помогают. Жаль, конечно. А по поводу «статических», так это просто по-аналогии с «взрослыми» языками по способу использования. Понятно, что фактически это фикция, так как нет раннего и позднего связывания, как такового.
(36) sergathome, не вижу связи между типизацией переменных и выборкой результатов из строго-типизированного хранилища данных (а именно из базы данных).
так а собственно по существу (34) — почему добавление документа (и следовательно отсутствием необходимости реализовывать стандартные методы, добавления Номера, Даты и т.п.) нельзя считать наследованием от Документов?!
википедия категорически подтверждает моё предложение 🙂
(36) sergathome,
(37)
А куркулятор-то зачем?
Не вдаваясь в очередной холивар «Нужно ли в 1С ООП?», заметил, что публикация изобилует ошибками (например, «Никаких описание(?) классов», «модэль», «весь код зачастую помещалась(?) в модуль формы.») — лично мне читать неприятно.
Неужели трудно вычитать текст перед публикацией? Даже если не пользуемся Мозиллой со встроенной проверкой орфографии — неужели тяжело сначала набрать текст хотя бы в Ворде, а потом перенести сюда? И как оценивать высоту полета мысли автора, который не уважает своих читателей?
(41) rus128, дык холивар о другом: есть ли там ООП, или нет его
Многие «1Сники» просто не знакомы с другими языками и естественно с ООП.
(40) Арчибальд, Да. Действительно! =)
(38) Stamper, повторяю для танкистов — считать можно, толку от этого нет никакого, поскольку подменить стандартный метод нельзя НИКАК. Также абсолютно бесполезно представление объектной модели таблицы как потомка некоей абстрактной сущности, поскольку контекст полностью управляет поведением кода.
(42) fromon, и как это влияет на обсуждаемый вопрос? тролей не кормим
(45) sergathome, ну зачем же оскорблять!? не надо этого делать.
>>»поскольку подменить стандартный метод нельзя НИКАК»
быстренько открой литературу и найди N отличий между наследованием и переопределением методов. это во-первых.
а во-вторых, заставить бы тебя реализовать все методы ДокументОбъект-а (коих в 1С 8.2.15.301 насчитал 20), в УПП (где документов хорошо за сотню) за твой счёт — ты бы иначе заговорил.
(47) Stamper, Формально вы правы. Наследование и полиморфизм (а так же инкапсуляция, раз уж начали) между собой слабо связаны как таковые. Но фактически не зря эти три понятия все вместе называют тремя китами ООП. Так как только втроем они позволяют достичь максимального эффекта. А то, что есть в 1С, очень ограничено. Да, наследование есть. Но наследуется только «базовый класс Документ» (Справочник, Регистр, etc.) и все. Язык не поворачивается настолько ограниченное наследование называть наследованием. Извините за возможно лишнее упоминание, но . С полиморфизмом все плохо, ну а с инкапсуляцией (те самые «полочки», которых как уже было тут сказано, хватает) все более или менее хорошо.
Получаем в итоге, у нашего ООП один кит больной, другого нет, а третий вообщем-то нормальный, но выглядит странно.
(47) Stamper, зря обиделся. Извини, если что. Что касаемо теоретических воззрений на само ООП, то переопределение методов неотделимо от наследования. 😉 Потому как первым был скелет и имя ему Абстрактный.
Впрочем это беллетристика. А вот обращение вида Метаданные.Документы прямо указывает — это дерево метаданных и ничто иное. Иначе придётся придумывать РТТИ, что маразм.
Надо заметить, что все обсуждение касается только наследования, полиморфизм и инкапсуляция сомнениям не подвергаются. Выскажу свое мнение. А именно, должен ли быть прикладной язык совсем уж объектно-ориентированным, т.е. с генеалогическими (евгеническими?) возможностями?
Я в этом сильно сомневаюсь. В процессе формирования прикладного языка должна быть исследована предметная область (реальные объекты), проведена классификация обнаруженных объектов и, далее, классификация свойств объектов (однозначно присущие, либо возможные/опциональные. При этом в какой-то разумный момент необходимо остановиться. Если исследование (анализ) предметной области проведено надлежащим образом, а затем грамотно построены соответсвующие объекты (классы) платформы (синтезирован адекватный платформенный образ предметной области), то прикладнику не потребуется наследование.
Другой вопрос, насколько платформа 1С адекватна предметной области. Например, Время Документа — это один момент, или таки несколько (ВремяСоздания, ВремяХозоперации, ВремяПроведения…)
(48) zfilin, ну почему же плохо с полиморфизмом? есть же возможность указать Procedure Foo(parameter=0);
т.е. возможность есть 😉
ну а красота… кто-то упорно пишет на C++ а кто-то переходит на Ruby или развивает C++0x
(49) sergathome, на обиженных балконы падают 😉 я же призываю вести себя тактично
«переопределение методов неотделимо от наследования» — ИМХО, вопрос религии.
я себе могу представить, что творилось бы в конфигурациях, если бы каждый франч мог переопределить .Записать()
(51) Stamper,
Это ответ на вопрос, что будет, если 1С разродится истинной ООП-платформой. Не станет ли народу нечего делать. Не станет. ;)))
(40) Ну хоть счЁты-то?? (жалобно так)
(50) Арчибальд,
а это о чем!? у документа есть Дата (которая включает в себя время). так эта дата — таки дата (ну и время тоже) отражения хоз. операции
дата создания и проведения сохранится в журнале регистрации
не путаем «дата документа» и «период» периодических регистров сведений и регистров накопления
я бы сказал, что максимально адекватна из всех мне известных
(52) sergathome, яркий тому пример Википедия 🙂
(56) KulSer, Хех. Для ответа на вопрос «где разместить элементы на форме» нужно еще сильнее отвязывать объект от представления.
В таком случае, стандартные объекты где-то имеют обработчик: ИспользоватьФорму(«СтандартнаяФорма»), а в вашем унаследованном объекте этот обработчик будет переопределен на: ИспользоватьФорму(«МояФорма»). Но рисовать (или копировать) все-равно придется обе формы, визуальные компоненты принципам ООП не подчиняются. Конечно, если мы не говорим об управляемом интерфейсе, который пытается что-то сделать в этом направлении.
(54) Stamper, мне непонятно
А 1С при проведении просит указать, с каким временем прводить документ. Т.е. у документа время как минимум, не единственное.
Регистры сведений и регистры накопления здесь совершенно ни при чем. Может, у меня в конфе их вообще нет.
Да, я согласен, что модель 1С наиболее адекватна из существующих. Только вот адекватна чему? Хотелось бы адекватности (в частности) настоящему учету. Реально же мы видим адекватность документообороту.
(66) Арчибальд, документ без заполненного реквизита «Дата» (который по сути отражает, сколько секунд прошло с 01.01.0001, т.е. он включает в себя время тоже) не запишется, не то, что не проведется.
это единственное время документа. в проводки можно писать какое угодно время, хоть ТекущаяДата(), если это соответствует бизнес-логике. равно как Вы можете добавить какую-то свою дату (типа ДатаОтгрузки), которая может отличаться от даты документа и по отдельным разделам учета делать движения с соответствующими датами. повторюсь: всё зависит от бизнес-логики, т.е. от того, как реализовано в конфигурации. а у документа Дата — это один реквизит, который фактически является обязательным полем в базе данных. как его использовать — дело разработчика.
Адекватность учету — это вопрос уже конфигурации.
(69) Stamper, может, я непонятно объясняю… Речь шла о модели предметной области (учет). 1С считает, что у Документа (модели хозяйственной операции, отражаемой в учете) есть один атрибут Время (неважно, что оно в составе даты). Однако по действующему законодательству, моменты совершения хозяйственной операции и составления документа могут различаться. Т.е. в реальности у каждого документа времени, как минимум, два, и эти два времени неотъемлемы от реальности.
(71) Арчибальд, Ага! В этом случае получается, что доменная (предметная) модель платформы отстает от действующего законодательства. А завтра поменяется законодательство и даты станет ТРИ. И, что? Менять платформу? А некоторым документам, как сущностям, но не как сущностям отражающим хоз.деятельность предприятия (ну, например, «Служебная записка») одной даты вполне достаточно. Или вообще без даты. Те же «Договора контрагентов» в типовых вовсе не документы, а очень даже элементы справочника.
Вот поэтому я и утверждаю, что не худшее решение привести платформу к чем-то более фундаментальному, вроде ООП, а доменную модель реализовывать средствами конфигурации от потребностей непосредственно предметной области.
(71) Арчибальд, если я ничего не путаю, то подтверждением хозяйственной операции в бух. учете является первичный документ, дата которого является обязательными реквизитом для заполнения.
время нас интересует для оперативного учета, который не регламентирован.
а уж сколько реквизитов «Дата» добавить разработчику — это его дело.
в типовой РеализацияТоваровИУслуг их штуки 3, кажется.
(7) s.sintsov, согласен. Документация нужна для всего нужна обязательно, и для таких обработок в частности. Бывает, что самому проще написать, чем искать чужое, а потом еще и разбираться.
(74)
Дата, а не время.
Про оперативный учет я вообще не говорил, ибо не знаю, что это такое. Но точно знаю, что бухгалтерский учет является оперативным. Таким образом, время нас интересует именно в бухгалтерском учете.
Далее, Хозяйственная операция (реальная) имеет некоторую протяженность во времени. Начало совершения операции может иметь дату, отличающуюся от даты завершения операции. Скажем, выпуск продукции ночной сменой. Вполне очевидно, что он будет зафиксирован (сделает движения регистров) завтра утром. А сегодня вечером часть продукции уже отгружена. Что нам об этой ситуации говорит время (даже дата) проведения документа? Проводить отгрузку завтрашним числом? Сегодняшним не получится: продукции на складе сегодня еще не наблюдается.
И дело здесь не в конфигурации, а в модели учета 1С.
(83) Арчибальд,
трудно вести дискуссию в таком ключе 🙂
а я, например, точно знаю что нет. хотя бы потому, что не все операции, отображаемые в оперативном учете отражаются в бухгалтерском.
в ПСБУ Украины я нигде упоминание времени в связи с первичными документами не встречал.
то, что Вы описали («разорванная» отгрузка товаров), реализована в Акселот Логистика: Управление складом, например (не сочтите за рекламу). это конфигурация для 1С.
повторюсь: Вы сейчас поднимаете проблемы реализации конфигурации, которые механизмами платформы вполне удаётся запрограммировать.
(84)
Почему трудно? Я сказал: не знаю, что такое ОУ. Не встречал нигде определения. Если Вы встечали — поделитесь. А то обстоятельство, что бухучет обязан быть «оперативным» в смысле не «посмертным» определено законодательно. В я это разбирал. А фирма 1С длительное время игнорировала это обстоятельство: например, в семерочной Комплексной бухучет был заложен как «среднеежемесячный». Т.е. при анализе предметной области (я о бухучете говорю) не было учтено одно из ключевых обстоятельств — отсюда и неадекватность. И не в конкретной конфигурации дело, а в поверхностном понимании сути учетных документов.
(86) Арчибальд, когда человек пишет «не знаю, что это такое, но точно знаю что это…» (когда речь об одном и том же) становится смешно 🙂
Бухгалтерский учет — регламентирован ПСБУ (правила, стандарты бухгалтерского учета)
Управленческий учет — каждый хоз. субъект выбирает для себя сам его правила
кстати, я из Украины. но у нас эти моменты практически одинаковые.
так же определено законодательно, что источником информации об отражении хоз. операции является первичный документ. а если товар вынесли со склада без Расходной накладной? по бух. учету отражать расход (без акта инвентаризации) мы не можем, а по оперативному учету — товара у нас фактически меньше.
1С 7.7 была выпущена в 1997 году, если я не путаю. 15 лет назад!!!!
а мы тут обсуждаем 8.2, спешу напомнить
(87)
В 1999 г.
(87)
Еще раз произнесу те же слова. Я не знаю, что такое оперативный учет. Но точно знаю, что бухучет должен быть оперативным. Где здесь одно и то же? Бухгалтерский учет и оперативный учет — одно и то же? Да, бухгалтерскому учету присуща оперативность. А что такое учет оперативный?
Насколько я понимаю, Вы уж точно не знаете, что такое оперативный учет, раз в ответе мне говорите про управленческий.
(103) Арчибальд, википедия нас рассудит
(105) Ну, не то чтобы рассудил…
Метод оперативного учёта состоит в непосредственном наблюдении хозяйственных операций, причём также и тех, которые невозможно непосредственно отразить в бухгалтерском учёте ― таких, как: явка работников, нагрузка на производственные мощности, простои, режим технологического процесса, характер брака. Специфика этого метода объясняет тот факт, что в оперативно-техническом учёте чаще всего применяются натуральные и трудовые измерители.
Если Вы говорили об этом учете, то вообще непонятно, зачем его приплели в разговор о Документах 1С, да и об 1С вообще. Объектная модель 1С вообще не предполагает непосредственного наблюдения операций — именно об этом я говорил, рассуждая о протяженности хоз операций во времени в противовес наличию у Документа точечного местоположения на шкале времени. Особенно мне понравилась явка работников применительно к 1С.
(106) Арчибальд,
это выдержка из синтакс-помощника конфигуратора
черт знает сколько лет в конфигурациях реализовано раздельное поведение при оперативном и неоперативном проведении документов
откройте хоть раз конфигуратор перед вступлением в спор
(107) Stamper, кстати о птичках — модель оперативный/неоперативный крива также, как метод (!) МоментВремени(). И растут они из одного места — объять необъятное. ? 😉
(112) sergathome,
обоснования?
(114) Stamper, обоснование просто как пробка — если делается система с «машиной времени», то есть запоминается всё и вся и есть возможность любого отката, то нефига пенять на дохлое быстродействие. А если нет, то будь честным. 1С 8 не является ни тем, ни другим. Факт. Один МоментВремени() с Границей чего стоят. Вы, таки разобралися с механизмом сего чуда ? 😉
(116) sergathome, лично у меня складывается чувство, что вы ни разу не внедряли 1С на действующем предприятии
«оперативный/неоперативный учет» нужен для разделения поведения программы в случае отражения операций минута в и минуту и в случае проведения задним числом
(118) Stamper, у меня есть уверенность. !. Вы имеете отношение к разработчикам платформы и …не обслуживали ваше произведение. Или не видели альтернатив. 😉
Не обижайтесь.
Ваш «отдел продаж» выполнил свою функцию гораздо лучше отдела разработки. Увы.
(119) sergathome, к сожалению, я не разработчик платформы.
у меня была возможность сравнить скорость разработки сравнимого функционала одним мной (за две ночи, в рамках выполнения тестовой задачи при приёме на работу) и группой из 20 .net разработчиков (которые расценили выполнение в 2..4 недели). этим и объясняется моя приверженность
(120) Арчибальд, : один из обязательных реквизитов «Дата составления документа»
а каким документом руководствуетесь вы?
(34) Stamper,
зато полезно тем кто пишет типовые… за такой быдлокод я бы их поубивал…
а про запросы я вообще молчу
(20) JohnyDeath,
нет там настоящего наследования, а только иммитация куцыми средствами 1с копирования и исполнения процедур объектов (но не для форм — для форм не получилось), и простое юзание несчастного IDispatch. Может, максимально приблизятся в разработке chessman (при поддержке artbear):
(25) gaglo,
(27) gaglo,
«…Дельфи с формами, событиями, но без наследования… — Невозможно, ибо абсурд.»
VBA?
А чем вам VBA не понравился? Тем, что явно не можете классы создать? Так продукты, которые он обслуживает (причем работает не чета 1с-у — в 2010 Екселе, например, когда через формат файла сняли ограничение на количество строк на листе, макрос заполняет 1 мол (1 000 000 000) строк произвольным значением за 20 минут), можно обработать и другими языками с наследованием и классами — тем же Дельфи.
Потпробуйте для конфы 1с что-нить написать на Дельфи ))
1с-у такая производительность не снилась.
(33) YakshinAnd,
где требуются?? и кому? Дельфи умерло почти, а сишники нужны только на драйверах — прикладные программы (где и нужны в основном классы и наследование) никому не сдались — уровень падает, как заказчиков и их задач, так вслед этому и программистов.
Или вы на С++ для 1с писать будете? интересно взглянуть ))
(159) AlexO,
1с-у такая производительность не снилась.
Будет полностью нарушен основной принцип 1С — открытость конфигурации.
Подобные разработки есть, и были в 7-ке. Подключаются через СОМ-объекты. Например драйвера кассовых аппаратов. Подключайте чего угодно… и используйте.
(161) AlexO,
А на чем, по Вашему, написана платформа?
(159) Уважаемый — Вы (кажется) не вчитались в тексты, ну это и понятно, дискуссия-то вон как разрослась…
Мне VBA вполне нравится; слово «абсурд» не моё, а цитированное; и уж если на то пошло, «1 мол строк за 20 минут» не впечатляет меня как невиданное быстродействие; и ещё рассказы про «1с-у такая производительность не снилась»… Опять лозунги и заклинания, а конкретика только на уровне (162). См. также цепочку (19)-(25)-(56)-(59) — KulSer попытался (полу)конкретно доказать преимущество наследования в кнкретном случае, но зажевал неудобный вопрос с наследованием формы, на что тут же zfilin и указал. А сравнив рецепт от KulSer с , где концентрированно изложены действия для достижения практически той же цели без наследования, вижу я, что… то есть не вижу я никакого решающего преимущества одного способа над другим.
Вот только один способ — воображаемый, а другой реальный.
(Ну это уже мои комплексы ;-])
(163) alex_shkut,
Открытость?? вы долго на 1с пишете? ))
Драйвера и для 8-ки есть. Ну давайте на драйверах напишите конфу. Посмотрим…
И речь никак не про 7-ку — 7-ка это была «надежда» истинного ОПП (ну вот доработают, ну вот учтут все пожелания…)
а вы платформу к 1с совершенствуете? мое вам уважение ))
(166) gaglo,
вы точно на 1с работаете? ))
(22) Stamper, дерево конфы — это всего лишь кучка ini-файлов, собранных в одну кучку. напоминает реестр виндовса
(223) tango, если посмотреть, например, в таблицы SQL — то выглядит всё иначе
(226) Stamper,
и что вы увидели в таблицах SQL кроме ссылок?
(227) AlexO:
в таблице Config лежит код модулей и идентификаторы таблиц всех объектов
(228) Stamper,
И где тут ООП?
(229) AlexO, ну так дело же не в форме абстракции, а в её содержании
(230) Stamper,
так давайте найдем там ООП… я его пока не вижу 🙂
(231) AlexO, сертификат 1С:Специалист по Платформе 8 есть?
(232) Stamper,
а что — сертификат 1с автоматически вносит в 1с ООП? не знал.
Знал бы раньше — когда познакомился со всеми этими профессионалами-специалистами, продолжил бы сдавать. А так — не собираюсь тратить на эту ерунду время.
Вы молодой, у вас его много — пожалуйста. Сдавайте, пересдавайте, хвалитесь друг перед другом этими мусорными бумажками, меряйтесь длиной сертификатов….
А я лучше в лес схожу, на птичек посмотрю.
(232) Stamper,
хотя не так.
А вот так:
— А вы думать умеете? Проектировать? сам, а не как 1с сказала и показала?
(235) AlexO, извините, не думал, что это Вас так заденет.
просто как и повсюду, сертификация позволяет отсеять «случайных» людей.
как Вам не хочется «тратить на эту ерунду время», так и мне не хочется тратить время на споры со случайными людьми.
(2) a-novoselov, насчет дешевизны вы, уважаемый, пальцем в небо попали!
Это еще с 1С-Бухгалтерии 6.0 пропагандируется, что 1С любой «лох» конфигурять может.
вот только это на самом деле не совсем так стало со временем —
тут количество перерасло в качество — все же есть така профессия «Программист 1С».
но подход остался прежним — делаем типовухи дешево и сердито силами разных биологов и гуманитариев!
С некоторых пор, похоже, этот принцып и на платформу распространили
(багтрекер платформы раздулся что-то непомерно).
Пора наверно смежные области присматривать …
(2) a-novoselov, понимаете ли в 1совском подобии Бейсика нет не то, что ООП а многих других элементарных вещей присущих языкам программирования, которые спасают от очень многих ошибок, которые кстати трудно выловить. Что же касается самого ООП то его отсутствие приводит как раз к низкому качеству кода, его избыточности делающей как раз понимание того что уже написано сложным. Для двухнедельных само обручающихся программеров изучение ООП кончно кажется сложным и непонятным. Посмотришь на код таких вундеркиндов и сразу приходит на ум фраза: Не стреляйте в пианиста,- он играет как умеет.
(240)
Да это не только в 1С. Посмотрите на толпы ПХП-быдлокодеров, даже на С++ куча библиотек индусским кодом написана. Дешевая рабочая сила есть везде, и работают на «лишь бы лишь бы». Я просто считаю, что 1С в этом обвинять не стоит. И многие таланты без образования и знания английского поднялись на 1С и стали супер-спецами, раскрыли себя, так сказать, благодаря доступности и распространенности. Мне кажется не стоит за простоту 1С судить, и за индусов, так как они раньше 1С-ки появились и всегда будут :).
(241)
Нет ООП? Да ладно…
Это ли не ООП? Какой избыточный код? Сколько кода нужно напечатать в том же С++, чтобы было настолько простое и лаконичное отражение хозяйственной операции «продажа»? Дюбой кодер понимает, что двумя строчками перезаписываются все движения этого документа. Где тут избыточность? Мне кажется язык 1С для своих целей очень даже хорошо подходит.