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

чего сказать-то хотел?

(0) Дало бы больше ошибок и более сложное сопровождение

(0) программисты перестанут плакать, что в 1С нет ООП, это будет главное достижение

(3) Браво. Присоединяюсь.

Да-да, я тоже хочу знать - что бы дало.
Хотелось бы на примере БП 8.0, если можно. Хотя бы коротенький пример, без кода - в общих словах

(5) А для меня, если можно, с примером (небольшим, классов на 20-30).

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

(7) Это в каких же основах Вы ООП увидили? :-)

(1) пример.
У меня есть объект Эстиматор, который показывает прогресс выполнения задачи.
Значитца так.
Код примерно такой (для перебора ТЗ):
Эстиматор=Эстиматор_Создать();

Эстиматор.Размер=Т.Количество();
//Идет какой то цикл
Для Каждого Стр из ТЗ Цикл
Эстиматор_Событие(Эстиматор, 1);
КонецЦикла;

На ооп:

Эстиматор=Эстиматор_Создать();

Эстиматор.Размер=Т.Количество();
//Идет какой то цикл
Для Каждого Стр из ТЗ Цикл
Эстиматор.Событие(1);
КонецЦикла;

Как минимум короче названия процедур.

(8) моя мысль была, что для создания 1С использовалась технологии объектно-ориентированного программирования.

Пардон:
не

Эстиматор=Эстиматор_Создать()

, а

Эстиматор=Новый Эстиматор();

(9) Ну можно же создать обработку Эстиматор, определить у неё в модуле процедуру "Событие" и переменную Размер - всё со словом Экспорт

и дальше получится всё с тем же синтаксисом.

Нет, обсуждать следует не агрегацию - она в 1С и так нормальная, а наследование

(11) Это не ООП, это создание экземпляра компоненты, типа как Excel.Application.

(9) И чё эт за галиматья ?

(0) ООП-это наследование,а при наследовании,зависимость от обновляемых конф,
уменьшилась бы

(13) ну и почему я не могу создать свой класс, ведь это бы упростило мне жизнь!

(16) Да в том-то и дело, что можешь. Обработка - и есть класс. (как в VB6)
Только наследования нет.
Ты давай рассказывай, как наследование помогло бы.

(15) ой ли? а ну как родительский класс поменяется, а? а у тебя от него "отнаследовано" полконфигурации?

(18)+ а то, что он поменяется - быть уверен. или я мало обновлял типовые? :)

(18) Согласен !
Поэтому хорошая сравнивалка изменений лучше плохого наследования.

(18) В этом и заключается прикол ООП, реализация изменяется, а интерфкейсы остаются.

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

(18) а для этого есть механизм манифестации,как в java

знаете, я вот сейчас подумал... немного не в тему, но все о том же.

вот MS придумала .NET, одной из целей которой было избавить программистов от "DLL HELL". и во что это превратилось? у меня сейчас на машине стоит 3(!) версии FrameWork'a. А все потому, что приложения, собранные под 1.1 в упор не видят 2.0.
Вооот...

+23 штоб не было "двоичного кошмара"

интерфейсы - это уже компонентня модель... так что, не трожьте интерфейсы..

(26) Шо ?!!

(21) или я мало обновлял типовые?

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

(24) MS спеликанила .Net у 2jee,когда Sun дала по рукам MS из-за резких намерений той потащить одеяло на себя,помните как резко кончилась любовь MS к java?

(27) COM, COM+

(28) Я немало обновлял НЕ типовые, и скажу честно ООП не хватает..

(29) Вот и я про то же. Общий модуль можно было бы заделать как класс.

об=СоздатьОбъект("ОбщийМодуль.Имя");
об.ИмяПеременной=3;
об.ИмяФункции();

+30 спеликанила,а манифестацию не сделала,я восхищаюсь java beans в этом смысле!

(31) У многого есть интерфейсы и у классов тоже..

(33) Если можно было наследовать объекты конфы и создавать свои классы потребность в общих модулях бы отпала.

(33) и плюс .txt файлец с изменениями в конфе по сравнению с предыдущим релизом :)

(+36) C# - тому ярчайший пример, ни строки за телом класса.

(36) да. только весь вопрос в том, кто поддерживает FrameWork. а вот теперь представь, что у тебя в новом релизе изменяется половина FrameWork'а. Без объяснения причин. И задокументировано это все ну как общие модули в типовых.

(38) тоже пример хорошей идеи и "как-всегда" реализации. в (24) пояснения

(40) Ну не сразу всё было гладко и красиво. Новый стандарт С++ вышел в 2003 году, что поделаешь, а то что фирма 1С на приколы неслаба это всем известно.

(36) Классы аккуратно создавать каждый в отдельном модуле. Подойди с другой стороны - что отличает класс и общий модуль? Если подумать, то ничего - просто заголовочка "Класс" нет.

Конечно сейчас он не работает как класс, но в будущем (если прикрутить такую реализацию) имхо вполне бы мог.

Ну всё же, объясните мне как это выглядело бы.

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

Как бы это могло выглядеть... синтаксически, или как-нибудь визуально в конструкторе... я просто не представляю ? И укладываются ли классы в концепцию метаданных (которые не просто представление структуры данных, а ещё и объектов, связанных с ними)

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

(+42) Добавилось бы только одно ключевое слово: СоздатьОбъект (впрочем, оно уже в движке есть). А термины "Класс", "Поле", "Метод" имхо обескураживают новичков, тогда как речь идет о простейших и всем знакомых вещах.

(43) При объединении ставишь галку в конфигураторе "Объединять объекты".

(44) Гений, ты я вижу любитель сам с собой поговорить...
(43) Наследуешь документ ПриходнаяНакладная.... Визуально будет новый док рядом, только имеет список базовых (смотри class manager в VS.Net).

(44) ну создай обработку "Время" и наслаждайся.
В качестве примера посмотри БухгалтерскиеИтоги

(46) объяснил - охренеть! можна сказать - глаза открыл. я прямо сразу все понял. А вы?

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

(47) Очень хорошо. Мы создали новый док ПриходнаяНакладнаяНаш, где-то в свойствах у него записано, что родитель - ПриходнаяНакладная

Теперь - если я открою журнал приходных накладных, что я увижу - "ПриходнаяНакладнаяНаш" или "ПриходнаяНакладная" ?

А если была некая обработка, которая создавала приходные накладные автоматом и где был код Документы.ПриходнаяНакладная.Создать() - какой документ она создаст - "ПриходнаяНакладная" ? И зачем ?

(35) для ООП ключевыми понятиями являются: "Инкапсуляци, полиморфизм, наследование". Все... здесь никаких интерфейсов нет.. а то, таким макаром и у модулей есть Interface, Implementation

(48) лучше бы уж справочник порекомендовал - это было бы ближе к теме... :)

(50) а сейчас ты умеешь хранить в БД например ТаблицуЗначений?

(53) ты прав, я не въехал в твой пример :)

(54) только тупой вариант с хранилищем...

т.е. основное что я не понимаю: если уже есть типовая. И наследование будто бы возможно.  Какое толк наследоваться от объекта в типовой, если во всех местах ссылки на старый, базовый объект ?

Задрали уже воду в ступе толочь...

(57) Так и будет старый объект. А какой толк добавлять реквизит в документ, если в старых его не будет? Вот именно система добавляет функциональности обрастая со временем, а не видоизменяясь.

(57) Есть автозамена типа Объект типа Документ.ПриходнаяНакладная считается объектом типа Документ.ПриходнаяНакладнаяВасиПупкина или Документ.ПриходнаяНакладнаяВаниГалкина. Если наследников много нужно назначить приоритеты автозамены типа.

(60) Или же создается новый наследник на основе двух наследников. Типа того

(59) недопонял, ну и ладно.
Я придумал даже ещё более жизненный пример.

Положим, мне надо изменить модуль проведения - добавить субконто в проводку.
Я наследую ПриходнаяНакладнаяНаш от ПриходнаяНакладная.
и ПЕРЕГРУЖАЮ метод ОбработкаПроведения()    (такая терминология в ООП, да ?)

таким образом если 1С изменит ОбработкаПроведения(), то на моём коде это не скажется ? (вроде бы хорошо) Но ведь и все те полезности и вкусности, которые 1С сделала, я тоже потеряю ?

(60),(61) мне кажется что в проблемы множественного наследования нам сейчас лезть не надо

(62)
Процедура ОбработкаПроведения()
   ....  Что натворил
   ДокБазовый:ОбработкаПроведения(); - Вызываем метод базового
КонецПроцедуры

(64) ну это всё замечательно, но не сработает, если мне надо добавить всего лишь пару строк в процедура на пару тысяч строк, с отработкой кучи вариантов (а мне надо только в каком-то одном, конкретном, да ещё и внутри второго вложенного цикла)

(62) У 1С будет виртуальный метод добавитьпроводку, который можно перехерачить и вставить свой код туда

(66) О, удача :) У 1С уже есть такой метод, он находится в модуле регистра бухгалтерии - процедура ПриЗаписи. Действительно помогает иногда. Но ООП тут ни при чём :)

(0) Когда я думаю о ООП у меня вырисовывается не структура наследования, а структура замены (или каскадного включения) методов... пока что

(65) А это уже, извините, недопонимание принципов и идеологии ООП. Дан тебе класс - ручки в него не суй, он делает то что делает, ты либо оставь, либо дополни.

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

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

(68) ты знаешь - у меня то же самое вертится.

Что-то вроде каскадного вызова общих процедур от частных ко всё более общим и абстрактным. Причём общие модули группируют процедуры по степени абстрактности.
Тогда самые абстрактные модули мы называем ядром (или "слоем" - по терминологии навижн) и запрещаем трогать.

(70) ты прав, я часто так делаю. Всё это уже есть в восьмёрке.

(69) ты тоже прав.
Я просто пытаюсь показать неудобство наследования для настройки типовых методом "точечных уколов"

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

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

(это по поводу якобы не нужности знания начинки типовых)

(74) 1) Почему же? для сохранения преемственности, базовую структуру классов (возможно стоять на поддержке из них будут не все) выполняет естессно разработчик типовой - а все изменения - через наследование.
2) Также как и структуру метаданных. Они будут доступны для редактирования но безопасны в смысле ООП - реквизиты будут иметь признак (private, public, protected)..
А начинку не надо знать, тока интерфейсы - доступные реквизиты (public, protected) и функции export, хотя лучше функции тож объявлять private, public, protected

ле, угомонитесь все...
ветка предназначена ВОЖДЮ!!!!

Вождь почивает уже

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

Привожу пример.
Пусть документ приходная накладная делает проводки
60-41.
Причем код примерно такой:

Процедура ДвиженияПоБУ()
  Проводки=Движения.Хозрасчетный();
...
  Проводки.Добавить();  
...
КонецПроцедуры

Так вот, если бы я имел возможность каскадно включить свой триггер примерно по такой схеме:

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

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

(78) Хочешь дам исходник DLL перехвата модуля 7.7 (перед компиляцией)?

(80) мне нужно немного другое. Если почитать (78) то становится понятно, что нужно не только перехват метода, но и знать состояние стека. Это уже не ООП, а голубая мечта!

(80) к тому же это run-тайм

Fixin, где ты такую траву забористую берешь? Ведь просто душа поет от того, какие спец.эффекты в твоем мозге сей продукт неизвестного земледельца вытворяет.

(83) Боюсь, что это не трава, а тяжелая химия...

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

Учитесь у старших братьев, тупые адынесники
http://www.axforum.info/forums/showthread.php?t=11876

Эээх. Стыдно мне, что я одинесник.

(86) Читал и плакал. Я горжусь тем, что я 1С-ник.

(84)А может просто систематическая недостача женского общества?(судя по дневнику)

(86) А чему там учиться? Надо туда фиксина направить, вот тогда там станет весело :) А пока там тихий и пристойный разговор вежливых джентльменов.
(89) Чтобы его выдержать, нужно такую-же траву употреблять. Не всякой женщине такое по силам.

(90) Хочется уточнить: не всякой живой женщине...

(90) (91) Выносливость женщин безгранична. Особенно из жалости. Но вы отвлеклись.
Саммари:
Гений 1С В этой ветке я буду дискутировать с Вождем и прочими, что дало бы ООП, будь оно внедрено в 1С. :) Дабы не загрязнять другие ветки.
Итак, ваш ход, оппоненты.
Vozhd если можно, с примером (небольшим, классов на 20-30).
Гений 1С пример.
У меня есть объект Эстиматор, который показывает прогресс выполнения задачи.
Значитца так.
Код примерно такой (для перебора ТЗ):
Эстиматор=Эстиматор_Создать();

Эстиматор.Размер=Т.Количество();
//Идет какой то цикл
Для Каждого Стр из ТЗ Цикл
Эстиматор_Событие(Эстиматор, 1);
КонецЦикла;

На ооп:

Эстиматор=Эстиматор_Создать();

Эстиматор.Размер=Т.Количество();
//Идет какой то цикл
Для Каждого Стр из ТЗ Цикл
Эстиматор.Событие(1);
КонецЦикла;

Как минимум короче названия процедур.

Vozhd Это не ООП, это создание экземпляра компоненты, типа как Excel.Application.
Гений 1С ну и почему я не могу создать свой класс, ведь это бы упростило мне жизнь!
Гений 1С Кроме хранимых прикладных объектов есть еще и алгоритмические, которые выполняют различные алгоритмы. Вот здесь бы ООП ой как пригодилась бы.
Например я бы создал класс Время и хранил в нем время в виде 4 символов. :)
С проверкой валидности и т.п.
Гений 1С Есть автозамена типа Объект типа Документ.ПриходнаяНакладная считается объектом типа Документ.ПриходнаяНакладнаяВасиПупкина или Документ.ПриходнаяНакладнаяВаниГалкина. Если наследников много нужно назначить приоритеты автозамены типа.
Гений 1С Или же создается новый наследник на основе двух наследников. Типа того
Гений 1С У 1С будет виртуальный метод добавитьпроводку, который можно перехерачить и вставить свой код туда
Гений 1С Когда я думаю о ООП у меня вырисовывается не структура наследования, а структура замены (или каскадного включения) методов... пока что
Гений 1С Да. если бы я имел извещение от объекта Наборзаписейхозрасчетный о том, из какого контекста добавляется проводка, я бы тут же перехерачил счета и прочие реквизиты проводок.
Гений 1С Как вам такая концепция - да простят меня адепты ООП.
Итак, мы имеем возможность навесить свою процедуру-триггер на любой вызов метода.

Привожу пример.
Пусть документ приходная накладная делает проводки
60-41.
Причем код примерно такой:

Процедура ДвиженияПоБУ()
  Проводки=Движения.Хозрасчетный();
...
  Проводки.Добавить();  
...
КонецПроцедуры

Так вот, если бы я имел возможность каскадно включить свой триггер примерно по такой схеме:

Включить мой триггер на метод Добавить движение в набор записей Хозрасчетный, вызываемый из процедуры ДвиженияПоБУ модуля документа ПоступлениеТоваровИУслуг, это бы мне с лихвой заменило отсутсвие ООП.
Соответственно, методы нужно было бы делать как можно меньше, чтобы можно было зацепить триггер на любой из них.
Такое триггерное программирование.
Гений 1С Ну и соответственно добавление новых методов и чтобы все свойства были как пропертиз - т.е. были функции их чтения/установки, то бишь такое нехилое использование всех свойств ООП, кроме наследования.
Гений 1С мне нужно немного другое. Если почитать (78) то становится понятно, что нужно не только перехват метода, но и знать состояние стека. Это уже не ООП, а голубая мечта!
Гений 1С к тому же это run-тайм

(92) А к чему Вы перехерачили столько текста в один мессадж? Чтобы завтра было проще освежать в памяти предыдущий бред? или я не понимая глубины замысла?

(93) Для демонстрации Гениальной попытки выполнить просьбу Вождя о маленьком примерчике в 20 классов.
И потом, я же не руками это отбирал. А вся глубина обоснованости необходимости ООП как на ладони. Особенно если добавить
Херрес О, удача :) У 1С уже есть такой метод, он находится в модуле регистра бухгалтерии - процедура ПриЗаписи. Действительно помогает иногда. Но ООП тут ни при чём :)

(94) Радуйтесь, что Гений не знает про сигналы и слоты, про коннекшин поинты и прочие прелести. А то бы он и их начал клянчить у 1С...

(95) Это точно. Вот как-бы его на Аксфорум переправить ... Правда там mazzy долго на него смотреть не будет, пристрелит нафиг :))

(96) Не стоит возводить напраслину. Мазуркин до такого не опустится.

(97) Значит кого-нибудь попросит :)

Уже все поняли, что ООП в 1С не нужно. Только одна деталь.
Ахапта обновляется, v2-v2.5-v3-v4 и так до 2015.
А у 1С все не слава богу. Что у нас там ?
ТиС 8.7 не совместима с ТиС 9.0,
в7.7 несовместима с в8.0,
ТиС 9.0 с УТ10
это только на вскидку.
Праильно! Нахрен ООП в 1С. Лучше каждые 2 года конфы переписывать.

100

(99) Круто! Выводы из сравнения обновляймости с совместимостью...

(99) Судя по появлению ветки - не все :)) Только как связано ООП вообще, недоООП в Кацапте и несовместимость конфигураций в 1С? Что касается Аксапты, то посмотрим что будет, когда они все на Грине сделают. Правда Билли будет тянуть совместимость до упора, у него уже есть опыт :)

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

(103) Согласен 100%. К сожалению, большинство 1С-ников не понимает что есть такое ООП. Да, кто-то что-то читал. Но ведь читать и реально работать - это разные вещи. Имхо, ООП в v8 необходимо как воздух. Но думается мне, что его таки не будет. По чисто комерческим соображениям.
В одной из веток начали дискуссию по поводу наследования в плане объектов метаданных. Так вот, господа! Это как раз и не нужно. Только код. Пусть будут избыточные поля в таблицах, господь с ними.
ЗЫ: все споры от незнания предмета и (что в данном случае естественно) непонимания возможностей применения.

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

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

(106) Ты пробовал обновлять релиз УТ, когда в половине общих модулей и в половине модулей документов крепко изменен код? Через обработки это конечно хорошо. Но речь идет о типовых конфах.

Время коронной ссылки.
http://stupid1snik.narod.ru/
Правда я знаю, что сейчас скажут :
1) Что это не полностью соответствует идеалам ООП
2) Что это единичный пример
3) Что возникнет миллион проблем (и кстати не укажут ни одной)
полное де жа вю

(107) Я пробовал понять зачем в УТ менять половину общих модулей и половину модулей документов, да ещё потом всё это убожество обновлять. Не получилось.

(109) Специфика, знаете ли.

Даже когда есть необходимость менять модули - всегда изменения можно внести в начало или конец процедуры и сделать их контекстно независимыми от остального кода, после чего модули элементарно обновляются через CVS + Araxis.

(109) УТ дописывалась на бизнес-процессы это раз. 2. Контора в Беларуси. Копеек нет, только рубли. Печ. формы. 3. Права на доступ к реквизитам... ну и так, по мелочи

(110) И зачем специфику обновлять?

(113) Косишь под дурочка, или правда ?

Может резко сказал, но не собираюсь обсуждать необходимость обновления типовых и неоходимость их изменения.

(113) No comments

(112)
- УТ дописывалась на бизнес-процессы это раз.

И какие общие модули всвязи с этим надо было менять?

- 2. Контора в Беларуси. Копеек нет, только рубли.

И что?

- Печ. формы.

О системе дополнительных печатных форм не слышали?

- 3. Права на доступ к реквизитам... ну и так, по мелочи.

Для реализации прав на доступ к реквизитам не нужно менять существующие модули.
Какие модули менялись конкретно?

(114) Кошу под человека,задавшего простой вопрос полудурку в 110 и не получившего ответа. Привык, ничего страшного, не стоит извиняться.

Как разговаривать про ООП так пи-жа на мегабайты, как простые вопросы по существу - комментсов ноу. В чем собственно и сомнений быть не могло. Откудаэто в одинэсниках? Вопрос.Риторический = истина

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

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

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

(120) Исходный продукт к сожалению до сих пор имеет массу багов. Именно поэтому очень хочется обновлений.

(108) И снова здравствуйте :) В старой ветке ты так и не ответил по сути ...
(121) А зачем для поддержки бизнес-процессов много кода в документ втыкать (если функциональность правтически не менялась)? Такая доработка (для поддержки б/п) займет от 5-10 до 100 строк кода. На фоне документов типовых - совсем мало кода.

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

(124) Так с тобой никто это вкус уже и не обсуждает.

(122) Немножко не понял. Вам неизвестно какие именно баги в нем присутствуют или Вы знаете в чем ошибки, но не можете их самостоятельно устранить?

(126) Еще один под дурочка косит. Сравни УТ 10.1 и 10.2