Возникла задача в которой было необходимо работать с объектами (не объекты метаданных) у которых есть множество одинаковых свойств и методов, но есть и свои специфические как свойства так и методы. Самым простым способом решения является ООП, но в 1С нет возможности работать с классами, инкапсуляцией, наследованием, полиморфизмом и так далее. Прочитал немногочисленные заметки и зарисовки, которые есть на этом сайте о том как предлагают реализовать подобные решения, но везде были свои «НО». Многие пишут, что не видят в ООП для 1С необходимости — это их дело, хотя и неосознанно они работают в «lite» версии ООП. Недостатки есть и в этой методике, которую хотелось предложить на Ваше обсуждение.
Для начала нам необходимо объединить данные и методы, этот процесс называется инкапсуляцией. Давайте посмотрим на текст следующего общего модуля:
Общий модуль «Класс_ФизическоеЛицо»
Функция Конструктор() Экспорт
МойОбъект = Новый Структура("Фамилия, Имя, _Пол", "", "", "");
МойОбъект.Вставить("ф", ЭтотОбъект);
Возврат МойОбъект;
КонецФункции
Функция Обращение(МойОбъект) Экспорт
Возврат МойОбъект.Фамилия+", "+МойОбъект.Имя;
КонецФункции
Функция Пол(МойОбъект, Пол="") Экспорт
Если НЕ ПустаяСтрока(Пол) Тогда
МойОбъект._Пол = Пол;
КонецЕсли;
Возврат МойОбъект._Пол;
КонецФункции
Здесь видно, что в качестве рабочей лошадки используется «Структура», хотя на ее место вполне подходит и «Соответствие». Первый недостаток заключается в том, что для вызова метода объекта необходимо использовать какое либо имя свойства для определения ссылки на модуль. Я для себя определил этим ключевым словом букву «ф». Но, методы и свойства чудесным образом объединились и теперь находятся в одной структуре (объекте) ссылку на который можно передавать и использовать почти в любом месте. Второй недостаток заключается в том, что контекст структуры не передается при вызове метода из этой структуры. Следовательно, необходимо первым параметром передать саму структуру. По этому все методы которые работают с данными объекта первым параметром получают саму структуру. Этот параметр я назвал «МойОбъект» (ну просто по тому что ключевое слово «ЭтотОбъект» занято). Третий недостаток заключается в том, что нет возможности сделать скрытыми свойства. Для себя я определил, что скрытыми будут те свойства, которые начинаются с символа «_» (подчеркивание) или их можно перенести в отдельное свойство (например, с именем «Скрытые»), состоящее из структуры только скрытых свойств. Что касается методов, то тут ситуация не такая однозначная. Ведь если процедуре или функции модуля не установить ключевое слово «Экспорт» то она будет недоступна из внешнего модуля, но она не будет доступна и для наследника. По этому если Вам необходимо использовать скрытый метод у наследников начинайте его так же как и скрытые свойства со знака «_» подчеркивания.
И так с инкапсуляцией мы разобрались. Теперь нам нужно решить вопрос с самым главным – наследованием. Смотрим следующий текст модуля:
Общий модуль «Класс_Сотрудник»
Функция КлассРодитель()
Возврат Класс_ФизическоеЛицо.ЭтотОбъект;
КонецФункции
Функция Конструктор() Экспорт
МойОбъект = КлассРодитель().Конструктор(); // Родительский конструктор
МойОбъект.Вставить("Должность", ""); // Добавляем новое свойство
МойОбъект.Вставить("ф", ЭтотОбъект); // Заменяем модуль набора методов
Возврат МойОбъект;
КонецФункции
Функция ОбращениеПоШтатке(МойОбъект) Экспорт // Новый метод этого класса
Возврат МойОбъект.Должность+" - "+МойОбъект.Ф.Обращение(МойОбъект);
КонецФункции
Функция Пол(МойОбъект, Пол=Неопределено) Экспорт // Модифицированный метод
Если (Пол<>Неопределено) и (НЕ (Пол="М" или Пол="Ж")) Тогда
Сообщить("Недопустимое значение при установке пола сотрудника!");
Возврат Неопределено;
КонецЕсли;
Возврат КлассРодитель().Пол(МойОбъект, Пол); // Вызываем родительский метод
КонецФункции
Функция Обращение(МойОбъект) Экспорт // Наследованный метод
Возврат КлассРодитель().СтрокаФИО(МойОбъект);
КонецФункции
Обратите внимание — каждый класс располагается в отдельном общем модуле. Теперь давайте смотреть, что у нас получилось. Конструктор вызывает родительский конструктор и получает от него все свойства, которые были определены в родительском классе, а если он вызывает своего родителя мы получим и свойства прародителя.. Четвертым недостатком является то, что если вы полностью переопределяете конструктор дочернего класса, то вы должны самостоятельно позаботиться о создании всех свойств, которые создаются родительским конструктором. Пятым недостатком и на мой взгляд самым существенным является то, что ВСЕ методы которые использует потомок необходимо объявлять в модуле потомка (в примере это функция «Обращение»). Небольшой ложкой меда здесь служит то, что при последующем или повторном наследовании эти методы можно перенести потомку простым копированием. Этот же недостаток заставляет отслеживать самостоятельно создание новых методов и копирование кода наследования в дочерние классы.
—
Но в результате мы получили объектный полиморфизм.
Давайте посмотрим, как будут работать наши классы в прикладном решении:
—
Использование в прикладном решении:
Сотрудник = Класс_Сотрудник.Конструктор();
Сотрудник.Фамилия = "Иванов";
Сотрудник.Имя = "Иван";
Сотрудник.Должность = "Программист 1С";
Клиент = Класс_ФизическоеЛицо.Конструктор();
Клиент.Фамилия = "Петров";
Клиент.Имя = "Петр";
Сообщить(Сотрудник.ф.Обращение(Сотрудник)); // Иванов, Иван
Сообщить(Клиент.ф.Обращение(Клиент)); // Петров, Петр
Сообщить(Сотрудник.ф.ОбращениеПоШтатке(Сотрудник)); // Программист 1С - Иванов, Иван
Сотрудник.ф.Пол(Сотрудник, "Н"); // Недопустимое значение при установке пола сотрудника!
Сотрудник.ф.Пол(Сотрудник, "М");
Сообщить(Сотрудник.ф.Пол(Сотрудник)); // М
Как видно из примера финальный код почти похож на стандартный ОПП (за исключением буквы «ф» перед методом и передачей самого объекта в качестве первого параметра) и такой подход можно смело назвать Подобием Объектно Ориентированного Программирования в 1С (ПООПс)
Если для Вашей задачи описанные недостатки будут малозначимыми, то вполне можно использовать такой подход для ее решения.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Подписался
А что произойдет при передаче такого «объекта» с клиента на сервер и обратно?
(2) ётун,
Не проверял, но предполагаю что если свойства Вашего «Объекта» будет состоять из примитивных типов, а модуль будет доступен как на клиенте так и на сервере, то вы сможете использовать серверные методы на сервере, а клиентские на клиенте, а свойства будут общие. То есть объект будет доступен и на клиенте и на сервере.В документации написано и тест показал что на сервере свойство «ЭтотОбъект» общего модуля не доступно. Следовательно «Объект» будет работать только на стороне клиента.(3) Спасибо!
Отсюда вытекает шестой и фатальный недостаток этой схемы. В то время, как бизнес-логика целиком обрабатывается на стороне сервера (фоновые, вебсервисы и т.п.) играться с этим на только на клиенте нет смысла.
(4) ётун, Не согласен. Общий модуль может быть клиентским и серверным. По клиентской части Вы попадаете в модуль, а по серверной части выполняйте работы на стороне сервера. Находясь в одном модуле можно же вызвать из клиентской части серверную. Например так:
Показать
(5) Примените, пожалуйста, то, что вы сейчас нафантазировали к вашей же методике и посмотрите, что получится.
Вы приводите недостатки предложенного метода. А достоинства вообще есть?
А чем обработки не подходят, вместо модуля? Надо статические методы — в модуль менеджера, надо работать с объектом на сервере без проблем, надо работать на клиенте, создаем форму пустую и там экспортные переменные и функции.
(8) pumbaE, да, обработки решают часть проблем. Появляются статические методы, нет нужды передавать объект, так как он содержится в виде объекта или формы. Но остальные недостатки те же. Наследования нет, полиморфизма нет, об абстракции даже и думать нельзя. В итоге и остается, что более-менее нативно в 1с можно сделать только инкапсуляцию, а все остальное — только через неудобные костыли 🙁
один вопрос: а зачем?
зачем пытаться сделать ООП из того, что как ООП не проэктировалось.
Вы не занимались в гараже тюнингом ВАЗ 2108, случайно?
попытка превратить свой тазик в иномарку, ну хотя бы с виду, угробив на это массу ресурсов и нервов и в итоге перечислять «недостатки».
Оно было придумано не для ООП а для конкретных задач бизнеса.
Для ООП есть тот же С++, на котором, если не ошибаюсь и написана 1С.
Учите его и пишите на нем, если так хочется
поездить на иномаркепоиграть в ООП.По примеру
Чем это лучще, чем поместить функцию ОбращениеПоШтатке в модуль объекта Справочник.Сотрудники и вызывать
Да, в базовом классе Справочник не определен этот метод, но и в примере я что-то не нахожу базового класса, предоставляющего данный интерфейс.
upd: OK, тут нет привязки к метаданным, но обычно всё-таки есть задача сохранения в БД данных, и городить огород с прослойкой ООП сомнительно. Ну и если без наследования и полиморфизма и без сохранения в БД, то есть штатная возможность — обработки, как уже отмечали.
upd2: Также, для любителей ООП есть внешние компоненты, но тут плохо знаком.
(0) Без обид, но это бред какой то
(6) ётун, Ваши комментарии самые ценные. Огромное спасибо! Дело в том, что до публикации статьи метод формировался и реализовывался действительно только для клиентской части приложения. Скажем так что методика была опробована при работе с табличным документом на стороне клиента где необходимо было управлять множеством областей у которых были как общие (одинаковые) свойства и методы, так и некоторые различия в них, плюс собственные свойства с методами принадлежащие только определенным типам областей. Изначально в глаза сразу бросалось дерево потомков. Вопрос работы с сервером не ставился. И огромное Вам СПАСИБО за указанные замечания.
В предыдущем ответе я действительно наивно думал что можно используя конструкции &НаКлиенте &НаСервере можно решить вопрос общения с сервером. Но прочитав Ваш последний комментарий и вспомнив о том что ВСЕ функции общего модуля с установленными свойствами «Сервер» и «Клиент» должны выполняться как на клиенте, так и на сервере, при этом находясь в клиентском контексте вызвать серверный контекст невозможно, я приуныл и подумал что ПООПс можно использовать только для клиентской части приложения.
Почитав еще раз документацию (как говориться: «Если ни чего не помогает, то прочти документацию»), пришел к следующему решению:
1. Если необходимо работать и на клиенте и на сервере, то модули должны разделяться соответственно на клиентский и серверный.
2. Для вызова серверного модуля из клиентского необходимо проводить промежуточное хранение ссылки на общий модуль клиентской части, а именно «ф».
Что касается наследования серверных методов, то они автоматом будут наследоваться, так как поток выполнения идет сверху от клиента. Могу Вам даже сказать что если в Вашем потомке нет необходимости корректировать серверные методы, то вам и не надо создавать для потомка серверный модуль.
И еще, в документации написано, что ссылки на объекты (документы, элементы справочника, планы счетов, и так далее) доступны как на клиенте, так и на сервере, а следовательно если в «объекте» ПООПс у вас будет ссылка на объект базы данных (например ссылка на справочник) то вы можете спокойно передавать такой объект с клиента на сервер и обратно. Нужно только следить за тем, что бы то что передается с клиента на сервер и обратно было доступно и там и там.
Уважаемые читатели, я не готов дискутировать на тему зачем ООП в 1С. Тем более что ВСЕ кто кодит в 1С используют «Lite» версию ООП в своей работе. Так например Любой справочник (например Организации) который вы создаете, является потомком класса Справочники у которых есть общие свойства и методы. Но вот сделать своего потомка от готового справочника у Вас увы не получится. Что касается других языков программирования, то написание на них модулей в стиле ООП действительно помогает, но встроить их в 1С можно только как внешние модули, а для некоторых решений с точки зрения политики безопасности и администрирования это не допустимо.
И последнее, те кто обратил внимание только на «Недостатки» должны попробовать полноценный ООП для того что бы понять его достоинства.
(11) zqzq, Одно из достоинств ООП в том, что метод описанный в базовом классе (в нашем примере это «Обращение») описывается один раз. И если потомок его не изменяет, то он автоматически обрабатывается базовым классом. Если бы у Вас были два похожих справочника один из которых физические лица, а другой сотрудники то метод «Обращение» Вам пришлось бы прописывать в каждом из них. В моем примере это простые методы. Но представьте что у Вас метод из 200-500 строк. Представьте что у Вас есть еще 20-30 справочников с похожим функционалом. И Вам в каждом необходимо разместить такой метод. А если нужно изменить метод для всех одновременно? Или в одном из справочников выполнить дополнительные действия с объектом?
Вы сейчас начнете писать что создадите общий модуль и перенесете туда общий метод, но это другой подход к программированию.
В данном случае вопрос не в новом методе которого нет у предка, а в том как можно произвести наследование.
По вопросу привязки к метаданным я ответил (13), про внешние компоненты в (14).
(15)
вот прям зудит подискутировать
но не буду ладно, раз автор не готов -)))
ухожу с этой темы.
(10) Makushimo,
Вы не занимались в гараже тюнингом ВАЗ 2108, случайно?
попытка превратить свой тазик в иномарку, ну хотя бы с виду, угробив на это массу ресурсов и нервов и в итоге перечислять «недостатки».
Оно было придумано не для ООП а для конкретных задач бизнеса
Не скажи. В 1с 7.7 был и есть 1с++. Весьма полезная и удобная штука. Наследование часто снимало часть костылей, особенно в 7.7, где был только один глобальный (общий) модули 😉
(15)
Показать
Вообще-то все современные конфигурации 1С в таком стиле и написаны.
(15)
Можно и «наследованием»:
(10) Я конечно далёк от восьмёрки, но таки немножко заглядывал в БСП. Между прочим, там как раз разработчики (из самой 1С) пытаются реализовать полиморфизм. Выглядит совершенно ужасно.
ООП не серебряная пуля конечно, но иногда очень полезно. Даже инкапсуляция — и то уже неплохо.
(19) kalimehtar, Вы считаете ЭТО наследованием? Если ЭТО
наследование, то как обращаться к свойствам которые установлены в классе «ФизЛицо» из класса «Сотрудник»? При наследовании я бы обратился
или
. В том примере который описали Вы кроме как
или
других вариантов нет. И что будет с Вашим кодом если будет 4-6 наследников? Если говорить о вашем предыдущем комментарии про общий модуль «Люди» то вы путаете «брата» и «потомка».
(0) Я просто оставлю это здесь…
(15) В ООП как подходе к программированию есть одна фундаментальная проблема, о ней даже авторы ООП и функциональных языков писали (с ходу не могу найти интервью и публикации) — это подход «идти от аксиом».
Т.е. вы определяете некоторые «аксиомы», некоторые базовые классы и от них начинаете строить следствия… но проблема в том, что в отличие от той же математики,где сейчас устоялся такой подход [но даже сейчас он не всегда корректен, пример аксиоматика теории множеств и т.п.], где этих «базовых» аксиом единицы и они прошли долгий пусть становления, иногда основываются на неких интуитивных принципах и даже при этом не всегда корректны…
В ООП же определение этих «базовых» аксиом ложится на КОНКРЕТНЫХ, зачастую МАЛОЧИСЛЕННЫХ людей в течение КОРОТКОГО исторического промежутка времени…Плюс строительство начинается не с самых общих понятий, как в математике, и которые тоже не всегда со временем оказываются действительно самыми общими, а с некоторого уровня абстракции…
Что увеличивает вероятность ошибки в выборе абстрактных обобщающих параметров, и т.п. И тут 2 проблемы:
— если завтра вы нашли более «общее» решение, то вам нужно сделать новый «базовый» класс для некоторых, уже существующих классов, что приводит к дикому рефакторингу, переписыванию больших кусков, а иногда и изменению логики существующих базовых классов…Т.е. выбрали не самый «общий» при проектировании — в процессе работы может придется «снизу->вверх» переписать n-ое кол-во классов, иногда до полного изменения логики работы;
— если вы ошиблись в своем аксиоматическом предположении, то и все следствия из него, все унаследованное также неверно…Т.е. может оказаться со временем что ваше первичное предположение было неверно и тогда весь ваш труд «следствий» можно также полностью выкинуть, как несоответствующей действительности.
Не скажи. В 1с 7.7 был и есть 1с++. Весьма полезная и удобная штука. Наследование часто снимало часть костылей, особенно в 7.7, где был только один глобальный (общий) модули 😉
(17) JohnyDeath, именно по этой причине в 8-ке добавили множество общих модулей, а когда поняли, что этого недостаточно, то добавили еще инкапсуляцию кода в рамках метаданных в модулях менеджеров объектов. Хотя, как показала БСП со своими сериями одноименных общих модулей для переопределения, этого все таки немного не хвататет…
(22) ToTMoM, Смешно! Однако когда у Вас возникает вопрос о том как нарезать хлеб, батон, торт, пирог, пиццу, и так далее вы наверно задумаетесь как реализовывать этот процесс. Делать универсальную Резку или для каждого вида хлебобулочных изделий описать свой способ этого процесса (или наследовать его от предка). Вопрос ведь в том что резать можно так: Изделие.Нарезать() и не важно какое это изделие хлеб, батон, торт и так далее. А можно так как: УниверсальнаяРезка(Изделие). Это разные подходы к программированию.
Мне вот интересно как бы вы реализовывали с помощью «УниверсальныхРезалок» работу с графикой? Где есть такие различные фигуры как круг, прямоугольник, многоугольник и так далее. Вы бы тоже делали «УниверсальныйЗакрашиватель()» , «УниверсальныйРасчетПлощади()», «УниверсальныйРасчетВерхнегоЛевогоУгла()» и так далее?!…
(23) Дык это, если начальные посылки не верны, то с любым подходом потом придётся всё переделывать.
Меня всегда удивляло, почему люди с такой настойчивостью ищут недостатки именно в методике и практике ООП? Прям аж конференции целые собирают, чуть ли не по типу Нюрнбергского процесса. В любом методе, любом подходе есть свои достоинства и недостатки — и чего теперь?
главное:
1. без фанатизма
2. думать головой, и не следовать слепо
а ещё заметил, что большинство ругающих ООП просто вообще ничерта в этом не понимает.
(26) ADirks,
+1
PS Алексей, привет! Давно тебя не было слышно 🙂
(25) Дело в том, что изначально объекты в ООП задумывались не как «полиморфизм, наследование, инкапсуляция», а как типа реальные объекты, которые посылают друг другу потоки данных и т.п. Т.е. как есть внутренности(как и у человека), и есть внешний интерфейс, и посредством внешнего интерфейса они общаются…Все. Просто есть процессы, привязанные к объекту, осуществляемые самим(!) объектом, типа Кошка.Прыгнуть()… А есть процессы, которые КТО-ТО ДРУГОЙ выполняет НАД объектом…
Вы же не делаете микроволновку к каждому виду продукта…У вас есть продукты, есть микроволновка и есть алгоритм их взаимодействия. Т.е. вы должны у для конкретного Овощ описать ИНСТРУКЦИЮ для приготовления (в нашем случае для разогрева), а нагревать Овощ должна Микроволновка…
Микроволновка.Нагреть(ЭтотОвощ,ЭтотОвощ.ПолучитьИнструкциюПриготовления(«НагревВМикроволновке»)).
Т.е. должно быть:
Внешние интерфейсы описывают, какие данные и в каком формате можно передать Объекту и что он вернет назад в соответствии с полученными данными. Плюс, так как объекты должны быть независимыми, то один объект может отдавать инструкции в одном формате, а другой в другом, то еще нужно контролировать конвертацию данных, отдаваемых одними объектами в данные, принимаемые другими объектами.
В итоге поток данных должен быть таков:
Овощ.ВнутренниеДанные<->Овощ.ВнешнийИнтерфейс->ПереводчикИнструкций.ВнешнийИнтерфейс<->ПереводчикИнструкций.ВнутренниеДанные<->ПереводчикИнструкций.ВнешнийИнтерфейс->Микроволновка.ВнешнийИнтерфейс<->Микроволновка.ВнутренниеДанные<->Микроволновка.ВнешнийИнтерфейс-> Приготовленный Овощ
Т.е. изначально это задумывалось как независимые объекты которые друг другу что-то передают, просят что-то с этим проделать и получают назад результаты. В некотором смысле Контрактное программирование с потоками данных между независимыми объектами.
А нынче, мало того что пропускают Микроволновки и заставляют Овощи греться самим, описывая внутреннее декларативное преобразование Овоща, а отнюдь не взаимодействие объектов…Так еще и наследуют Прямые от Точек, механизмы(а не «инструкции по») отрисовки Точек располагают в самих Точках, так еще и наследуют эти механизмы отрисовки к Прямой…
Вот есть например Точка, есть Прямая, это два независимых объекта. Объект Прямая объявляет: я могу состоять из двух объектов, которые подадут мне по моему запросу n-чисел типа double, где n = текущей размерности пространства, в котором я Прямая нахожусь. Если такие объекты есть и они выполняют наши договоренности — то я могу делать то-то и то-то. Если они не выполняют — то я могу делать только то-то, например сообщить об ошибке или еще что-то. Но это не родитель и предок, это один независимый объект, и второй объект, имеющий в составе другие объекты и зависящий от их поведения…
(25) что касается вопроса ОРГАНИЗАЦИИ ТЕКСТА КОДА и работы с ним, то тут нужно именно средство ОРГАНИЗАЦИИ ТЕКСТА КОДА.
Т.е. если методы повторяются, то явно в коде они не должны дублироваться, но ДЛЯ ПРОГРАММИСТА при желании они должны отображаться как дублированные. И программист, меняя метод ИЗ ЛЮБОГО МЕСТА ПРОГРАММЫ, включив режим «Отображение дублирования» указывает, меняет ли он поведение САМ МЕТОД, т.е. для всех, или он меняет ПОВЕДЕНИЕ этого метода для этого конкретного Объекта либо группы Объектов.
В итоге средство анализа синтаксиса САМО должно создать новую вторую, измененную процедуру и заменить вызовы у указанных объектов и в указанных местах. А иногда и далее САМО проанализировать код этих двух процедур, найти ОБЩУЮ часть, вынести её в новый метод и обернуть первые две процедуры, посредством вызовов третьей с разными параметрами либо еще как-нибудь…И все.
НО это все должно САМО делать средство синтаксического анализа кода. А программист в каждом конкретном месте должен мочь видеть не только обертки и вызовы функций и потом нажимая F12 скакать по ним, он должен мочь включить режим «Развернуть первый уровень вызовов» и увидеть в данном месте полный, реально выполняющийся код…И потом, если надо, внести изменения прям тут. А средство синтаксис. анализа должно САМО эти изменения преобразовать…
Вынесение общих процедур, наследование методов и дублирование кода — всем этим должно заниматься средство анализа, а не программист. Цель работы программиста — в работающем алгоритме, а организацию и удобство внесения изменений в код, структурирование обобщением и обертками должно выполнять специально обученное средство.
А суть ООП в данном случае — как классно что можно повесить все это на программиста! …
(26) ADirks, тут то и важно, откуда идешь. Если идешь от корней к листьям, то при неправильно предсказанном корне надо не просто «трансформировать», а иногда и полностью выкинуть весь последующий код, так ты предположил — а жизнь оказалась другой. Если ты идешь от листьев (наблюдаемых экспериментов, как в подходе физики), то завтра, если у тебя появился новый листик, то с следующими от них «общими» ветками может случиться лишь:
— надо две ветки 1 уровня «срастить» в более «толстую» ветку второго уровня… т.е. вынести обобщение
— надо ветку текущего(и если надо по цепочке далее) уровня сделать «потолще», т.е. расширить состав свойств, реквизитов… Вчера у вас например был «Красный листик» И «Зеленый листик» и у нас было только свойство Цвет. Завтра мы нашли другой листик, он оказался другим по Форме, добавляем еще свойство Форма и все.
Никаких ошибочных предположений тут возникнуть не может, т.к. мы ориентируемся и исходим не из гипотетических, нами придуманных обобщенных идей, а их конкретных случаев, к тому же реально наблюдаемых…И мы идем от «частных» к «общему», просто корректируя текущее обобщение если нужно.
В варианте же текущего понимания ООП, вы пишете в 1998 код, определяете класс Машина, делаете у нее Двигатель, с цилиндрами и прочей фигней, всякие там Карбюраторы, потом наследуете Бензиновые и Дизельные двигатели…А потом появляется электромобиль, и вы офигеваете, пробуя его впихнуть в свою систему классов xD
А можно просто в нужном классе переопределить или скрыть нужные методы что существенно сокращает время работы )) В этот и удобство ООП.
Изначальное предназначение ООП — упрощение однородных действий над разнородными объектами. Уменьшая на несколько процентов быстродействие, ООП в разы ускоряет разработку и поддержку.
Собственно родилось ООП из идеи хранить вместе с данными машинные адреса вызова процедур по их обработке (в эпоху, когда «машины были большими»); конструкторы-деструкторы родились из необходимости добавлять/убирать объекты в глобальной области памяти, автоматически проставляя правильные адреса вызовов, полиморфизм и наследование получились автоматически, а инкапсуляция — из здравого смысла для сохранения иерархичности кода и во избежание его запутывания.
И если за десятки лет существования среды в ней не стали реализовывать ООП, то причины явно не в невозможности реализации.
Для повышения порога входа для всех — начинающих и программистов из других экосистем, чтобы не снижать капитализацию, например. Или для поддержания стоимости разработки на определенном уровне. Или придумайте сами.
(31) vadim1011985, например, у тебя был класс Двигатель, у него были некоторые конструктивные внутренние части и механизмы работы с ними, например датчики температур, система подачи топлива и т.д.
Теперь у тебя появляется ЭлектроДвигатель. В принципе в данном случае можно расширить доступные типы Топлива, доопределить механизм работы «Системы подачи топлива» с учетом нового типа топлива «Электричество», но а во всем остальном? Просто добавить новых конструктивных элементов присущих ЭлектроДвигателю и скрывать другие части в зависимости от типа? Типа если это ЭлектроДвигатель, то явно я у него не увижу цилиндров и поршней, но по факту они есть? мдя…
По-правильному, вам в итоге надо изменить класс Двигатель, перенеся частные конструктивные особенности и связанный функционал в классы-наследники, потом выделить еще один обший по коструктиву класс для бензиновых и дизельных двигателей. Т.е. для добавления одного класса надо:
— сравнить добавляемый функционал с выбранным классом-родителем
— перенести частные и лишние особенности из класса-родителя, к которому мы добавляем наш новый, во все классы-наследники
— в зависимости от классов-наследников произвести рефакторинг и создать нужное количество новых общих классов для них
И так каждый раз)
(33) ToTMoM,
Теперь у тебя появляется ЭлектроДвигатель. В принципе в данном случае можно расширить доступные типы Топлива, доопределить механизм работы «Системы подачи топлива» с учетом нового типа топлива «Электричество», но а во всем остальном? Просто добавить новых конструктивных элементов присущих ЭлектроДвигателю и скрывать другие части в зависимости от типа? Типа если это ЭлектроДвигатель, то явно я у него не увижу цилиндров и поршней, но по факту они есть? мдя…
Не совсем если на примере то можно объяснить так например есть класс TPoint c полями f_X f_Y и F_Color и Методом Paint (X,Y) и свойство SetColor который по заданным координатам закрашивает точку по заданному цвету
От него наследуется Класс TLine первоначально все методы и свойства этого класса открыты но например я не хочу что бы линия меняла цвет поэтому метод setColorя помещаю в секцию Privat и уже для класса TLine Этот метод недоступен. т.е. а Метод Paint (X,Y) переопределяем таким образом что он строит линию закрашивает точки от одной координаты до другой — таким образом образуя линию
Инкапсуляция
Инкапсуляция (encapsulation) — это механизм, который объединяет данные и код, манипулирующий зтими данными, а также защищает и то, и другое от внешнего вмешательства или неправильного использования. В объектно-ориентированном программировании код и данные могут быть объединены вместе; в этом случае говорят, что создаётся так называемый «чёрный ящик». Когда коды и данные объединяются таким способом, создаётся объект (object). Другими словами, объект — это то, что поддерживает инкапсуляцию.
Внутри объекта коды и данные могут быть закрытыми (private). Закрытые коды или данные доступны только для других частей этого объекта. Таким образом, закрытые коды и данные недоступны для тех частей программы, которые существуют вне объекта. Если коды и данные являются открытыми, то, несмотря на то, что они заданы внутри объекта, они доступны и для других частей программы. Характерной является ситуация, когда открытая часть объекта используется для того, чтобы обеспечить контролируемый интерфейс закрытых элементов объекта.
(30) Ну я снова спрашиваю: причём тут ООП? Проектирование снизу вверх, и сверху вниз ну никак не связано с ООП. Если модель целевой системы построена неправильно, то при любой реализации будут проблемы. Если в ходе жизни целевая система кардинально изменилась, то и модель надо кардинально менять. Это свойственно любой модели, и избежать этого невозможно.
А чем, собственно, ООП будет полезно в рамках 1с?
Зачем так издеваться над собой? 1С придумана для удешевления готового продукта. В SAP есть чистый ООП. Но стоимость внедрения/владения 1С в разы меньше. И именно такими жесткими мерами и был достигнут такой результат. «Дорогие» программисты на с++ создали продукт, который позволить делать готовые решения используя более «дешевых» программистов.
Не надо пытаться прикрутить к велосипеду пятое колесо. Тем более, что не получится от этого получить хоть какую-то выгоду.
P.S.: Я анализировал 1С на присутствие ООП и понял, что все элементы в нем есть. Это и наследование (когда создается новый справочник, то он наследует методы, присущие справочнику). Есть классы «Структура», «Соответствие», «Таблица значений», которые являются явным примером применения инкапсуляции и полиморфизма. И хоть программист не может создвать перегруженные функции, но в 1С такие используются. Например, функция «Скопировать» таблицы значений. Можно передать Перечень строк и колонок, а можно структуру, содержащую параметры отбора. 1С это ООП, но с ограничениями для разработчика.
(38) karapuzzzz, я бы сказал что 1с это результат ООП . Про наследование я бы поспорил, так как при создании справочника вы создаете очередной объект класса «Справочник» которому присуще свои поля (Наименование и код) , методы (НайтиПоКоду , НайтиПоНаименованию и т.д) и свои свойства о наследовании тут речи нет. Тоже касается и структур и соответствий вы создаете объекты некоторых классов и работаете с ними.
(19) kalimehtar, вы сейчас описали не наследование, а «включение». Наследование = А является Б (базовый класс), включение = А содержит Б. Кстати, включение более просто по поддержке и лучше поддерживает сокрытие данных/реализации, т.к. доступен только внешний интерфейс включаемого класса.
(38) karapuzzzz,
Не думаю. Стоимость продукта зависит от платежеспособности целевой аудитории.
Качество продукта зависит от объемов бюджетов на его обслуживание, на которые готова целевая аудитория.
(41) v3rter,
Не обязательно. Более-менее объективной системы оценки-то не существует. Я несколько раз сталкивался с решением одной и той же задачи (скажем, развитие существующего функционала в уже готовых решениях) на разных платформах (1с и другие), стоимость которых жутко различалась. Причём разница в стоимости была не однозначной: ни 1с, ни другая платформа не претендуют на звание «всегда дешевле». Были и архидорогие реализации на 1с против довольно дешёвых на другой платформе, была и дешевая реализация на 1с против дорогой на другой платформе. Два случая можно отнести к грамотному впариванию (при этом нельзя сказать, что впаривалось особо жирному клиенту, у которого денег куры не клюют). Думаю, что всё дело тут в подходах менеджмента. Боссы, курирующие проекты, часто поступаются принципами научного менеджмента, и пренебрегают поиском и изучением альтернатив. Если бы они, прежде чем пускать разрабов в свой огород, удосужились прибегнуть к оценке стоимости работы другими разрабами, то и стоимость, возможно, была бы совсем другой.
Все это время не было возможности писать ответы, но читал с большим удовольствием. Многое было переосмыслено (за это Огромное спасибо ToTMoM).
Жаль, что обсуждение данного поста переросло в обсуждение полезности и бесполезности ООП.
Исходя из всех комментариев к данной теме, можно обобщить:
1. Данная методика позволяет спокойно манипулировать данными как на клиенте, так и на сервере.
2. Созданные «Объекты» имеют признак инкапсуляции и как говорилось в комментариях «полезна во всех подходах».
3. В данном случае следствием инкапсуляции является полиморфизм.
4. И, к сожалению, если необходимо наследование его нужно имитировать вручную.
Методика позволяет с указанными ограничениями работать в стиле ООП. Для тех кто придерживается другой точки зрения, данный пост позволяет нестандартно манипулировать данными в своей работе.
Методика, конечно интересная, но как уже отписались выше, в 1С есть менее затратные средства тоже приближенные по духу к ООП. Это и обработки, и модули предопределенных объектов. Разумеется большая часть средств уже зашита в платформу в качестве предопределенных классов, но это лишь специфика среды разработки.
С реальной, а не религиозной потребностью в чистом ООП в 1С сталкивался лишь тогда когда пытался на ней решать нетиповые для платформы задачи. Например, когда писал игрушку для бухов
да не надо для учетной системы ООП!
не надо!
ООП это простой другой путь мышления и соот-но архитектуры приложения.
В 1С мы имеем чистый процедурный подход и пытаться пристроить сюда ООП бессмысленно.
ЗЫ Я видел приложения на андроид/джава после процедурщиков.
С точки зрения ООП жуть берет. Писать на джава в духе процедур это тоже известная проблема.
(46) Вы озвучили ключевую фразу. Скомпилирую её до утверждения «ООП это (в первую очередь)- тип мышления». Отсюда мы придем к тому, что даже в турбо-бейсике, можно использовать идеологию ООП. Я конечно утрирую, но привычки и подход к работе кочуют за человеком, а не языком (средой разработки). Лишь долгая работа в какой-то среде, может привести к пониманию духа и «родного» стиля инструмента.
Однажды, мне пришлось описать концепцию ООП, применительно к практике разработки на 1С. И, с известными ограничениями (учитывая фиксированность некоторых структур) удалось это сделать, не найдя нереализованных концепций.
В конце концов, что такое ООП — это способ позволяющий разработчику абстрагироваться от деталей. И в 1С достаточно инструментов, для построения подобного рода схем. Скажу даже больше, успешные в коммерческом смысле решения, зачастую строятся из очень некачественных составляющих. Но удачная архитектура, и соответствие «классов-кирпичмков» спецификации позволяет отложить оптимизацию внутренностей на более поздние этапы. Я лично участвовал в проектах, где непосредственно код методов классов писали откровенные «обезьяны». Но так как до проектирования классов «обезьяны» не были допущены, то в целом продукт вышел стабильный и в срок. То что большинство разработчиков не поднимается выше теории структуры алгоритма и процедурных подходов, говорит лишь о доступности среды разработки широкому кругу лиц. Что в принципе даже хорошо, так как в разработке нужны и рядовые кодеры, которые напишут большую часть кода.
Отсюда же следует, что проблема «в 1С нет ООП» исходит от разработчиков изучивших конкретный (отличный от 1С) инструмент, но не постигших суть ОПП. Отсюда и костыли, ненужные в такой предметно-заточенной среде как 1С, и несбывшиеся ожидания. Об этом я и писал уже, менее развернуто в (44).
(47) Артано,
Ню-ню… высшая каста прямо программисткая…
…»не постигших суть ОПП»….
:))))
(48) Нет, я всего лишь двигаюсь в направлении первичности понимания принципов, над отдельными фактами. И это не только к программированию относится. Использование любого инструмента, будь то методика анализа, среда разработки, даже лопата, в конце концов, без понимания фундаментальных принципов просто сведется к запоминанию «куда надо нажать чтобы заработало».
(49) Артано,
«в направлении первичности понимания принципов, над отдельными фактами» :)))) — 1С не лучший помощник в этом!
Вы не в ту сторону двигаетесь! (уж извините) :))
некоторым очень не хватает умения: «куда надо нажать чтобы заработало»!
:)))
Суть ООП в полиморфизме. При процедурном подходе полиморфизм невозможен. Полиморфизм — это, по сути, управление потоком выполнения — код, который будет выполнен в результате вызова функции, определяется не в функции, а вне её. Это позволяет манипулировать абстракциями высшего порядка. Вот и всё.
Наследование — это специфическое и довольно странное средство обеспечения полиморфизма, инкапсуляция — пустышка и ересь.
(3)
Используйте модуль обработки — он доступен везде. Сам использую их в качестве псевдоклассов (без наследования) — очень удобно, IMHO
(52) Спасибо, я с этим знаком.
Почему невозможен? Если доступен eval() | Выполнить(), то очень даже возможен, другое дело, что со скоростью интерпретатора. И даже когда eval недоступен, доступны гигантские CASE | ЕСЛИ ИНАЧЕЕСЛИ ИНАЧЕЕСЛИ … КОНЕЦЕСЛИ, то есть возможен, но с «костылями». ООП перекладывает это на уровень компилятора. А вот написание кода в стиле описания объектов и переопределения методов изначально было побочным эффектом, который настолько всем понравился, что превратился в основной, оброс идеологией, методологией и вошел в учебники )