Возник тут у нас с коллегами нехилый диспут на тему "почему в 1С нет наследования".

Это сложно с технической стороны реализации или не сделано по каким-то политическим причинам?

а должно быть??

по политическим

(1) Сложный вопрос, в тех системах, с которыми работал (Аксапта, Lexema) было.

(2) Ну вот мы в диспуте тоже к этому выводу пришли.

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

(4) Если рассматривать обработки, как классы, то: наследование включение реализовано; полиморфизм реализован - просто отсутствует типизация; Частично реализована инкапсуляция, т.к. не полностью реализовано наследование. Собственно 1С приближается к ООП, версии в 10 будет думаю полноценной.

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

(0) Настоящее наследование - это сложно. Даже в Java нет множественного наследования.

Почему в 1С не беременных? ;)

опять...

без наследования пишут что попало...

В 1С нет объектов пользователя!
Все объекты создаются системой на этапе её проектирования.
Некое подобие объектно-ориентированного подхода всё-таки есть - работа с объектами 1С и возможность получения конкретного объекта из класса.
Создали "Документ" сделали выборку, а при выборке получаем "Документ.Счет".
Есть также функция "УстановитьВид".
Нету наследования на этапе конфигурирования - но при наличии наследование фразу "конфигурирование" пришлось бы заменить на "программирование".

В 1С реализовано какое-то "техническое наследование" и "технический полиморфизм". В пофигураторе можно указать скажем документобъект или справочникобъект например в подписках. То есть система понимает объекты на уровне видов метаданных. А вот программный доступ только на уровне конкретных видов документов и справочников. А жаль.

при наличии наследования в 1С пришлось бы искать квалифицированный персонал (все методы "промышленного" программирования от 1С в ж.пе). А где же взять столько недятлов?

Появится наследование, будут спрашивать почему есть.

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

Зато не надо будет выносить процедуры в глобальный модуль.

(0) Напишите 1С++ для 8-ки ;-)

(0)Имхо наследование, полиморфизм и иже- вещи полезные, но помоему это сделано для большей совместимости. И так ВК развелось выше крыши, а если еще каждый прогер будет свои хедеры клепать, то вообще все в раздрай пойдет

(10) подобие объектов есть, но большинство всё же понимает их по другому:

класс=объект метаданных "обработка"
экземпляр класса - экземпляр обработки
публичные методы - процедуры и функции модуля обработки со словом Экспорт
приватные методы - процедуры и функции модуля обработки без слова Экспорт
публичные переменные - переменные модуля обработки или реквизиты
Конструктор класса - код, помещённый внизу модуля обработки

Классический пример такого объекта от 1С - бухгалтерские итоги

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

наследование есть, но только "одноуровневое" - от стандартных объектов типа "справочник", "документ" и т.д...

(19) однако в 8.2 появились модули узлов метаданных Документы и Справочники ))
правда кажись ничего полезного сделать там низя

(19) тогда можно сказать, что есть объекты и есть наследование.
(У документа могут быть общие реквизиты).
Но, так как объекты заданы, то заданы и пути наследования.

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

В восьмерке кстати типовые отчеты написаны так, что их наследовать элементарно.

Вообще 1С правильно всё сделали, ООП это отмирающая ветка развития отмирающего программирования.

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

(24)Делфист наверное?:)

(25) почему ? потому что слово "модули" ?
ну я не знаю как ещё назвать эти кубики.
"возьмём УПП, поставим сверху Инталева, снизу УС, слева УАТ, справа УР"

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

Только так и должна строиться работа.
При этом ООП здесь вообще нафик не сдался

(24) Сервисы тоже кому то писать надо. А так вообще баян из баянов. Каждый наверн кто приходит в 1с из другого языка на форум подобную тему пишет. Неинтересно уже.

(26)>"возьмём УПП, поставим сверху Инталева, снизу УС, слева УАТ, справа УР"

Если тебе интересно их собирать как кубики, то оно конечно...
Но кто-то должен и писать эти самые УПП,Инталева,УС,УАТ и УР. Лично мне это интереснее.

(28) они достаточно маленькие, чтоб их можно было без проблем написать процедурно

(29)Не суть маленькие или большие. Важно что без чужих кубиков- ты как без рук. И своих писать не сможешь.

Кубики-шарики.
Спрашивается, почему тогда Java никто не любит.
Там всё из кубиков.
А слово "Модуль" широко используется в 1С!

кстати, говоря о рарусовских продуктах, тех же УАТ и УР - они написаны в стремлении максимально приблизиться к стилю ООП.
Ну там примерно в таком стиле: вместо того чтоб сделать проводку в модуле дока - создаётся высокоабстрактный объект-обёртка, заполняется, вызываются какие-то методы, в какой момент происходит реальная запись проводок - хрен поймёшь
И вообще хрен поймёшь, без изучения ихних "классов" и после УПП - смотреть просто тошно

(31)Имхо зависит от величины кубиков:)
В конце концов асм - тоже из кубиков..только ооооочень маленьких:)

Так кто говорит, что надо писать сразу на языке 1С.
Пишешь на чём угодно, а потом написанное конвертишь в язык 1С - иногда оказывается, что куча кода вырождается в несколько строк - а всё остальное за вас напишет компьютер - и отлаживать не надо.

(31) Почему это Java никто не любит? Весь нормальный мир на нём сидит.

(32) Ты в УПП то видел как движения формируються. Вот уж действительно хрен поймешь после рарусовских продуктов!

(31) Java никто не любит - ложное утверждение. Это у нас никто не любит, потому что не по русски и потому что для РСБУ кубики плохие :)

(36) вопрос привычки. Лучше всё же привыкать к мэйнстриму, чем к разным маргиналам

(0) а зачем? что бы все гламурно было?
Какие конкретно задачи было бы удобнее решать с ООП?

А "быстрота" Java даже кривые реализации 1С переплюнет, но зато Unix+Windows+MacOs совместимо.

(4) это где 1С свой язык как ООП выставляло???

(39) Сокращение числа трудно уловимых ошибок.

(42) за счёт некоторого увеличения числа просто чертовски трудноуловимых ? :)

Хотя вообще не думаю что количество ошибок сильно связано с наличием ООП
А вот с наличием системы автоматического тестирования - здорово связана, и 1С выпустила такую систему ! Вот этим стоило заниматься

(0) Зачем стандарты ООП  нужно переносить в 1С 8?
Вероятно при разработке этого языка высокого уровня уже использован ООП в языке низкого уровня. На чем 1С сделана? На С?
Нам предоставлен предметноориентированный механизм и все ООП уже реализованы во внутренней работе платформы. !? imho

(44) Исправление ошибки на стадии тестирования дороже, чем исправление на стадии кодировки. Думаю программист 1С должен быть более квалифицированным, чем программист C# чтоб писать код с тем же процентом ляпов

(0) Ты же работал с аксой. Там и так с документацией и описаниями на классы бардак, иногда, чтобы понять, что же оно делает, приходится чуть ли не до главного папы лезть и смотреть.
А теперь представь, как всё это реализует средней адинэснег 86-го года рождения и почём это всё поддерживать стоить будет?

(46) а я думаю наоборот
1С заставляет держаться в русле, в шарпе же полная свобода и вероятность плохого дизайна куда больше

(48) Архитектор ПО действительно может сделать что угодно, а вот программсит загнан в более жестские рамки. В 1С же наоборот.

(49) ты видел живые системы на шарпе, к которым приложил руку Архитектор ?
На сколько я знаю, вот уже сколько лет - только небольшие поделки.

Если нет - назови мне ERP на шарпе

(50) Непонятно какое отношение имеет "лично видел или нет" к обсуждению концепций систем. Но все же MS SQL 2008.