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

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

(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% согласен с первой частью. Файл-серверная архитектура при многопользовательском доступе - зло.