Используются или могут ли использоваться принципы SOLID в 1С?

wiki:SOLID_(объектно-ориентированное_программирование)

Где пункт КГ/АМ?

1С платформа и так достаточно предметно ориентирована.
Зачем надевать ещё одну одёжку, если она уже есть внутри?

(2) показывай уже

Это смотря кому нужно. Тем, кто на основе типовых делает свои решения - да, нужно безусловно. Самой фирме 1с и внедренцам типовых - не нужно.

в 1с очень мало программистов, в основном бухи перебежчики, они и понятия не имеют что это такое.

где вариант "Нет, причина в тех кто ее конфигурирует"

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

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

Создаём класс ПлатёжныеДокументы, делаем 4 потомка: ПКО, РКО, ППВ, ППИ.

Вам это надо?

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

(8)>>Создаём класс ПлатёжныеДокументы
и как ты это собрался сделать?

(10) возвращаемся на 77 и вуаля!

(10) Он теоретически) Еслиб было можно.

(8) можно еще проще, делаем один документ и разруливаем по коду операции, никакого дублирования кода :)

(10) Если вы этого хотите, то переходите на ООП и забудьте 1С. Есть ещё один большой плюс - за вашу нетленку никто не возмётся больше
(13)  ага, и каждый модуль портянка на 100500 страниц

Принцип открытости/закрытости
Программные сущности должны быть открыты для расширения, но закрыты для изменения.

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

Да есть в 1ске все нужное от опп, можно же для примера из (8)
Создаём класс ПлатёжныеДокументы, делаем 4 потомка: ПКО, РКО, ППВ, ППИ.

Сделать общий модуль ПлатежныеДокументы, базовую форму в общих формах...

(0) солид один стоит 500 т руб
+ упп 150 т руб по минимуму

итого не бюджетно получиться

(16) а override как делать собираешься? без него ну никак иначе ерунда получится

(17) принцип не может стоит 500 тыр :-)
с солидворксом не путай

(18) сделать обработкой, а перегрузка в 1С встроена, тут же утиная типизация
криво, но как есть на текущей платформе

(18) мда... чтото немогу выкрутиться штатной 1ской...)))

Сколько таких тем, но ниразу никто так и не смог на примере рассказать нафига это в 1С. Ну кроме того что ООП это круто.

По факту теже спагети из вызовов, только вид сбоку

(20) что значит "перегрузка встроена" ? че то я недогоняю, пример покажи...

Разработчикам платформы некогда, они multitenancy делают:
http://v8.1c.ru/o7/201303mt/index.htm

.

Не можно и не нужно.

(22) +1

(0) Принципы могут и должны применяться. Но как и любая методика требуют обучения. А с этим плохо: в типовых еле-еле эти принципы взлетают, внятных статей/книг с примерами нет.

например, справочник "Внешние печатные формы и обработки"

не нужно. ООП в 1с зло

(30) рано или поздно будет

(31) ваши бы слова, да в 1С ))

(32) все к этому идет. смотри как развивается бсп

но не думаю что ООП добавит простоты доработки типовых. Это миф

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

не надоело ?

(35) +1

сейчас только в виде внешних DLL

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

(35) файловые базы в топку!

а есть еще шикарный  принцип wiki:KISS_(%EF%F0%E8%ED%F6%E8%EF)

(39) Хотите поговорить об этом?)

+ собственно сейчас самой главной проблемой БСП является отсутствие описанного и мало изменяемого интерфейса.

я-бы пошел следующим путем

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

далее за счет подчинении подсистем друг другу реализуем "наследственность",

пример
есть подситема "УправлениеПользователями", в ней есть процедура "УстановитьПараметрыСеанса", мне что-то нужно добавить, я делаю новую подсиненную подсистему "УправлениеПользователями_01" и в ней пишу
Процедура УстановитьПараметрыСеанса()
Родитель.УстановитьПараметрыСеанса();
// ----
мойПараметр = 1;
КонецПроцедуры

Все что я не описал берется автоматом из родителя.

---------------------------------------------------

что получим
1. БСП будет занимать корень подсистем и обновляется автоматом при "совместимости описанного интерфейса подсистемы"
2. пользователи могут переделывать или дополнять конкретные процедуры не коверкая БСП

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

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

(41)+ если господа из 1с читают - приглашайте на работу, готов реализовать (разумеется не как кодер а как идеолог)

:)

зы
в каждой шутке есть доля правды

(42) это СОВСЕМ НЕ ТО, ну нету там наследования!!!

(44) нафига в 1С наследование ?

(45) что бы тот-же рарус мог делать надстройки на БСП и прог уже дальше на рарус

представь подсистемы
УправлениеПользователями
____УправлениеПользователями_Рарус
________УправлениеПользователями_Омега

первые 2 обновляются каждая сама по себе,

(45) Да у кого-то тут коленка лишняя...

(46)  и смысл ?

какой нибудь более осмсленный пример есть ?

УправлениеКлиентами
____УправлениеКлиентами_CRM_Рарус
________УправлениеКлиентами_Омега

на верхнем уровне идет работа с регистром "Взаиморасчеты", и еще куча чего
Рарус добавляет работу с регистром сведений "Контакты" и добавляет в регистр "Взаиморасчеты" новый реквизит
Омега - конечная организация, хочет добавить реквизит в регистр "Контакты" а все остальное оставить.

рарус закрыл код!

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

(49) похоже на сказку..

рарус добавил новый реквизит в регистр
а все старые модули что на верхнем уровне работают по принципу "выгружу в тз, обработаю и загружу обратно"

и ?

(40) ну давай поговорим. Хотя слабо могу представить как kiss и 1с совмещаются.

ребята, хорош бздеть
ООП рулило и будет рулить

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

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

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

(49) Хорошо Омега добавила реквизит, завтра Рарус добавил еще один и так получилось что имена совпали, ведь Рарус же ничего не знает что там омега добавила. И что получится?

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


И так вариантов можно накидать вагон и маленькая тележка. 1С нитот продукт где имеем черный ящик на входе 2 параметра на выходи 3 значения. т.е. никто не гарантирует того что даже в типовой завтра не изменятся названия процедур и параметров. Даже от того что в регистрах 1С поменяет местами ресурс и измерения никто не застрахован. О какой модульности и ООП можно вести речь при таком подходе?

(55)
> привела астрономическому усложнению процесса поддержки и рефакторинга


Сам придумал?

(51) тут все представляют "просто" в 1С очень по-своему

(15) Консерватор :)

КГ/АМ :)

(15) А сейчас не так?
ctrl+c ctrl+v и добавляй/убавляй что хочешь в копии

(61) когда поменяют образец, цикл придётся повторить

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

(63) А где пример?

(62) А как иначе?
Если у тебя есть готовый объект, например, тот же ПКО. Ты в лучших традициях ООП создаешь его наследника Юзер_ПКО с добавлением пары реквизитов и изменением, допустим, модуля проведения. Затем поставщик удаляет из своего объекта или начинает по новому использовать некоторый реквизит, который был задействован в юзерской реализации проведения и привед. В любом случае придется переписывать свой объект под новую логику работы конфы поставщика

Мне только одного принципа из solid не хватает Буквы L.

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

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

Да какая нафик разница писать МойДокумент.ВыплнитьСуперДейсвие() или ВыполнитьСуперДействие(МойДокумент), есть общие модули и с их помощью можно на 90% заменить все эти мифические плюсы ООП. А то что тут просят у объектов, которые в таблицах бд хранятся наследников делать, так такого и вообще помоему нигде нет, даже в Hibernate это помоему не реализовали толком (хотя я давно уже с ней работал, может чего то всетаки и намутили жизнеспособного)

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

(68) Мы больше о функциональности которая дает(или не дает) ООП говорим, а не о хранении данных

(69) согласен

(69) Я считаю, что это может быть вполне закономерным этапом развития. А то свистелки и перделки в виде такси пилят и пилят, а над расширением функциональности системы не шибко работают.

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

(70) А какую реальную функциональность тебе может дать ООП?
Сделать ПлатежныйДокумент - наследник ПКО, РКО, Выписка: фик не получится! Потому что это должно отражаться в БД, а этого практически нереально сделать.
Все что можно сделать это для 8 написать аналог 1С++, на это собсно особо и фирма 1С не нужна, было бы желание а его видишьш ли ни у кого и нет, так как бонус это не особо большой даст.

(69) "Шуруп забитый молотком держиться крепче гвоздь закрученый отверткой" - в зависимости от задачи ООП становиться либо молотком, либо отверкой, либо плюшкой с повидлом. Да и, честно говоря, этих ООП как минимум два - то что было впихнуто Страуструпом в С++ и то что реализовано в MOP  в лиспе. И если второе действительно прекрасный лебедь, то первое - гадкий утенок котороен не спасают даже проповеди Александреску.

(73) Э... ты про кого сейчас говоришь, про либы которые используют проф.программисты в своей разработке, или всетаки про 1С которую бухгалтерша тетя Ася пользует тыркает просто кнопки и что там получится ей по большому счету китайская грамота?

(74) И почему же не получится? Можно поконкретней?

конкретный пример где можно было бы применить ООП в 1С

В типовых есть такой модуль "РаботаСоСтроками" - там всякая лабуда : разбиение строки по пробелам, каждое слово в строке первая буква в верхнем регистре.

вот этот модуль можно было бы убрать и все эти процедуры запихать в клас Строка.

что это дает: если нужно изменить поведение какой либо функции не нужно будет переписывать общий модуль и снимать его с поддержки

(77) не получится отвязаться от цепочки зависимостей разработчиков..

1С поменяет в объекте ихсодные данные
эти данные идут в ч0рный ящик раруса и там вываливаются с ошибкой.

и пока рарус не сделает обновлеиня учтя все изменения 1Са - следующий за рарусом разработчик не сможет обновиться.

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

и так по цепочке.


то есть сферическая мечта в вакууме "1С обновляется сама по себе не коцая наших доработок" - ООП тут не помошник..

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

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

(81) Дублирование одного и того же кода - это плохо, очень плохо. Вы наверное с таким не сталкивались

(81) И при добавлении новой функции в базовом модуле не забудь добавить её вызов в подчиненные модули, а если таких модулей с десяток, как и функций?

(67) не появится

(78) собственно сейчас так и делают - все доработки в своих модулях (даже проведение уносят  в подписки а процедуры выносят в модули)

причем в БСП для всех подсистем добавляют специальный модуль "____Переопределяемый" - куда вынесены вызовы нужных для функционирования подсистемы модулей..

то есть надо свои определения добавить в подсистему "ВариантыОтчетов" - в одном модуле который является связкой добавили вызовы своих процедур и функций и все...

надо в подсистему SMSоповещений добавить своего провайдера - то же самое..

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

(82) А кто тебе сказал про дублирование????
Ты же знаток ООП и про соответственно паттерны должен знать ну не на зубок но основные то точно. Тобишь такое наитиповейшее действие ты считаешь дублированием?

//Модуль РаботаСоСтроками

Функция ОченьВажнаяФункция(...)
....
Возврат результат;
КонецФункции

//Модуль МойРаботаСоСтроками

Функция ОченьВажнаяФункция(...)
Возврат РаботаСоСтроками.ОченьВажнаяФункция();
КонецФункции;

(69) У 1с нет базиса, т.е. неизменного модуля к которому ты прикрутил бы своё ООП. В качестве базиса в 1С выступает объект Документ/Справолчник/Регистр, со своим набором сво1йств.

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

(86)  Вот плюс стопитьсот за мысль.
(88) а когда появиться будет таже джава только на русском

(86)+ про упаковку (boxing) и распаковку (unboxing) вообще понять сложно, книжки читать бесполезно, только вербально

(78) Это и так есть, например модуль БСП, кому не нравится пишут свой пользовательский модуль который выполняет нужные функции, чем это отличается от твоего желания??

(86) вы так говорите про то что "большинство 1сников никаких языков кроме 1С не знают" как будто бы это плохо...

(87) То есть ты предлагаешь заглушки пихать кругом, куда ни попадя?

(80) Что мешает тебе сейчас в 1С это сделать?

(0) - ну вот зачем ты тут это запойстел?

Тут 90% людей не отличают класса от объектов, а ты им тут про принцип Лисков и инверсию зависимостей заливаешь?

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

(91) смотри (90) вот это работать не будет если я новый модуль забубеню

(95) пока по длинне писюна ты выигрываешь у левмихалыча и  AaNnDdRrEeYy...


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

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

(97) интересно, разработчики платформы знают про ООП ?

Так всё таки каким местом к 1с ООП приложить я так и не понял, тем более всё то о чём говорят те кто хочет ООП и так есть в 1С

(100) Ну мы же пользуемся типом "ДокументОбъект" значит да)

(101) продолжаем ждать внятного примера использования ООП в 1С :)

(87) тут нет наследования, тут явно нужно описать... а в идеи с подсистемами наследование реализовать можно.

можно и с общими модулями реализовать если у самого модуля ввести понятие Родитель и построить их в виде дерева

(100) если я добавлю новый модуль то я никогда не смогу сделать сокрытие методов базового класса и работать с разными объектами как с одним целым

класс Строка //это закрытый класс от 1С
{
    void какойтоМетод() // метод 1
}
класс мояСтрока:Стрка
{
  new void какойтоМетод() //метод 2
}

Строка массивУпакованныхСтрок = Новый Строка;

массивУпакованныхСтрок.Добавить(Новый Строка);
массивУпакованныхСтрок.Добавить(Новый мояСтрока);

массивУпакованныхСтрок[0].какойтоМетод(); // будет вызван метод 1
массивУпакованныхСтрок[1].какойтоМетод(); //будет вызван метод 2

(98) - какая длина писюна?

Нормальные программисты должны от корки до корки изучить:

Beck, Kent: Implementation Patterns

Patterns of Enterprise Application Architecture Фаулера

Dependency Injection in NET

и

Принципы, паттерны и методики гибкой разработки на языке C# Мартина

(103) см (29)

Это Аз, Буки и Веди современного ООП

(106) А почему именно в C#?

(106) Ты не умничай, а пальцем покажи

класс мояСтрока:Стрка
{
  new void какойтоМетод() //метод 2

}

Т.о. ты должен описать в твоем классе что ты используешь класс
new void какойтоМетод() //метод 2

Т.е. это и есть твоя заглушка

В рамках 1С, ты можешь или описать методы с возвратом, как было указано выше
или просто использовать вызов старого класса строка

(106) "нормальные программисты должны изучить.."  и далее идет:

"Принципы, паттерны и методики гибкой разработки на языке C# Мартина"


НА ХЕ РА ?
кто тебе эту чушь сказал?

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


смешно..

это типа как "настоящий водитель гоночного болида должен в совершенстве уметь подковывать лошадей и знать каким овсом их нужно кормить в какое время суток - ибо это основы основ"

(107) имелся в виду пример задачи нереализуемый в 1С сейчас без ООП :)

(111) - ты знаешь, там где я работаю, 1С нет, не было и в ближайшие 100 лет не будет.

Территориально и прочее.

То, что знание паттернов НУЖНО, я уже убедился на ЛИЧНОМ опыте.

Привет от Table Data Gateway/ Row Data Gateway.

Да.

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

(111) - ты разослал свой CV во все западные фирмы, но тебя там не взяли и ты пошел одинэсить?

Бедненький...

(106) Э.... А если я пишу драйвера или к примеру биосы разрабатываю, ну на худой конец просто с ардуином балуюсь на досуге я точно никакой не программист уже???
А еще я вот на яве балуюсь в свободное время "умный дом" себе тренирую, я тоже же совсем не программист получаюсь :(

(115) А нас и 1С неплохо кормит, зачем нам ваш загнивающий запад?

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

(117) - Запад гниет уже лет 300, да.

(110) нет, строка
new void какойтоМетод() //метод 2

значит что если объект принадлежит класу МояСтрока то будет вызвана реализация метода 2 если же объект принадлежит классу Строка то будет вызвана реализация метод 1. программа сама определяет какой метод вызывать и нет необходимости указывать это явно.

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

и еще он стоит на краю пропости

(120) А для этого и придумали переопределять поведение у классов потомков.

(120) Ты вообще сам то понимаешь что весь твой пример применительно к 1С в которая как мы всем помним НЕ ИМЕЕТ ЖЕСТКОЙ ТИПИЗАЦИИ это полная ... ну как бы это сказать... ну вообщем не имеет смысла.

(115) даже и мысли небыло..

западные фирмы сами приходят, просят 1С внедрить

и как то их отсутствие ООП не волнует ни разу :)

(123) Питон тоже не имеет жесткой типизации, тем не менее ООП в нем присутствует

(113) ну а там где я работаю ООП нет и небыл и не будет еще лет 100 ибо оно не нужно в принципе.. и что дальше?

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

ну какое к черту твой опыт тут в этой сфере имеет значение?
что то там было про чужие монастыри и уставы - слышал вроде бы, не ?

(125) - а также Ruby, PHP, Perl и много чего еще

(123)+
СписокДокументов = Новый СписокЗначений;
СписокДокументов.Добавить(Док1);
СписокДокументов.Добавить(Док2);
Для Каждого Док Из СписокДокументов Цикл
   Сообщить(Док.Печать());
КонецЦикла;    

Будет вызвана именно его функция печати, а все в списки типа "Документ"

(125) Ну и в чем тогда вообще смысл примера из (105)?
Для каждого тамошниго объекта будет вызвана именно его функция, в "якобы наследованном" можно написать свою реализацию а не возвращать "родительскую", что тут конкретно "невозможно" сейчас в 1С?

(126) - т.е. зачем в чужой монастырь (SOLID, ID/IoC, MVP, MVC, Unit Of Work) приходить какой то утилитарной утилитке из бывшего СССР для складского учета в ларьках?

ID/IoC -> DI/IoC

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

(123) в лиспе тоже нет жесткой типизации, но - внезапно - есть ООП.

(130)  ага.. аргументы кончились :)
понятно..

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

понятно.. продолжайте читать свои библии разработки в сишарпах

(129) Здесь больше все таки пожелание к возможности создания своих расширяемых типов, а не все в ООП

(135) Собсно объект помимо методов еще хранит и данные, чего общие модули сделать например не смогут

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

(137) Ну я бы не стал так утрировать

(137) ну да..

об этом то я и пытаюсь объяснить: когда задача состоит в том что надо почесать нос - примитивно и ногтем, не надо для этого 6 лет учиться в медвузе а затем ложитья на операцию по пересадке сердца.

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

(137) Как бы да 99,9% здешние 1С-ников - это именно настройщики к типовой, которым ООП и даром не упёрлось

(136) "Хранить данные" где? Если просто временные то пожалуйста ваяй обработки и используй их типа "объекты", если хранить в БД, то еще раз - фактически нереально!
Слишком большая вероятность коллизий особенно в узкоспециализированном спектре (1С это же финансовая программа - спектр применения очень небольшой). Есть огромная вероятность что в каком-нибуть потомке добавят поле ЦенаОсобая к примеру, а через н-ое количество времени решат добавить такое поле в родителе, как такое разруливать? Еще тот геморой с возожными фантазиями каждого "наследователя" на индексы и т.д. и т.п.

(128) если Док2 и Док1 одного типа то будет вызвана одна и та же реализации "функции" печати, а не для каждого своя.
если типы у док1 и Док2 разные то для каждого типа должна быть своя функция печати что ведет к дублированию кода, и без невозможности применения интерфейсов остается только гадать есть ли у док1 метод печать() так же как и у док2 или ее просто нет.

Писатели нетленок тоже не понимают зачем им это ООП, они и без неё прекрасно живут

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

(139) - только вот в западных ERP (взять хотя бы Dynamics) системах все это есть.

Может быть фирма 1С ориентировалась на примитивизм и ужасное айти образование российских как бэ "программистов" настройщиков 1С, 70% которых просто "с голодухе" пошло в сабж

(142) Так и в ООП в этом не поможет

(140) Нимб не жмет? В учебных заведениях не проходили что утрированные утверждения никто,никогда,всегда и подобные абсолютный признак просто не знания реальных данных?

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

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

(141) Чтобы знать как такое разруливать -нужно покодить используя ООП, тогда его плюсы и минусы и станут очевидны. 1С итак объектна ориентированная система, проблема лишь в том что этим мы управлять не можем, у нас есть песочница с опр. набором объетов, с которыми мы балуемся. Может оно и к лучшему..

(146) А где я писал что никто и никогда?

(144) я правильно понимаю что если успешный и богатый Васисуалий Какакьевич - гей и епется в 0пу то ты бездумно переймешь его опыт и переквалифицируешся в геи?

ибо у успешных людей ТАМ так принято и проследывается связь: "Васисуалий успешен и он дает в 0пу" да ?

(142) Если у тебя нет жесткой типизации (в 1С ее же нет, мы знаем) то какая разница что именно будет в списке, до момента исполнения ты всеравно не будешь знать что там, может там и документ а может там и просто строка, так что ошибки вероятны в любом случае с ООП или без.

мой любимый пример из типовой 1С БП 2.0:

Если ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НаАванс
           ИЛИ ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НаАвансКомитента
           ИЛИ ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НаСуммовуюРазницу Тогда
           ДанныеДляПечати    = СобратьДанныеСФнаАвансИСуммовуюРазницу(ТекущееОснование);
       ИначеЕсли ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НалоговыйАгент Тогда
           ДанныеДляПечати    = СобратьДанныеСФНалоговыйАгент(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОтчетКомитентуОПродажах") Тогда
           ДанныеДляПечати    = СобратьДанныеПоОтчетКомитенту(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияТоваровУслуг") Тогда
           ДанныеДляПечати    = СобратьДанныеПоРеализацияТоваровУслуг(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияОтгруженныхТоваров") И ТипЗнч(ТекущееОснование.ДокументОтгрузки) = Тип("ДокументСсылка.РеализацияТоваровУслуг") Тогда
           ДанныеДляПечати    = СобратьДанныеПоРеализацияТоваровУслуг(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияОтгруженныхТоваров") И ТипЗнч(ТекущееОснование.ДокументОтгрузки) = Тип("ДокументСсылка.ПередачаОС") Тогда
           ДанныеДляПечати    = СобратьДанныеПоПередачеОС(ТекущееОснование.ДокументОтгрузки);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ВозвратТоваровПоставщику") Тогда
           ДанныеДляПечати    = СобратьДанныеПоВозвратТоваровПоставщику(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОтчетКомиссионераОПродажах") Тогда
           ДанныеДляПечати    = СобратьДанныеПоОтчетКомиссионераОПродажах(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.АктОбОказанииПроизводственныхУслуг") Тогда
           ДанныеДляПечати    = СобратьДанныеПоАкту(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ПередачаОС") Тогда
           ДанныеДляПечати    = СобратьДанныеПоПередачеОС(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ПередачаНМА") Тогда
           ДанныеДляПечати    = СобратьДанныеПоПередачеНМАОрганизаций(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОтражениеНачисленияНДС") Тогда
           ДанныеДляПечати    = СобратьДанныеПоОтражениеНачисленияНДС(ТекущееОснование);        
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияУслугПоПереработке") Тогда
           ДанныеДляПечати    = СобратьДанныеПоРеализацияУслугПоПереработке(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.НачислениеНДСпоСМРхозспособом") Тогда
           ДанныеДляПечати    = СобратьДанныеПоНачислениеНДСпоСМРхозспособом(ТекущееОснование);
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОказаниеУслуг") Тогда
           ДанныеДляПечати    = СобратьДанныеПоОказаниюУслуг(ТекущееОснование, "Контрагенты");
       ИначеЕсли ТипОснования = Тип("ДокументСсылка.КорректировкаРеализации") Тогда
           ДанныеДляПечати = ПолучитьДанныеДляПечатиИсправленияСчетаФактуры(ТекущееОснование);
       КонецЕсли;

(152) Да, обожаю это!

(152) который уже обсуждали и пришли к выводу что ООП здесь не поможет

(136) >>> Собсно объект помимо методов еще хранит и данные, чего общие модули сделать например не смогут


общие модули - не смогут!

а вот подсистемы - смогут!

А должно было как быть?
20 классов ДанныеДляПечати, каждый с методом СобратьДанные?

(155) Это чем подсистемы смогут?

(152) и что этот пример показывает?

(156) Каждый документ реализует свой метод, который на выходе выдает данные для печати

(149) ну как же ты написал 99.9% учитывая что сейчас на форуме 1729 человек то не "настройщики к типовой" это 1.749 человека, тобишь ты еще кто-то чуть больше половины :)

(156) Нет должно быть один СобратьДанные в которое тупо скопипастит этот кусок кода

(159) В 1с такое легко можно

(160) Он чуть-чуть подрабатывает "настройщики к типовой"

(151) согласен, проблема в строгой типизации.
класс - это тип. нет типов - нет классов, нет классов нет ООП.

(154) поможет, поможет ))

(160) я настройщик

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

(158) слабость мысли разработчиков

(164) ООП это подход к проектированию и реализации приложения, типизация тут не причем.

(162) Вот текст из БП 3.0



   ДанныеДляПечати = Новый Структура;
   
   ВалютаРеглУчета = ОбщегоНазначенияБПВызовСервераПовтИсп.ПолучитьВалютуРегламентированногоУчета();
   
   Запрос = Новый Запрос;
   Запрос.УстановитьПараметр("ВалютаРеглУчета",                    ВалютаРеглУчета);
   Запрос.УстановитьПараметр("ДокументОснование",                    ДокументОснование);
   Запрос.УстановитьПараметр("СчетФактура",                        СчетФактура);
   Запрос.УстановитьПараметр("ВидСчетаФактуры",                    ВидСчетаФактуры);
   Запрос.УстановитьПараметр("ИспользуетсяПостановлениеНДС1137",    ИспользуетсяПостановлениеНДС1137);
   Запрос.УстановитьПараметр("ПустоеПодразделение",                БухгалтерскийУчетПереопределяемый.ПустоеПодразделение());
   
   Запрос.УстановитьПараметр("ТекстБезАкциза",                        ?(ИспользуетсяПостановлениеНДС1137, НСтр("ru = 'без акциза'"), ""));
   Запрос.УстановитьПараметр("ТекстКомиссионноеВознаграждение",    НСтр("ru = 'Комиссионное вознаграждение'"));

   НомераТаблиц = Новый Структура;

   Запрос.Текст = Документы[ДокументОснование.Метаданные().Имя].ТекстЗапросаДанныеДляПечатиСчетовФактур(НомераТаблиц)
       + ТекстЗапросаДанныеДляПечатиСчетовФактур(НомераТаблиц);


(168) слабость или лень?

(170) И что из него следует?

(171) вряд ли лень, им потом его сопровождать

(172)
Документы[ДокументОснование.Метаданные().Имя].ТекстЗапросаДанныеДляПечатиСчетовФактур(НомераТаблиц)

(152)

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

попытка
Модуль = ТекущееОснование.Метаданные.Вид();
ДанныеДляПечати = Документ[модуль].СобратьДанныеДляПечати(ТекущееОснование);
исключение
ДанныеДляПечати = СобратьДанныеДляПечати(ТекущееОснование);
конецпопытки.

Как вы и хотели
>>Каждый документ реализует свой метод, который на выходе выдает данные для печати

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

(175) давно уже делают. Хватит сидеть на бухе 1.6

(178) я не сижу я уже третий год на 2.0 и пол года на 3.0

(164) отсутствие типизации не говорит об отсутствии типов

(175) Я просто не помню, но разве БП2 вышла после 8.2?
Вроде только в 8.2 появились модули у менеджеров, так что вполне может быть что это просто кусок унаследованного кода.

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

+(182) получается набор велокатов фиксина, из которого в разные стороны торчат костыли и внезапные штуки...

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

ИХМО - если такое сделают - то 1с будет реально крут в плане допилки типовых.

(184) В аксапте такое с помощью слоев решается

(185) в аксапте и классы в чистом виде есть

Вы еще 3д графику предложите моделировать.

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

(187) это ты к чему?
(188) а там останется типовое "Счет", но вот заполнять туда будут "СчетОмега"

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

Ни разу не видел ни одной удачной идеи про объекты унаследованные от 1сных документов.
Всякие СчетаОмеги и ПлатежныеДокументы - полная лабуда

(190) и даже в какой-то степени инкапсуляции (если смотреть на нее шире): от регистра скрывается истинный тип

(177) вот как ты заставишь все документы в 1С иметь метод Печать()?
конечно можно перед вызовом проверять если этот метод или нет, тупо выполняя его в отладчике, но это все криво и некрасиво - красиво это когда идет реализация интерфейса именно того интерфейса который ты сам спроектировал.
трудно решаемые задачи в 1С - это красота и минималистичность кода, это вечный копипаст кода в разных модулях, это простыни кода с условиями Если. Вот от этого уйти реально трудно.

(191) ты возможно просто мало видел

(192) ну, может и да, но ИМХО регистр коду-то не потребитель. В этом польза от того, что мы в документ.Счет можем явно указать, какие методы public, то есть могут быть переопределены потребителем, а какие - private, то есть являются реализацией, не подлежащей изменению.

(194) потребителем будет что-то, что юзает этот регистр
от него скрывается истинный тип
но это уже философия

(193) Ну вот еще где то в самом начале я писал, какая разница писать Документ.Печать() или Печать(Документ), ну где полет фантазии:
//Мой супер общий модуль
Процедура Печать(Документ)
//Проверяем что это действительно документ и у него есть экспортная печать если нет то выходим
Документ.Печать();
КонецПроцедуры

(194) может в недрах у кого то и скрывается удачный пример, но в форумных баталиях его еще никто не предъявил

(193) ну тогда и от пустых значений надо защищаться

(196)И так тоже делают, есть и такой паттерн

(197) про объекты, унаследованные от 1Сных документов, может его и не будет, но про пользу от наследования в 1С в целом уже продемонстрировали в (193)

(200) вот именно что польза в целом, а в примерах ничего

(193) Стесняюсь спросить, а ты сам много писал с использованием ООП, реальных задач имею ввиду а не хелловордов?
Ты как бы про отладку функционального кода и ООПшного мне не рассказывай красивых сказок, когда тут все фунцкии/процедуры под рукой и везде можно залезть, или когда начинаешь скакать через 1-5-10 и более наследований и искать где там что не так сработало и вдруг упереться на 5-ом зарывании что а блин от этой либы у меня исходников то и нет. И я даже сейчас вижу как прошел путь от МойФранч-ФранчМоегоФранча-Рарус, блин а на рарусе то уже закрыто.

(198) пустое значение - это базовый класс,

базовый класс это "Документы" в нем имеем динамические процедуры "ПриЗаписи" и т.д.
Документы.Счет - в нем переопределяем процедуры базового класса.

(201) я уже писал, что для целей сопровождения готового ни чего не нужно. Даже мозги не  нужны

(202) А ты думаешь так по функциям общих модулей не попрыгаешь? Те же яйца, только в профиль

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

(202) с помощю поставки без исходных кодов и кривых рук в 1С можно добавиться того же самого

Кажется мне что будет так, как фирма 1С решит. Решит, что будет ООП, все дружно скажут okay и будут обучаться работе с ООП, с УФ научились работать же

(208) думаешь много народу научилось УФ работать?

я например имею опыт почти 2 года УФ но весьма слаб в этом, и разработчики типовых - то же нифига не шарят в УФ.

Я понимаю плюсы УФ, но не видел ни одной хорошей реализации этих плюсов, везде есть сильные недочеты

(209) какие недочеты например?

(209)+ ООП с управляемыми формами - вот это будет мега круто :)

(204)(205) Так я и говорю что просто добавление ООП не даст никакой "красоты и минималистичность" коду, вот хоть тресни абсолютно не даст. НИЧЕГО не добавит ООП в 1С кроме того что некоторые закомплексованные будут гордо говорить ну теперь то мы точно настоящие программисты.

(210) например количество передачи управления между клиент и сервер просто зашкаливает.

(211) Ага уже полет фантазии зашкаливает - ФормаДокумента, ФормаДокументаДляМариИвановны,ФормаДокументаДляМариИвановныСГалочкой,ФормаДокументаДляМариИвановныСГалочкойИФлажком, чеж их не лепить, все же просто :)

(202) стратежку на xna типо варкрафт писал- в образовательных целях. виртуальную файловую систему- все данные в одном файле. что то типо библиотеки system.IO. это из крупных где больше одной сборки.
И не было с отладкой никогда никаких проблем, пишешь класс тестируешь и не трогаешь его больше, и не нужно лесть в исходники потому что пофиг как это реализовано главное что выполняет то что нужно, не устраивает наследуешся и меняешь если потом не работает так точно знаешь где искать в наследнике! никогда нельзя трогать то что уже отлажено и работает, следовательно зачем тогда исходники.

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

(212) Ага, пару месяцев поговорят закомплексованные, что они тру-программисты, но найдется пара человек и вгонит их в уныние словом "хаскель".

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

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

(200) бред, а не пример. Скажем так. Как ты при ООП будешь гарантировать метод печать у ВСЕХ документов? правильно прописывая у базовой структуры этот метод. При этом в базовой структуре эта тупо заглушка возвращающая пустую печатную форму, а уж при наследовании ты должен переписать этот метод на твою печать

Ну и четь это так принципиально будет отличаться от

Попытка
Документ.Печать()
Исключение
ПустаяПечатнаяФорма()
КонецПопытки

Или если тебе так не нравится сделай в общем модуле процедуру НапечататьДокумент с этим кодом и вызывай не через
документ.Печать(), а через НапечататьДокумент (Документ)


Т.е. на вызоде теже яйца только сбоку, никакого ни плюса ни минуса

(220) Про интерфейсы не слышали?

(220) Ну или чистые виртуальные функции

(220) Определяешь интерфейс IPrintable, документы его реализовывают. В цикл перед вызовом метода печать проверяешь, что документ реализует этот интерфейс...

(222) Вот опять двадцать пять :)
Ну какие интерфейсы в 1С? Ну нет тут проверки типов, ну ни о чем твой интерфейс не скажет 1С-ной виртуальной машине :)

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

Пример, УТ11. Что в начале говорили? Хрен вам а не договора и не партии. И что сейчас?

Т.е. на выходе мы будем иметь или монстра под 2 гига, зато наследование будет. Или каждый раз в хлам переписанный базис

В рамках 1С я за второе

(224) Так я его и определяю в глобальном модуле. Хорошо назову его не НапечататьДокумент , а IPrintable и получу тоже самое

(225) Та шо вы гаварите? Объясните мне пожалуйста, как это нету проверки типов? То что тип назначается динамически, еще не значит что при вызове методов он не проверяется

(223) чем это будет отличаться от реальной функции в общем модуле?

(227) фишка в том что 1С никогда не будет труъ-языком программирования пока 1Сники кодят на б-гомерзком русском...

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

(231) Т.е. получается 1С круче, ибо нет этого ограничения?

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

(232) Тогда по вашей логике ассемблер еще круче, у него вообще никаких ограничений

(233) А функциональность этих самых новых объектов ты за счет чего будешь реализовывать? за счет языка программирования 1С? Тебе и сейчас никто не мешает запилит внешнюю компоненту, с какой угодно функциональностью

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

(226) балин!!! ну не надо смотреть так как будто типовая будет в одном классе!

посмотрите как наследуется в ООП

object >>> ...... >>> CustomForms >>> forms >>> muForms

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

Ихмо сейчас этот монстр уже вырвался из под управления и в ближайшее время мы будем иметь кучу дублей кода в БСП

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

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

(238)>>потому что коллекция этих документов всеравно никак не контролирует что в нее добавляют

сделай свою коллекцию и контролируй добавление в нее.

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

(240) Ну так что мешает тогда реализовать коллекцию с контролем фукции сразу?

(239) простое добавление функций ООП без полного переписывания БСП - пустая трата времени, а БСП переделывать - ну ты понимаешь :)

(238) Так а почему вы решили, что ООП это аналог кнопки для бухов "Сделать хорошо и закрыть"? ООП - это концепция, а не средство исправления ошибок из-за кривых рук.

Ого набросали. все не читал, примеры более эффективной реализации задач с помощью ооп на 1с были?

(245) Так а как их без конфигуратора 1С сделаешь-то?)

(246) я имею ввиду, что сейчас в 1с есть такого что можно было бы сделать более эффективно, если бы фирма 1с сбацала классы?

(245) мне вот это пример понравился
http://habrahabr.ru/post/148015/
особенно то что под "Резюмируя" написано.

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

(249) Ни разу не видел узкой специализации в языках типа C++, Java и тп. Да и 1с, я думаю написан не с использованием процедурной методологии. Вот хотелось бы услышать, чем оно избыточно и вредно?

(250) Узкая специализация имеется ввиду конкретно 1С, это предметно-ориентированная среда, созданная для решения конкретной задачи - автоматизации предприятия. Избыточность и вредность будет в том что действительно станут появляться Документ1, Документ1СГалочкой, Документ1СГалочкойИФлажком. От этого никуда не уйти. А позже начнутся стоны да ваша 1С полное ...

(251) это называется паттерн стратегия

Мое мнение заключается в том, что нужно сделать не сами объекты метаданных расширяемыми и наследуемыми, а сделать именно встроенный язык 1с, полноценным ооп-языком, Для меня часто не хватает какого-то репозитория объектов, которые в т.ч могли бы создавать и оперировать с произвольными структурами данных. И которым могли бы пользоваться другие программисты. Подобное уже давно существует в том же сапе и аксапте.

(248)

1. Наследование. Есть перационист. Его задача отражать события в базе. Есть документ ПКО, есть снятие резерва. Ваша задача смоделировать процесс отражения хозяйственных операций в учёте. Решая задачу в лоб, у нас будет много дублирования кода из-за того, что сам процесс формирования автонумерация документа, структура подчинености и т.п. идентичны для обеих документов. Но если мы включаем объектное мышление, и вспоминаем про инструмент наследование, то получаем примерно следующее (диаграмму лень рисовать, сорри):
Есть документ (абстрактный документ). У нее есть поведение сформировать движение, номер документа, и состояние — проведен, помечен на удаления. Это отличный пример абстрактного объекта в котором соблюдены принципы инкапсуляции (при реализации я их обязательно буду соблюдать). И есть Оператор, конкретный такой Оператор Иван. Он умеет работать с абстрактным документом. Т.е. смотреть статус создавать, проводить и т.д. вы поняли. Сила наследования в том, что нам не придется переписывать нашего Ивана для каждой из документа, будь то ПКО или снятие резерва. Я думаю всем ясно почему? Получается что инструмент применен правильно.

2. Полиморфизм. Документ ведб по разному работает. У ПКО нет табличной части, у снятия есть. Используя полиморфизм мы легко меняем поведение в наследниках абстрактного документа.

3. Инкапсуляция. Основная фишка инкапсуляции в том, что я не должен знать, что происходит внутри моего документа. Допустим, я вызываю не метод записать движения в таблицу RG2548, а просто пишу провести(). Что произойдет в этот момент? Если принцип инкапсуляции не соблюден, то я буду вынужден печи сказать в какую таблицу и что я должен писать. Если не соблюдать принцип инкапсуляции, то мы должны будем говорить печи проверь-ка текущий статус, можно ли формировать движения при текущем статусе....

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


Т.е. у 1С есть ООП. И точка

(254) Я еще раньше об этом сказал, вопрос в том, что сам язык не позволяет создавть и расширять свои типы данных

(253) Пример. А то опять опять получается 1с авно потому что не умеет варить кофе

(254)да есть наследование и есть классы, но все они sealed т.е все приплыли они запечатанные. толку то от этого?

(257) А что при ООП я могу менять базовые классы???

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

(258) Не можешь, хошь поменять - отнаследуй и меняй на здоровье

(260) причем тут наследования речь то "все они sealed т.е все приплыли они запечатанные. толку то от этого?"

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

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

Чем это отличается от вашего толкования ООП?

(261) sealed, запечатанный, герметизированный - означент что класс конечный и не может выступать в качестве базового, т.е бездетный.

(264) Эээ а как тогда у меня получается документ. ПКО который наследует все свойства и поведения класса документ?? Хочешь сказать меня глючит и такого нельзя в 1С сделать?

(263) Это не метод, а событие, подписавшись на которое ты можешь провести какие-либо действия при проведении

(265) ты троллишь? а теперь от ПКО что нить отнаследуй!

(266) ОбработкаПроведения можно считать virtual protected методом

(265) Взять учебник по C# например, главу по классы и объекты - проработать, потом вопросы задавать

(267) немного.

Легко. Например создам класс ПечатьДокумента, который отнаследует метод Печать у документа ПКО

(270) а теперь своего "наследника" запихни в типизированный реквизит обработки с типом "ДокументОбъект.ПКО"

(270)показывай

(272) 8======================>

(271) А это зачем?

Или ка в анедоте про бензопилу?

(271)(272) сейчас будет что то типо второго документа который будет иметь свою печать() и в ней вызывать печать() ПКО, типо врапер такой

(273)что это? ... твой код показывающий все возможности ООП в 1С ... в части наследования

Не думаю что ООП даст большие преференции. А вот частичная типизация, Linq могли бы упростить кучу кода.

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

(277) я же настройщик, я кода не знаю, ваших ООП в институтах не проходил

(279) :)

(278) регулярки бы еще, в полнотекстовый поиск например

278 + ООП и так многие не сильно то и понимают, впрочем как и Linq но хотя я и сам 2 руками за ООП, для 1С лучше развивать ФП

(283) в любом случае все это ФП построенно на использовании объектов и их методов, так что ООП - вполне логичное продолжение.

Да и не функциональное, а процедурное. Функциональное это немного другое

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

(265) Linq это функциональное программирование

287->285

(288) linq - частный случай ФП)

Что приниципиально иного дает ООП в контексте 1С?
Ничего! У всего, в том числе у ООП есть своя цель. Сам по себе метод целью может быть только у эстетов, ну вы поняли...

(290) >>у ООП есть своя цел
вот и развернул бы тему

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

+ (292) ну и надеюсь ума хватит, чтоб спроецировать цели и задачи ООП на 1сную действительность и понять, что здесь ООП не нужно.

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

(294) гы-гы... а у вас действительно комплексы :)

(292)читал, ты сливаешь

(296) ? отсутствие у кого-то ума для того, чтоб понять прочитанное, не заставит меня слиться ;)

(295) не комплексы а реальный взгляд на суровую действительность.

проголосовать забыл

триста!

(298) суровая действительность в том, что у людей есть комплексы и некоторые их не стесняясь демонстрируют :)

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

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

(294) Уже три года не помню задач, которые решаются за полчаса, или это мне так везет...

(287) Но не процедурное же. Используется чистый ФП подход с замыканиями.
(294) На некоторые задачи уходят намного больше времени.
(304) Значит задачи у тебя такие.

Подброшу дров
http://blogerator.ru/page/oop_why-objects-have-failed

(306) баян

(307) Ну дык, все равно, не нужно крутость ООП возводить в аксиому и  пихать везде, где можно. Что ж тогда в автокаде лисп используется?

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

(306) не нужно все возводить в Абсолют

(309) Никто и не возводит. Абсолют же не имеет границ, а в данном случае границы применимости и оптимальности. Так вот в концепции в 1С применимость ООП (не путайте с тем, что предлагали использовать БСП и общие модули - это мимикрия) = 0, оптимальность = 0. Так что... проголосую.

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

(311) В 1С есть вычислить и выполнить

Самая страшная беда 1с - отсутствие интерфейсов к уже отлаженным блокам кода.

(312) а, да - точно. Есть. Только это отдельно от 1с и со своими ограничениями. И текст передаваемый туда - не компилируется, а исполняется - это как бы 2 большие разницы.
(313) Код не бывает отлаженым. Он может быть корректными или нет. Для контроля корректности кода есть стопятьсот методов проверки. И интерфейсы  никакого отношения к этому не имеют.

(306) - ты сидишь сейчас в ОС и пользуешься программами, которые используют ООП.

(314) Например в C# есть T4. Внутри 1С кодогенерация идет для выполнения SQL запросов и прочее. Да и самому часто приходится лепить текст запроса собирая его на основе метаданных. Иногда и тексты модулей например для конвертации данных из одной конфигурации в другую на основе объектов XDTO

(315) А также сижу и в 1С, где использую кашу из всяких других методов (процедурное программирование, к примеру).
Еще раз. ООП сам по себе неплох, но у него есть границы применимости.

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

(318) Говорят вот этот язык специально заточен для распределенных вычислений - и это не ООП
wiki:Erlang.

(318)
"например одну и туже функцию надо запустить с разными параметрами в разных потоках?"
ну как бы просто запускаешь и всё. чего тут тёмного?
поток не может существовать без функции, а объекты типа thread это обертки для этой самой функции потока. у потока есть свой собственный стек и у каждой функции потока свои локальные переменные. и параметры передавай в функцию потока какие вздумается. это я так, для общего ликбеза.

+(318) и на "чистопородистом С" никто не мешает писать программы в стиле ООП (например GTK+). Потому что ООП это парадигма, а не языки программирования.
Вы чего молчите вообще? Тему про ООП надо растягивать до 1000 постов. Такова традиция.

(321) Да а что тут растягивать, большая часть задает такие вопросы, которые люди работавшие с ООП, обычно не задают. В результате обсуждение скатывается в обсуждение, а так можно в ООП или нельзя или "А это че вообще такое"? Я свою точку зрения выразил давно. Хотелось бы язык позволяющий создавать свои типы данных с поддержкой ООП-парадигмы. И еще адекватную обработку исключений

(318) ООП для 1с имеет смысл как расширение языка.

Объясню:

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

В объект ООП можно и нужно поместить проведение документа, но форму и ее реакцию - это большой вопрос...

Вот какие границы применения ООП я себе вижу....

А мне глубоко наплювать, что в 1с нету ООП. В 1с я о нём не вспоминаю никогда. Что бог дал - на том и зарабатываем.

начал систематизоровать свое отношение к 1с в целом как к системе, в том числе и в разрезе ООП

http://infostart.ru/public/190375/

(326) На 101% согласен с первой частью. Файл-серверная архитектура при многопользовательском доступе - зло.