Вот написал о эволюции кода 1С - в порядке бреда. Высказывайтесь. #159316

Я ж написал - в порядке бреда, строго не судите. Поток мысли...

причем здесь ООП и стандарт языка? можно удобоваримо писать и на функциональном языке

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

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

Уважаемые, просьба не флеймить. Правило №2.

Да ладно, я ж написал - поток мысли.. :)

А я полностью согласен с автором. Правду пишет.

Согласен с мнением, высказанным в удаленных постах.

совсем не бред ! не дорос до бреда еще ! просто Чушь!

Мысль там и не ночевала...

Вот немогу понять, зачем ООП в 1с? Объясните мне дураку...

Чтоб проблем при поддержке было больше, чтоб сложнее обновлялись конфигурации, чтобы меньше партнеров занималось внедрениями и меньшее количество пользователей покупало продукты 1С...

При желании конечно можно найти тенденцию движения 1С к ООП. Но на мой взгляд 1С создала свою объектную модель и идет по пути ее совершенствования.

Ты реально работал с ООП ?

Видимо пришло время коронной ссылки :

Работал. И не один год.

Как говаривал один известный профессор: разруха - она в головах... 1. Можно успешно писать программы на любых языках программирования и эти программы могут быть устойчивыми и производительными. Просто надо думать ДО программирования, а не программировать ВМЕСТО думания ... 2. ООП само по себе ничего хорошего не добавит в процесс писАния конфигураций на 1С, ибо обезьяна с гранатой - это страшно. 3. Абсолютно пофиг на чем писать нормальную программу ... 4. А как ООП поможет или повредит описанному в ?

В качестве примера - супер, в качестве реально работающей системы ... не уверен, потому что доработки системы (как правило) не являются просто кусками прилепленными сбоку от основного функционала системы. А если это так - причем здесь ООП? :))

Т.е. тебе нужно больше примеров, хороших и разных ? Вменяемым все сказал, упертым - не доктор.

Забавно слышать такое от упертого :-)

Свое мнение - аргументирую. В отличие от тебя.

Ага, нужно :) Попробовав делать так, как описано в примере получил такое ... множество веселых проблем, что страшно стало ... Еще раз: пример с формами или чем-то интерфейсным (в т.ч. к внешнему миру) - кактит на ура, пример со всякими движениями - не в кассу ну совсем...

Бла бла бла... и ни одного аргумента. Скушно уважаемые.

Скажи, а для тебя модуль документа и форма это совершенно разные вещи ? Представляешь себе, gcomp и то, и другое раскладывает в текстовые файлы.

Какого уровня аргументы нужны? А когда gcomp успели к v8 прикрутить?

Меняю я структуру данных в регистре. Соответственно меняю модуль проведения у документа. Как будет после этого работать Ваше наследование?

Как тут у вас весело...

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

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

Я хотел указать основные предпосылки - изоляция (независимость от глобальных переменных и свойств объектов) функций и использование структур.

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

Гениально!!! Распишите, пожалуйста, структуру таблиц для наследования до 4 уровня. У меня структура меняется редко. Но и потребности в наследовании у меня не возникает. А зачем Вам наследование? Вы можете привести реальный пример, когда наследование дает выйгрыш относительно той идеологии, что есть сейчас в 1С? Это не имеет никакого отношения к ООП.

Да, видимо из-за 80% 1Сников ООП и не будет в 1С никогда... :)

Мальчик мой, а причем здесь регистры?? Это всего лишь модель данных, хранящая остатки и обороты. Где их связь с ООП?? Создаются классы, работающие с физическими, нормальными таблицами, а ты про регистры, смех

>>При изменении структуры регистра в типовой 1С выпустит новый класс, наследующий от предыдущего, а мы наследуем от этого нового класса и вносим изменения только в свой класс. Зашибись... Так мы уже наследуем от класса, который стал "отцом" для нового... Изменять наследственность и писать поддерджку (возможно) нового интерфеса - это очень увлекательно...

Интерфейс не меняется, меняется реализация

Вам, уважаемый, нужны бы очки. Я уже приводил ссылку на пример. В

Кстати, могу добавить, что в случае перехода на ООП писать такой кривой код, как в типовых уже будет невозможно. :)

Самы простой пример: Базовая форма с кнопками ОК, Записать, Провести, Закрыть. Одна форма. Ни о чем не говорит?

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

Ах, если бы к Delphi движок 1С по СУБД, писал бы я счас на 1С?!

Видимо твое, поскольку большинство программ пишется на VC++

Вот сравни - что проще юзать OLE (обеъкты и методы хранятся вместе) или влазить в код 1С?

Примерчик про регистры конечно супер... Может кому-то "Объектно-ориентированные методы. Принципы и практика." Грэхема почитать...

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

Даже то что документ в 1с жестко связан с регистром уже многого стоит)) 1С делалась для чайников (6.0), но ничего не стоит на месте, а корешки глубоко сидят в сознании

Рад был бы увидеть Ваш способ для типовых, с сохранением автоматического обновления.

Добавлю еще, что и остальные книжки Грэхема стоит тоже почитать...

от дурости ни%ера не спасает ЗЫ добавте к законам Мэрфи

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

И все же, сходи к оккулисту. Там же написано "пример не претендует на чистоту реализации методов ООП"

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

А машинный код, надо полагать, еще более профессиональный?

Че-то ваще не так, аффтар, тема не раскрыта

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

Не знай - но на 1с писать легче чем на дельфи и на си ++

На ООП разрабатывать продукт такого объема будет не проще...

Удивительно. Ты и бухгалтерию с зарплатой сам писал ?

Я лично могу могу вообразить такой пример применения ООП - написание своих классов на основании базовых, если для них есть функции реализация которых, в базовых классах отсутствует и её приходится постоянно "добавлять". Для этого в принципе есть 1С++.

Да, писал. А Вы писали?

Ну пипец)) Это Осипов был, смотрю фотку видел вроде. Ты писал на ООП языках приложения с СУБД. Сколько в них было форм, таблиц. Я писал с нуля, около 500 таблиц, 300 форм

Именно поэтому 1С Предприятие написано на ООП языке! Чтоб жизнь медом не казалась. А то слишком легко было бы.

Скажу только одно: ИМХО с коммерческой точки зрения введение в 1с ООП будет ошибкой.

Откуда такая уверенность, что именно поэтому?

Видимо ты посчитал затраты на разработку и сопровождение УПП в обеих вариантах ?

И с чего Вы взяли, что при написании платформы использовалась только парадигма ООП?

(+63) Т.о. что нужно от 1С - реализовать поддержку подобного механизма на уровне движка + хранение коллекций классов + контроль версий (типа как в .Net манифесты - известно заранее что эта dll не будет работать со сборкой ниже определенного номера).

никто же не призывает писать на чистом с++)) русский народ интересен своими крайностями в суждении. Речь идет в статье о создании предметно-ориентированной и в то же время поддерживающей все принципы ОПП среде. Щас ппридет Волшебник и скажет: что 1С поддерживает что-то из ООП, что нет его четких определений (а они есть, см Буча). Эта тема былп месяца 4 назад

Оно конечно хорошо - сразу послать куда-нито и закрыть спор :)) И тем не менее - какого уровня аргументация нужна: не работает в приципе, сложно реализуется, усложняет разработку или конкретный код?

Некоторые фишки можна было бы создать - но не все ...

А нафига тогда вообще своё IDE создавать? Пускай 1С выпустит "набор кубиков" для Visual Studio 2003-2005. И несколько "типовых" solution. И пиши сколько влезет.

(+75) Даже язык можешь сам выбрать...

Примеры

Что-бы зеленые грести. Тебе еще надо и визуал студио копать и покупать и проч.. к тому же естче коды украдут сразу-же

Будут продавать как "Комплект разработчика"

А .NET + Visual Studio разве не является именно таким решением?

Не понял, но попробую ... твой пример показывает добавления к существующем движениям другие движения по другому регистру. Допускаю, что таблица, из которой берутся данные где-то правильно рассчитана. Теперь представляем, что нас не устраивают движения, формируемые базовым классом... Видится несколько вариантов действий: 1. полностью переписать реализацию базового класса (если она открыта для изменений) 2. полностью реализовать в нужных местах свою реализацию вместо базового класса Если добавить к этому необходимость использовать результаты работы базового класса для последующих расчетов (что, как правило и случается), то получаем еще большие проблемы, т.к. нужно полностью переделывать способы и методы работы с БД... P.S. Несмотря на твое хамство, я по-прежнему считаю, что от ООП есть толк, но в части работы с ... хммм учетными данными. Кастомные контролы и формы, некие системные фичи, типа врапперов над базовыми методами ftp etc

Неужели ты не понимаешь разницы между первичной и предметно-ориентированной средой? Есть Navision, я слабо знаком, но там по утверждениям, есть слои, базовые и ваши, то есть аналоги классов. PS. Любой спор о недостатках 1с свводится к "мордобитию", неужели не хочется видеть ее лучше и удобнее?

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

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

"Лучше и удобнее" для кого? Для программиста - на всех не угодишь: кто-то жить не может без ООП, кому-то нравится ФЯ, кому-то нужна динамическая типизация, а кому-то статическая с выводом типов. Если лучше и удобнее для пользователя и "сопровожденца", то это уже вопросы не столько к платформе, сколько к конфигурациям.

При 20 уровнях наследования затормозит и Феррари, если наследник Камаз. Наш спор пустой, без цифр и дроказательств, и даже эмоций маловато))

Вот примеры проблем ООП: P.S. Качество программ определяется не столько языком, сколько опытом и знаниями автора.

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

Посмею заметить, что УПП тормозит и без наследования. А если еще и отнаследовать...

Только выше базового качества программ вряд-ли прыгнешь, достаточно открыть индустриальные типовые конфигурации, их же надо хранить, как девочку))

1. И при этом объясняем всем остальным потомкам базового класса о смене иерархии? 2. А если эти изменения нужны для всех потомков базового класса? 3. да не вопрос, а как передавать результаты работы предка в потомка? - все в базу писать?

Это Navi томозит ??! По сравнению с УПП он просто летает!

в ты смотришь в корень)) а вот это уже интересно и справедливо))

Это всего-лишь (по памяти) мнение человека, очень плотно работающего с Нави. За что купил - за то продаю...

ПО крайней мере лично меня бы ООП избавило бы от вот такого вот набора функций и соответственно их вызова, кстати, хотя бы ссылку на функцию дали, я бы сам ООП замутил. :) Я уж не говорю про компоненты форм - готовые элементы управления.

работающего в 1980 году?

А чем Вас не устраивает, допустим, COM модель. Там нет наследования, но расширять функционал базовых компонент в принципе можно (если позволит автор компоненты).

Объяснять не надо. Те кто хочет, пользуются старым интерфейсом, те кому нужно - новым. (Интерфейс - это фактически функции класса) Тяжело словами объяснить. Чтобы понять нужно почитать и попрактиковаться.

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

И как быть когда у разных интерфейсов разное отображение на данные? Ну не хватает мне реквизитов в типовых документах.