К примеру, какой-нибудь конструктор типа СКД, но для интерфейса или конфигуратор для OS X, или хранимые процедуры в языке запросов!
Понятно, что ООП не добавят из принципа, но какие принципиальные улучшения можно ожидать через год!?

(104) 1с реализует виртуальный класс "v_Организация" который содержит

1. Виртуальный Справочник "организации"
2. Виртуальный РС "УчетнаяПолитика"
3. Виртуальный ПВХ "НастройкиУчетнойПолитики"
4. Интерфейс получения/записи данных из РС
5. Интерфейс получения Организации

Далее создается класс "Организация" который содержит

1. Справочник "организации"
2. РС "УчетнаяПолитика"
3. ПВХ "НастройкиУчетнойПолитики"

и который частично переопределяет/дополняе интерфейсы виртуального класса.

тем самым мы получаем разделение функциональности и зон ответственности.

отчасти именно это и реализовано в БСП, единственное чего нет в БСП - это возможности дальнейшего наследования и расширения свойств/данных

(105) Для этого не нужно ООП. Просто делаешь общие модули с общими процедурами/функциями и используешь где надо.

(107) А как на все это должна реагировать БД? Не запариться ли она свои таблицы перестраивать после перегрузки всех свойств объекта?

(107) У тебя в регистре "УчетнаяПолитика" и так основное измерение организация, что уже дает тебе разделение зон ответственности. Разделение функциональности дает использование ПВХ.
Так зачем огород с классами?

(108) так это и нужно, чтобы не делать процедуры ПроверитьКонтров(), ПроверитьСклады,... , ПроверитьСправочникНомер100500(), ПроверитьСправочникНомер100501()...

(108) вообще вопрос применения ООП, заключается не в том, что без него нельзя реализовать задачу, а в том, что с ним просто удобнее. Никто не мешает городить 1000 процедур, 150 переменных и копаться в них. Просто на определенном масштабе проекта такой подход начинает усложнять поддержку/модернизацию

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

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

(113) Если логика данных позволяет попробуй юзать фоновые задания

(114) вот нашел этот язык: wiki:Brainfuck

(114) все пофиг. Они в институтах пару лаб написали на приплюснутом и уверили себя что ООП захавал мир...

(114) "Ты не можешь просто выполнить процедуру. Тебе надо создать экземпляр класса и только потом обратиться к его методу."
Так юзай static. Класс нужен там, где есть логическая сущность, включающая данные и методы их обработки. Если у тебя данных таких нет, то тут static.
Вот есть у тебя класс "автомобиль", у него переменная "уровень бака", и метод ЗаправитьБак(). Ты просто делаешь Автомобиль.ЗаправитьБак(), который никуда дальше объекта не лезет и проверяет уровень, и заправляет если надо.

(111) Ну да, ты плодишь вместо процедур - классы. А в классе оказывается, что "УдалитьЛишниеСимволы" для контров одни, а для складов - другие и ты перегружаешь в каждом классе эти методы. В итоге твой класс скатывается в процедурное программирование с увеличенным количеством кода.

Я хочу динамически создаваемые подписки  на события, чтобы совсем не править конфу, а обработочкой цеплять подписки

(119) ладно, на холивар нет и времени, ни желания. Каждый волен выбирать, что ему по душе

(118) Вот есть у тебя справочник "Автомобиль" с реквизитом "УровеньБака" и в нем экспортная функция ЗаправитьБак(). И где твой ООП теперь?

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

юнит тесты бы...

(122) ты не замечал, что метаданные 1с, и справочники в частности, это и есть объекты?

(124) Хочешь - используй, в чем проблема?

(19) разве там нет ограничения на 99999 строк? или 8.3 убрали ограничения?

(100) что-то не слышно противников ООП Shurjk,  NcSteel. (93) А Зачем ? - это не аргументация, а почему-бы и нет?

Нужна кнопка во весь экран = "Сделать 'Заебись'"

(129) это декларативная парадигма. А тут фапают на ООП

(128) Ну дык зачем?

И почему ООП не смог родить убийцу 1С?

(130) Ну пусть на ООП сделают такую кнопку...
Хотя, ООП - зло само по себе, а уж в учетных программах...

(132)да не нужно ВСЕ делать на ООП...

давайте разберемся, что можно и нужно делать

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

(133) С чего это вдруг? даже в ООП чтоб получить оверрайд нужно вызывать НОВЫЙ объект

(134) у нас обьект "НДС" (подсистема), а все подчиненные подсистемы переопределяют вышестоящий, то есть при создании подчиненной подсистемы ты говоришь, что теперь обьект "НДС" иметт свойства из модуля "НДС_6", и если там свойтсва нет то из модуля "НДС".

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

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

(136) такого огорода уже сколь напереписывали, никто не разберет. Говорят, же, чтоб не городить огород, берешь готовую подсистему, а в своей (наследуемой) меняешь только то что надо.

(133) Так ты хочешь своими методами замещать штатные? Для этого тебе нужно ООП? Чтобы потом разбираться почему это все сообщения стали зелеными или почему отвалился расчет НДС? (137) Ты хоть один реальный пример из жизни приведи, где это нужно и где это сложно реализовать обычными методами, а то я пока что только слышу цитаты из книжки по ООП.

(138) не спора ради, просто интересно.  ты в 1с пришел с какого-то языка или сразу 1с?

в новой платформе будет лисп. или какой нибудь хаскель.
А еще китайский язык.
Ибо - мода и тренд.

Вау - клуб гадания 1Сников? Охренеть )

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

(142) ничего не мешает, так оно сейчас и делается. Только между модулями столько может быть перекрестных, что хр. разберешь. Наследование же позволяет просмотреть иерархию объектов очень даже понятно

(139) развивалось как-то так basic(много) -> asm(поверхностно) -> pascal(много) -> delphi(много) -> c++(поверхностно) -> 1c(очень много). Просто сейчас я активно изучаю java и мне она не нравится. Я пытаюсь переварить эту идеологию и пока не вижу преимуществ. У меня просто растет количество кода, он становится все сложнее, все сложнее понимать взаимодействия.
Все эти "Библиотеки" - это уже есть в виде "Инструментария разработчика" от ТормозИТа, БСП и всевозможных консолей. Вся эта белиберда с наследованием просто оторвана от реальных задач.
Теоретически, чисто теоретически, это было бы удобно на каких-то очень больших и очень хорошо структурированных проектах. Но на это требуется настолько много человеческих затрат, чтобы держать это все упорядоченно...
Любая средняя, да и большинство больших задач решается процедурным программированием. Поэтому я и прошу привести "Реальный" пример от этих теоретиков. Пока что услышал только про виртуальные метаданные от vde69. Да может получиться что-то интересное. Но ценой этого будет потеря производительности, как обычно. И для этого не нужен огород с ООП

(140) ооо, лисп это круто. Куча труЪ одноэснегов останется в прошлом сразу.

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

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

(143) с чего это твой ООП здесь будет лучше? Ты насоздаешь своих классов НДС_6, НДС_5, НДС_4, поперегружаешь там родительские функции, а потом будешь думать в каком месте искать ошибку.

(144) "Реальный" пример - любое отраслевое решение, основанное на БП, УТ и т.п. (например, от РАруса, ВДГБ и т.п.). Вместо, того, чтоб использовать типовую 1С-ную конфигурацию как родителя (не изменяя), перелопачивается куча кода типовой (и так для каждого выпуска типовой версии 1С для выпуска отраслевой).

(146) у твоего комментария ровно 0 пользы. Проходи мимо

(147) Ты можешь чисто теоретически сформулировать жизненный пример преимущества этой идеологии?

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

(152) И ты зашел в эту тему чтобы сказать что все дураки? Ну молодец, что.

(149) И в чем преимущество? Ты будешь перелопачивать кучу кода в своих наследуемых классах. И так с каждым релизом.

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

(153)
<strike>Зедс дэд, беби, зедс дед</strike>
Не все, детка, не все...

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

(155) Начнет с того что объект - не самое важное в ООП. Важно - класс (точнее тип определяемый классом и доступные для этого типа операции.)

(154) и если он облажается то у него будет много интересных и разнообразных ошибок, неведомо как возникающих...

в случае 1С есть все вещи которые дает ООП, просто они "не такие" и ограничены. ну 1С тоже особенная)
например создавая справочник "Организации" создается класс который наследует свойства от глобального класса "Справочник"
Но нельзя создать к примеру "Книга" или "Куб"
новые метаданные нельзя создавать.

(18) Ты удивишься, но она и сейчас летает с 60 миллионами. Правда апдейты делаются напрямую через Merge.

вот мне бы хотелось что бы 1с сделала комипилятор и можно было делать екзешники) и не нужно было ставить платформу 1С клиенту

(161) а деньги?

(162)а деньги мне)

(159) гляньте мельком на яваскрипт...

(164)зачем?

короче! для тех кто говорит, что ооп фигня: представьте что в 1с не было бы документов и справочников, а был бы общий модуль, а там это:

Перем НаименованиеКонтрагента;
Перем ПометкаУдаленияСклада;
Перем ФлагПроведенияТребованияНакладная;
и т.д. тысяч 5 переменных

а потом процедуры
Процедура ПометитьНаУдаленияЭлементСправочникаДоговора;
Процедура СкопироватьАвансовыйОтчет;
Процедуры ОбработкаПроведенияТребованияНакладная

(146) Сейчас уже можно через язык http://vmeste.info/data/vision/


и слух

http://www.vokrugsveta.ru/news/14928/

(165) да теже "справочник" "документ" и т.д.

(166) представь - в 1С есть и справочники и документы уже сейчас.
Не допонял - ты предлагаешь выкинуть то что есть сейчас? ради сомнительного удовольствия диспетчеризации по типу?

(169) нет, это просто иллюстрация того, что ООП в 1С уже есть сейчас, просто вопрос в степени его реализации

Принципиальное новое! Новая платформа 1С 8 будет поддерживать базы данных на 7.7. Причем буду сняты все ограничения на DBF-таблицы в 2 ГБ.
Появится возможность использования баз (и типовых и измененных0 на 7.7 через движок 1С 8 в облачных хранилищах.
Не нужно будет конветировать, допиливать и изучать новое. Все будет работать так, как кому-ту не снилось, или так, как кому-то приснилось.

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

(172) а обработки все будем у мани покупать?

Хочу надежное шифрование всех модулей и вообще конфигурации, что бы ни одна собака не залезла в код

(172) Зачем же так?! Если все заточено в конторе, то зачем бригаде программеров надрываться на генерированием имитации работы. Так мозговую грыжу можно заработать.

(173) маню купит корпорация НГН (Нуралиев, Гилев, Наиспов) Так что все будет в одних руках. Незаментно, с обновлением закроют конфигуратор и вуаля - мир захаван!
"Все звезды светят мне, а банки - платят мне!"(с)

Кстати насчет принципиально нового - предлагаю чтобы 1с ввело виртуальную реальность в свои решения

(177) представляете как будет выглядеть процесс заполнения заказа? Прям как Нео с Тринитей экипировались перед тем как в гости к агенту Смиту зайти?

Интересно а вот как визуализировать процедуру закрытия месяца.... Ну например как сражение с девятиголовой гидрой....

Надеюсь что через пару лет добавят поддержку новой функциональности Гекатона из MS SQL 2014

(55) про триггеры не писал, а хранимые процедуры позволили бы полностью логику на SQL-сервер перенести, раз SQL подобный язык сделали, и хранимые процедуры могли добавить в своем стиле!

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

(171) Режим совместимости с v7.7 - это мечта) Но вряд ли сделают.. по уму, его надо было сделать в самом начале, при старте восьмерки - тогда переход на новые конфигурации был бы плавным и технологичным.

(180) Зачем?

(179) хорошо, но не думаю, что это поможет. У нас узким местом является только лишь сервер 1с, ms sql никогда не надрывается

(0) Про голосовое управление уже было?

http://lenta.ru/news/2014/06/02/1cacronis/
Acronis и 1C запустили сервис «1С: Облачный архив» для резервного копирования данных и настроек платформы «1С: Предприятие». Об этом компании сообщили на пресс-конференции.

Облачный сервис создан на базе технологии AnyData Engine компании Acronis , позволяющей резервировать данные любых типов из любых источников, и облачного решения для создания хранилищ данных Acronis Storage.

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

Сервис предназначен для предприятий малого бизнеса, которые не обладают достаточными собственными мощностями для хранения резервных копий данных. Для резервного копирования сервисом предоставляется 5 гигабайт в версии «Техно» и 100 гигабайт с возможностью расширения по запросу для версии «Проф». Борис Нуралиев, директор компании «1С», считает, что 100 гигабайт на данный момент достаточно для всех компаний.

Сервис входит в пакет услуг информационно-технологического сопровождения «1С:ИТС», который стоит 10,4 тысячи рублей в год по плану «Техно», и 24,72 тысячи рублей в год по плану «Проф». Нуралиев отметил, что для окупаемости новой услуги хватит, чтобы количество подписчиков «1С:ИТС» возросло всего 10 процентов до конца года.

(186) Вот опередил меня. Тож самое хотел вбросить. )))
А вообще опять традиционный срач начался ООП против 1С. Как будто других парадигм программирования нет. Мне вот таки непонятно чем ООП принципиально лучше функциональщины? Тем что данные хранит вместе с кодом? По мне так не очень это.
Давайте в 1С-ке забубеним лисп  - он более для математики подходит. Ту же систему уравнений РАУЗ, мне кажется, проще было описать на нем.

(187) в 1с нет "функциональщины"

(188) Да нету. Но вдруг появится )

(189) И тогда я со спокойной душой пойду в дворники )))

будет Eclipse, синтаксис полностью изменится и будет англоязычным, конфигуратор перестанет существовать, будем учить всё заново, зато 1С перестанут называть недоязыком программирования)

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

можно было бы офисы с винды нахрен увести..

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

(193) А зачем городить дубль?! Конфигуратор уже есть.
Этот огород имеет смысл тогда, когда нет конфигуратора.

Дык вообще убрать его нах. Среда разработки отдельно, приложение отдельно. Байт код и все счастливы.)

Смотри в сторону Scala(144).

интегрируют Flash в 1С, чтобы в игрушки можна была поиграть :)

(197) Анимированная ОСВ! Где 99 счет корчит либо гримасы, либо улыбки.

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

(200)!

Вот чего по-настоящему надо в 1С v8: ПриСменеПодсистемы
Остальное по большому счёту дурь, кроме триггеров.

(199) Если ты по поводу ООП (193), то усложнить, наверное. Хотя сложность тут наверное только для мамонтов типа меня же, кто еще не привык мыслить объектно. Если же ты про (195), то это однозначно усложнение. Но при этом скорость работы и защита конфигураций станут имхо на порядок выше.

(183)  зачем выполнять всю логику на SQL сервере?!

(202) Про скорость и про защиту. Это же 1С. Тут все так непредсказуемо... Или по законам Мерфи ...

(204) Ну тоже верно.) Надо учитывать специфику компании.

(203) так "слегка" быстрее чем лазить в БД, а потом это обрабатываться на сервере 1с и в процессе обработки опять же лазить в БД