Тема создана по мотивам http://www.kuban.ru/forum_new/forum9/files/282593.html. В той ветке вопрос ставился гораздо шире, а результат свалился из области 1С очень далеко.
Поэтому прошу в этой ветке отвечать на вопрос хотели бы Вы видеть ООП в 1С? Желательно аргументировать. Если нет, то почему. Если да, то в каком виде?
P.S. Тема специально создана без возможности для голосования

ООП 1с не нужен:
1) ООП накладывает ряд ограничений по быстродействию. Еще более тормознутая 1с - это перебор..

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

(0) потому, что ООП требует жесткой типизации, а платформу с жестко типизированным языком труднее продавать.

не наше это... не надо
представьте как копать УПП, например
ЗЫ. или не доросли мы еще

(2) Почему? Если в VCL от Delphi жесткая типизация, но ее все используют (из тех кто использует VCL)
(3) Так может проще будет, осбоенно если базовые классы документировать хорошо

(3) не доросли. Было бы ООП, там бы и копать проще было, поскольку реализация от интерфейов была бы отделена, а большая часть нашей работы как раз и сводится к тому, чтобы понять что с чем влияет и на кого взаимодействует

(5) А это как напишут, может бы ты плевался далеко от одного словосочетания ООП в 1С..

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

(4, 5) Я бы не осилил (по крайней мере сразу). Это жесткач

(8) глаза боятся, а моск, он на то и да человеку
(6) понятен план, но в (0)-то просамоё идею, я про идею и отвечаю 8)

Нужен ООП и прочие прелести? Прямые запросы? Юзайте .Net и SQL..

Опять? Только ветка была про это

А что говорили разработчики? И вообще зачем гадать, юзаем что есть :)

(10) а в том-то и дело, что не нужны

(13) <> (7) ?

(14) =

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

(16) "это сделает его и быстрее" - это за счет чего?

(17) +1

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

(17) более структурированный код поддается лучшей оптимизации...
например загрузка не модулей по требованию а объектов?
или хранение объектов в базе (интерпретация по методам хранимого)?

были как то тесты сравнения borland c 3.1 и аналогичная программа написанная примерно равный прогером за тоже время на borland c++ 3.1 система писалась неделю (большая) какая была быстрее?

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

(19) при любом мозге лучше понимается, по скольку люди мыслят объектно, однако, прелесть ООП не в читабельности, а в инкапсуляции и наследовании. А сколько раз хотелось иметь возможность написать что-то вроде

class TОбработка: public TВнешняяПечатнаяФорма{
// а вот тут уже много чего не нужно реализовывать, поскольку это уже реализовано в родительском классе
};

мечта просто...

(22) А что мешает написать свою универсальную функцию/процедуру?

(30) "например загрузка не модулей по требованию а объектов" - это к языку имеет косвенное оношение.

(21) Это компилятор быстрее был. Мне преподы (не один, целых 4) втирали что ООП тормознее..

И схемы рисовали и научно это все красиво втирали..

(23) процедура не имеет атрибутов, методов, кроме того, виртуальных (переопределяемых) методов у процедуры тоже нет, да много еще чего нет

(26) [дабы соблюсть справедливость...] "научно и красиво" - это характеристики ФОРМЫ, но ни как не СОДЕРЖАНИЯ

(27) Знаю, но немного подумав все равно можно извернуться и прокрутиться..

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

(28) Ну вот в сети нашел:

http://grizlyk.chat.ru/my/1.htm

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

Можешь еще про ООП почитать.. Содержание очень простое, ООП к сожалению не позволяет достигнуть лучшей производительности в связи со свой структурой.

Как Вам объектно-ориентированное расширение SQL. Например:
1. выдать сотрудников с названиями их подразделений:
SELECT Сотрудники.Наименование, Сотрудники.Подразделение.Наименование
FROM Сотрудники
2. провести документы за период
EXEC Документы.Провести()
FROM Документы
WHERE Документы.ДатаДок BETWEEN :НачДата AND :КонДата

(30) ок. Что быстрее, ООП или процедруные ЯВУ

(31) смеюсь сквозь слезы, учите матчасть, коллега! Еще раз повторяю, не в производительности дело. Требуемой производительности можно добиться на любой платформе, была бы необходимость.
(32) сам придумал?

(34) Отчасти да

(34) аналогично, смеюсь так-же..

+ (36) Я как раз про производительность говорю, что в рамках 1с отнюдь не последнее дело. Тут ведь баланс нужен, баланс скорости написания работы и скорости самой платформы..

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

+(32) Причем Провести() override-метод, то есть перегружается для каждого вида

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

варианты ответов нужны?

(40) Но если программа будет выдавать 2+2 за 16 секунд она тоже никому не будет нужна, т.к. за эти 16 секунд у нас продают на десятки тысяч товару..

Баланс, и еще раз баланс.. Создавать скриптовый язык с ООП.. лучше не нада..

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

(41) ОФФище http://www.dgorg.jino-net.ru/ не открывается в опере, это так и надо?

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

(43) Я не разбирался, времени нету. Там флеш какой-то корявый, 8-й или 7-й - не помню... Могу флешку на мыло послать. Хотел красиво - а вышло как всегда, не грузиться у некоторых и все, а у меня работает на всех машинах, черт его побери..

(44) Я фастрепорт видел, отменная дрянь.. так же как и кристал репорт

+ (46) имхо..

ООП в действительности быстрее чем процедурные языки... стоимость перевызова сейчас минимльна а повторное использование кода в ООП намного более оптимально...
к тому же обновление при ООП станет тривиальной задачей!
(оно не заденет пользовательский ков вообще!) последнее и есть основной плюс ООП

(46) фастрепорт написал 1 человек :)))

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

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

Как вы думаете, что работало бы быстрее?

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

ЗЫ я чо-то умное сказать хотел, только забы, что именно, кто-нить догадался?

(49) было бы чего писать.. я при должном финансировании и 1с 7.7 напишу один (платформу)

(51) Я тебя прекрасно понимаю, что ты хочешь сказать про красивости. Я их тоже люблю..

давайте разделим тему на 2 разные:

ООП и УПП

и ООП и остальное....

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

(54) Вот! уже лучше..

(55) значит меня не слушал.... ООП нужен для УПП и может быть для комплексной которая выйдет скоро.... для остального - зачем?

(56) Для остального тоже покатит, по поверю в ООП на 1с только тогда, когда я его там увижу (в оригинальной версии производителя)..

(50) а если воспользоваться потоковыми интструкциями то будет намного быстрее...
я когда писал граф библиотеку - у меня линия, точка и треугольник были классами... только полностью на ассемблере :))

(57) что в бухии скрывать за интерфейсным слоем?

(56) для повтороного использования кода, например

class КомплекснаяКонфигурация: public Торговля,Зарплата,Бухия{
//переопределение спицифичных методов
};


(58) кхм, если написать класс треугольник, линию и точку на асме, то я думаю они будут все таки быстрее, чем даже потоковые.. :)

(60) Ну это ваще мечта :)

(61) опять-таки - как писАть...

(60) не взлетит...
скорее
class списание{
}
class ФИФО:списание{
}
class ЛИЛО:списание{
}
class средняя:списание{
}


или class единицахнанения{
}
class материал:единицахнанения{
}
class товар:единицахнанения{
}
class алкотовар:товар{
}
class одежда:товар{
}

(61) потоковые инструкции ассемблера имелись ввиду

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

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

(67) в чем разница от процедур?
если какой то метод тормозит - перепиши его с наследнике и вставь наследника вместо переписан ного класса... будет тебе плюс...  и при обновлении ничего не затронется

ООП - в первую очередь легкость обновления!
сколько так и останутся сидеть на УПП 1.1 из заа этого?

(68) Как это при обновлении ничего не произойдет? А если как раз этот класс и переписан был фирмой 1с? Для того, чтобы обновления по максимуму не затрагивали наработки юзаются слои..

(68) А если у тебя в наследовании 200 классов, пойди докопайся где у тебя глюк..

Хотя в принципе все зависит от конкретного примера, и реализации..

(69) Куча не ООП проектов, для которых обновления не являются чем-то болезненным. Тут главное грамто придумать структуру системы и ее модулей, а также регламент внесения изменений в систему. Изначально УПП не расчитана на изменения, а как большие ЕРП проекты заточена на минимальные внесения.

переписан класс -  ты наследуешь и подменяешь... проблемы будут или в случае смены функциональности (что редкость) или если руки кривые

пример
класс товар{
}
класc одежда:товар{
перем рост отобр //автоматически отобразится в табличной части при выводе например в форме список номенклатуры и т д
перем размер отобр
перем тип // автоматически не будет попадатть в таб части

выбратьпопартиям //
{
выбирает этот объект с учетом доп свойств можно наложить доп фильтр, можно и написать с нуля
возврат массивчегото
}
выбратьпоместамхранения //
{
выбирает этот объект с учетом доп свойств можно наложить доп фильтр, можно и написать с нуля
возврат массивчегото
}
списание{ // не трогается вообще!
}
}

1С - доступно и всерьез (с)
Счаз сколько прог 1с получает в Москве? А сколько он будет получать если в 1с появиться ООП? О доступности речи не пойдет - потому ООП и не будет.

(75) я бы срезал... за упрощение :) как мне обещали после перехода с 7.7 на УПП

(76)Упрощение после перехода на УПП?!

(77) вот я и не чешусь по поводу ввода данных там...

(78)Маразм у вас - сваливай оттуда

А кстати УПП не так уж и сложен ;-) Покрайней мере один человек все модули понять может, как укрупненно так и в деталях. Единственное заковыка предметная область тут при внедрениях нужны консультанты. А как ПО УПП еще "читается".

(80) у УПП основной минус - явное дублирование хранимой информации.... ООП это бы скрыло !

(81) Непонятно. Что значит "явное дублирование хранимой информации". Одинаковые по составу регистры для разных направлений учета?

МестаХраненияБух
ПартииБух
бухпланСчетов

А как ООП может помочь "скрыть" существование таких регистров. Их наличие обусловлено:
- структурой базы данных
- различными областью применения этих регистров
Не следует забывать что все эти регистры могут двигаться асинхронно. Т.е. сначало оперативный учет (МестаХраненияБух), а потом подтягиваться партионный учет (ПартииБух ) и бухгалтерский (бухпланСчетов).

а вариант двигать ПартииБух только без расширения партии? как это сделано В отчете о розничных продажах? или что еще проще сразу по плану счетов, без сумм, которые подвязывать по необходимости?

Всплывем...

Буду сам писать свою платформу

поднимаю ОдинЭсОбъектОринПрогСрач

(84) Регистры это часть структуры данных. Интересно, как наличие определенной структуры данных обусловленно структорой данных? :-)

Если будет ООП, то будет наглядный код. Если будет наглядный код, то разобраться сможет каждый дурак.
А разьве нам надо чтобы мог разобраться каждый дурак ?

(90) Наглядность и ООП не связаны между собой, по-моему.

(91) Одна из легенд ООП. На самом деле все зависит от грамотной разработанной структуры классов, что справедливо и для процедурных языков, когда грамотно разрабатывают библиотеки функций.

(91) +1...
(92) Сколь нагляден код в С++?

(93) Ровно столько сколько и на С ;-)

(93) Насколько наглядна такая конструкция: "x+++++y"? :-)

Мдяя. Дятлы во всей красе. ООП в стандартном понимании никогда не будет. Позволю себе усомниться во вменяемости людей, ратующих за ООП. С++ был ЖОПОЙ по реализации в компиляторе. И прочие поделия тоже. Единственные массовые реализации ООП приличного качества это Ява и СШарп. Однако сии реализации могут тормозить нехило в кривых руках. При сравнении ООП и ПОП (процедурно-ориентированного программирования) неплохо бы учесть реализацию транслятора: кривой транслятор убъет на корню любую красивую идею. Ну и как существенный минус ООП-реализаций все почему-то забывают непредсказуемую работу мусоросборника, на которую повлиять практически невозможно. Для пользователя активация помойки является случайным торможением, причем торможение определяется кривостью кода. Вот этой зависимостью от кривизны рук/мозгов/реализации ООП и убивается в массовых проектах.
1. Ограничения снизу на мозг разработчика
2. Ограничения снизу на мозг издателя (документировать надо КАЧЕСТВЕННО)
3. Ограничения снизу на мозг пользователя
4. Ограничения снизу на мозг саппортера
Все это приводит к дефициту спецов, росту цен и о какой массовости в таком случае можно говорить?
.
ПС Наваяйте класс ДОКУМЕНТ, способный работать в многопользовательском режиме, сделайте его работоспособным, а потом наваяйте ввод первички из хотя бы 3 видов доков-наследников, да так, чтоб работало. После чего прикиньте, осилит ли это студент Вася? Я проделал это на Фоксе, опыт грабель есть. А теоретический киздеж "как было бы красиво" киздеж и есть.

(95)работа такой конструкции является UB - неопределенное поведение.
Один компилятор посчитает как (x++) + (++y), другой как x + (++(++y)). И если кто так пишет, то он сам себе злостный чебуратино.

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

(98)это вызвано экономией тиков.
Конструкция "x++" занимает меньше тиков, чем "x = x + 1". И логичнее выглядит.
Кто не хочет так писать, используют вторую конструкцию, но так не пишут :)

(99) каких еще "тиков"? или компиляторы в наше время не умеют оптимизировать код?

+99
"x++" - x.operator++() или
"x = x + 1" - x.operator=(x.operator+(x(1))) - есть разница?

(101) Не зная устройства "operator++" и "operator=", говорить о разницах смысла не вижу

(102)и не надо говорить, первый вариант быстрее.

(0)Наличие ООП в 1с было бы плюсом. По крайней мере наследование.

(61) Не факт - разница неплохо гасится за счет оптимизаторов.

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

(96) тупость мусоросборщик есть в 1с (даже больше в 1с нет явного удаления в отличии от С++)... я что то не видел там явного удаления таблицзначений.... или я что то пропустил?
(99) тупость... современные компиляторы переводят и первую и вторую конструкцию в inc x (например "современный" BC 3.1)

(106) интерпретация кода в 1с и так есть... вообще интерпретатор КРАЙНЕ мало поменялсябы

(107)для простых типов типа int да.

классов в 1С даже "штатно" можно на создавать...

(109) я что то не помню, что бы у сколь нибудь сложного объекта реальной системы использовалось ++ или --
я не беру STL (это особая песня)
я беру классовую иерархию объектов тика доки и справочники в 1с

(111)
X* pX = new X[100];
while(pX)
{
   foo(pX);
   pX++;
}

+112 а вообще, перегрузить можно как угодно.

и что это значит?

(114) он грит, что у него 21,5....

(113) Перегружать операции и работать с массивами а-ля С++ думаю 1С не надо

(114)ничего, просто пример :)

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

(118)smart pointers в твой список еще.

(96) Фигня-фигней. Дай студенту Васе УПП. "Осилит ли это студент Вася?"

smart pointers??? это что?

(121)не ясен перевод или что они делают?

(122) туп я.... не знаю что такое :)) в пяти словах...

(123)"Smart pointers are objects that look and feel like pointers, but are smarter." - это в качестве юмора.
Умные указатели, обычно используют для контроля за выделяемой памятью (выделять, чистить за собой, не допуская утечек).

(124) я считаю, что они должны быть реализованы на платформе :))

(125)на сколько я знаю, стандартом это не определено и отдано на конкретную реализацию компилятора.

(126) я про любую платформу....

продолжим ОопСрач

Нет, не хочу. Я потом не хочу разгребать всю эту иерархию объектов. Без ООП что вытворили в первой редакции ЗиКа? Что-бы было с ООП?

Нафиг не нужна. Особо возбудимых можно удовлетворят мыслью что создаваемые или документы по сути наследники абстрактного класса "Документ"

(129) Вообщем ты прав)))

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

(131) а как в VS обходятся без плана счетов и субконто?.. без остатков и оборотов?..

(132) На самом деле обходятся... Я писал и поддерживал крупный проект на VB (бюджетирование) Но из-за отсутсвия предметной ориентации языка писать конечно значительно сложнее.
Когда перешел на 1С - тут-же в неё влюбился, настолько всё делается проще...

1C предметно-ориентированное, то еть в терминах сабжа - 1С это ПОП