Коллеги, вы наверняка знаете что в классических языках программирования существует принцип DRY - don't repeat yourself (не повторяйся). Прежде все речь идет о способах лаконичного написания кода без дублирования участков кода. DRY тесно связан с ООП.
Как известно в 1с точно нет ООП и скорей всего отсутствует DRY. То что мы сейчас видим в типовых это бесконечная лапша из кода. Причем повторяются не только отдельные конструкции, но и целые блоки. В результате общие по смыслу участки кода могут появляться как в модулях документа, в общих модулях, в модулях обработки и так далее. Из за этого разбор кода типовых превращается в сущий адский ад. У меня вопрос. Хорошо, 1с не хочет давать нам ООП, но они также не знают о существовании принципа DRY ? И не пора бы им узнать и начать его использовать? Что помогает вам в разборе типового кода 1с ?

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

(0) а ты сам-то в "каноничные ООПшные" системы заглядывал? Вот взять какой-нибудь ентерпрайз на over 10 миллионов строк кода, через который прошла не одна сотня программистов, среди которых были и индусы, и говнокодеры, и детишки клерков, получающие первый опыт программирования... Ну и как ты там будешь проверять дублирование кода?  Там целые подсистемы могут дублироваться, не то что строки кода или методы

(0) тебе нужно DRY? Ну покури БСП - там этого DRY выше крыши!

(25) и дальше что? Это аргумент в пользу чего?

(16) > Открытие формы счета на оплату в УТ11 вызывает всего 35 общих модулей. При этом количество вызовов к этим модулям 737 !!!! При открытии формы счета !!

Так ведь уже была версия, что код типовых это просто легальная обфускация (с помощью средств внешнего программирования) со стороны фирмы «1С». Которая явно направлена на ограничение открытости платформы. К чему это приведет? К тому, что народ будет искать альтернативы новым версиям 1С

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

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

(25) :) напрямую да но бизнесу так же нужно все и вчера так что косвенно нет

(19) Вот такая клиент-серверность?

(26) Пример приведите как бы реализовали чтото в 1с с использованием наследования

(36) эээ, а зачем?

(26) Вы вообще понимаете, что современный 1С это по сути pure-SQL, ORM'а в нем кот наплакал. А учитывая что в самом SQL наследования и полиморфизма по сути нет (в MS SQL вообще, в PostgreSQL одна видимость, а в Oracle есть в виде какого-то мутанта из ООП и SQL), чего вы собственно от 1С хотите то?

(41) Ну, братец, расскажи-ка нам, неучам, как серьёзные пасаны работают.

(42) Так я наоборот защищаю 1С.

(41) ты не путай гостевой раздел и форум. За оффтоп можно уйти надолго!

(42) он тупо не знает что такое 1С. И про юзабилити понятия тоже не имеет.

(20) В трех словах чем там дело с этими ветками закончилось и почему превратилось в мем? )

+(46) А то пздц много читать, очень влом

(46) В двух словах - пришел лесник Ежов и вломил всем :))

(43) Ты статью-то "Почему не 1С" когда допишешь? Ждем-с...

(49) Тут rphosts уже предупредил про оффтоп.

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

(41) Заказчику поровну внутрянка,это не понятно до сих пор?

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

(51) на меня чего накинулись? Я на конкретный комент автора отвечал. Нельзя сделать наследование не поддержав его на уровне запросов, а его даже SQL не поддержал.

>>Заказчику поровну внутрянка,это не понятно до сих пор?
Ну так закройте тему на этом. Зачем вообще автору отвечать.

(40) > эээ, а зачем?

Речь идет о деобфускации типового кода. А с каким кодом легче работать? С запутанным (фирмой «1С») или «нормальным»? Думаю, ответ очевиден. Альтернатива – писать собственные конфигурации, но это очень дорогостоящее удовольствие.

(51) Заказчики разные бывают, но большинству да, пофигу.

(53) Так репутацию ты такую заработал, вот и получаешь по заслугам :))

(53) Он в своей теме про oddo был куда как корректнее

(32) Куда смотреть ?

(58) Внутрь себя :)))

как отсутствие ООП мешает зать DRY (то бишь выделения общего кода в процудуры-методы) ?

(59) я не хирург экспериментатор.

(60) вообщем да.

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

тс просто отстал от жизни или сидит на УПП 1.1

(29) "Наследование - это худшее, что есть в ООП"

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

Три столпа ООП и они прекрасны.

В 1С с натяжкой есть только инкапсуляция.
но нет ни наследования, ни виртуальных классов, ни указателей, ни перегрузок, ни делегатов, ни .... дохрена чего нет.
Сокетов блин нет! Нет настоящей параллельности.

(63) это раньше было три. Сейчас обычно говорят про 4, добавляя еще абстракцию.

Вот простая статья про ООП и т.п., даже назвал бы её ООП для 1С-ников :)) https://habr.com/ru/post/446816/

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

+(66) скорее даже абстракция встроена в сущность любого программисрования. Программирование само по себе - это абстракция и моделирование. Любое программирование, даже на asm'е

Вот другое мнение об ООП (tl;dr)

http://rsdn.org/forum/philosophy/7539267.1

(63) Без наследования прекрасно можно жить даже в ооп.

А что в современных конфигах много повторяющегося кода? Я просто не в курсе.

(69) черт с ним с ООП, ты не ответил, куда смотреть ??

(70) я бы так не сказал.

(68) Когда программисту делать нечего  - он парадигмы ООП вылизывает :))

(70) От вендора - почти нет, платой за это идут лютые конструкции.

Давно пора сделать иерархическое наследование методов общих модулей. Чтобы не было этого заката солнца вручную через ОбщийМодульРасчетНДФЛПереопределяемый и тому подобное. Когда спагетти-код вместо простой и понятной иерархии.
Кстати, расширения - это очень похоже на наследование методов.

(69) А как вы полиморфизм обеспечивать собрались без наследования (напоминаю что в ООП в основном имеется ввиду именно subtype полиморфизм)? То есть от ООП только инкапсуляция останется?

(75) Нинада наследование.
Расширение тоже плохой пример.
Я видел конфу с 15 расширениями, работать в таком тот ещё ад.

(75) Какое нафик наследование, когда при изменении базового класса расширение падает к хренам собачьим :))

(77) Проблема тут скорее в юзабельности интерфейса конфигуратора, что не видно четко иерархию применимости расширений к конкретным объектам метаданных. Именно это и вызывает сложности при множественном расширении.

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

(79) конфигуратор уже прошлый век

(81) Вот только про ЕДТ не надо тут. Глючное тормозилово.

код из типового 1С не надо использовать и всё :)
и из БСП не надо ничего использовать.
Я делаю свой личный модуль "МодульСервер" и использую только его,
в том числе только оттуда вызываю функции из типовых модулей

(3) Например, наследование нельзя сделать программно. Есть только как-бы двухуровневое наследование на уровне дерева метаданных.
Из-за этого имеем почти в каждом документе имеем одинаковые куски кода из процедур а-ля "ПодготовитьТаблицуДвижений". Так был бы на уровне конфигурации базовый класс, который вызывал бы эти процедуры и их не приходилось бы писать в каждом документе.

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

(84) Ну будет у тебя не в одном месте, а спагетти в другом.
Посмотри тот же МодификацияКонфигурацииПереопределяемый.присозданиинасервере.
В чем преимущество то?

(86) или какую нибудь подписку с типом ДокументОбъект
Пока я вижу какое то абстрактные слова что будет проще, но на деле - захожу в менеджер 2 минуты и мне все ясно.
Захожу в подписку общую и пол часа курю код.

(54)мне нет дела до БСП, пока оно работает норм.

(87) когда люди программировали на q-basic или pascal, им тоже вобщем-то было всё ясно )

(87) смысл базовых классов в том, что тебе не нужно вообще туда заходить. код базового класса должен работать качественно.

(90) а реалии в том, что ничто не вечно, хочешь ты или нет но рано или поздно - прийдется.
Изменения базового класса - золотые.

Вроде даже в SAP ABAP сделали ОПП со всякими наследованиями и полиморфизмами.

(0)Как ваш драй работает с модульным ПО?
есть Модуль работы с сетью
есть Модуль работы с графикой
есть модуль работы с.... бд

и эти модули допустим пишутся разными командами...

(0) Кто решил что ООП это хорошо или правильно? Плюсы по сравнению с функциональной парадигмой?

(94) где в 1С функциональная парадигма?

(95) Вы ответьте на мой вопрос, чем ООП лучше функциональщины? А я вам расскажу, что такое DSL и зачем он нужен

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

(97) чем легче?

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

+(99) это то, чего вообще никак в процедурном коде не достичь. ну - без дублирования кода не достичь.

(97) "Легче запомнить объект с его методами чем лапшу из процедур и функций" - зачем нужно запоминать?

(97) >> Легче запомнить объект с его методами чем лапшу из процедур и функций
С точки зрения "запоминания процедур и функций" отличается объект с экспортными процедурами/функциями от глобального модуля с экспортными процедурами и функциями?

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

(99) Это в теории или при ну очень хорошем проектировании. В реальности достаточно часто возникает ситуация, когда не удается написать нормального потомка без изменения предка - просто потому что для чего-то область видимости неудачно выбрали, где-то в иерархии звено пропустили и красиво унаследоваться теперь не выходит и т.д.

(96) с функциональными языками не работал, поэтому сравнивать не могу. на мой взгляд, это вообще языки для разных областей, их не корректно сравнивать. Функциональный больше для математики, на мой взгляд.

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

(106) Во первых, в (97) вы сказали, что "Легче запомнить объект с его методами чем лапшу из процедур и функций". Про данные речи не шло.
Во вторых, является ли хранение данных внутри объекта достоинством или недостатком ещё надо аргументировать. Например, в функциональном программировании "данные внутри объекта" хранить вообще не принято. И ничего, никто не говорит, что это плохо.

(104) Проектирование системы классов в ООП само по себе неординарная задача в более-менее больших и сложных проектах. А ошибки в проектировании стоят очень недёшево.

(97) зачем запоминать-то? Ну и это

ООП
Объект.Хуяк1();
Объект.Хуяк2();
Объект.Хуяк3();

Функциональное программирование
Хуяк1(Объект);
Хуяк2(Объект);
Хуяк3(Объект);

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

Стиль 1С называется FTA (F**k Them ALL) И мне это нравится)))

(110) по-русски это называется "ЁБА!" и не расшифровывается

(109) на ФП будет как-то так:
Результат <- Данные =>
   Хуяк1 =>
   Хуяк2 =>
   Хуяк3 =>
   в_продакшен

Хотя, в_продакшен, скорее всего,  будет нечистой, её из цепочки вынести бы.

(97) Учите мат. часть
https://ru.wikipedia.org/wiki/Процедурное_программирование

https://ru.wikipedia.org/wiki/Функциональное_программирование

Потом как разберётесь в вопросе, приходите

(113) К чему отсылка к сравнению процедурной и функциональной парадигм программирования?  Sysanin_1ц, по моему, и не утверждал, что в 1С используется функциональное программирование.

Сами "гуру" от 1С вообще утверждают, что основная задумка в 1С - это ПОП (Парадигма предметно-ориентированного программирования).
http://1c.ru/rus/partners/training/edu/theses/?y=2008&s=7&t=115

Хоть я и не "натуралист-биолог" - в мире множества парадигм программирования особо не разбираюсь. Но сдается мне, что в 1С всё же больше от процедурного программирования, чем от ООП.

(112) Это питон какой-то.

(115) А почему не ес6?

(114) "основная задумка в 1С - это ПОП"
Это многое объясняет. Особенно структуру типовых.

Вообщем, как-бы мы не спорили, что лучше было из этих парадигм положить в основу "языка" 1С. "Они" перелопачивать движок 1С уж точно не станут на основе наших хотелок. В прошлом уже фирма 1С показала свое отношение к народному проекту 1С++. В 1с8 мало что из предложенного было реализовано (.

(114) Вы сначала вопрос мой прочитайте, который я задал Sysanin_1ц, а потом уже участвуйте в дискуссии

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

Забавная тема когда есть БСП

(0) стараюсь писать в dry-стиле, и типа процедуры-функции не более страницы на экране

На самом деле в программировании есть более важные принципы, чем DRY. Основные из них это принцип сопряжения и принцип связности. Когда кладут на эти принципы, код становится тяжелее сопровождаемым и хуже воспринимаемым, т.е. несоблюдение этих принципов стоит $$$

(123) Самый главный - это KISS

(122) Стек же отращивается.
Несколько функций - api, а вот сама реализация - максимально в линейном стиле, не важно какой длины, как правило если хорошо заархитектурил кода будет мало.
И естественно против механизмов сделать все.
Каждый вздох - отдельный механизм.
Вполне себе читабельно и изменяемо

(0) когда ты в совей чистой ж ООПке прицепил 2 библиотеки, которые используешь на 0.05%, да еще и на 50% дублирую друг друга, ты хочешь сказать, что у тебя DRY?
Ты заблуждаешьтся - нет предела совершенству
-----------------
Процедуры и ф-ии в ОМ - это тебе пример DRY

(124) переведи .

(127) https://ru.wikipedia.org/wiki/KISS_(принцип)

(128) ах вот как мой любимый принцип называется)

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

(124) этот принцип относится не столько к программированию, сколько к проектированию