Подобие Объектно-ориентированного программирования в 1С (ПООПс)

24.07.16

Разработка - Рефакторинг и качество кода

Статья для тех кто знаком с ООП и опустил руки.

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

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

Общий модуль "Класс_ФизическоеЛицо"

Функция Конструктор() Экспорт
	МойОбъект = Новый Структура("Фамилия, Имя, _Пол", "", "", "");
	МойОбъект.Вставить("ф", ЭтотОбъект);
	Возврат МойОбъект;
КонецФункции

Функция Обращение(МойОбъект) Экспорт
	Возврат МойОбъект.Фамилия+", "+МойОбъект.Имя;
КонецФункции

Функция Пол(МойОбъект, Пол="") Экспорт
	Если НЕ ПустаяСтрока(Пол) Тогда
		МойОбъект._Пол = Пол;
	КонецЕсли;
	Возврат МойОбъект._Пол;
КонецФункции 

Здесь видно, что в качестве рабочей лошадки используется "Структура", хотя на ее место вполне подходит и "Соответствие".  Первый недостаток заключается в том, что для вызова метода объекта необходимо использовать какое либо имя свойства для определения ссылки на модуль. Я для себя определил этим ключевым словом букву "ф". Но, методы и свойства чудесным образом объединились и теперь находятся в одной структуре (объекте) ссылку на который можно передавать и использовать почти в любом месте. Второй недостаток заключается в том, что контекст структуры не передается при вызове метода из этой структуры. Следовательно, необходимо первым параметром передать саму структуру. По этому все методы которые работают с данными объекта первым параметром получают саму структуру. Этот параметр я назвал «МойОбъект» (ну просто по тому что ключевое слово «ЭтотОбъект» занято). Третий недостаток заключается в том, что нет возможности сделать скрытыми свойства. Для себя я определил, что скрытыми будут те свойства, которые начинаются с символа «_» (подчеркивание) или их можно перенести в отдельное свойство (например, с именем «Скрытые»), состоящее из структуры только скрытых свойств. Что касается методов, то тут ситуация не такая однозначная. Ведь если процедуре или функции модуля не установить ключевое слово «Экспорт» то она будет недоступна из внешнего модуля, но она не будет доступна и для наследника. По этому если Вам необходимо использовать скрытый метод у наследников начинайте его так же как и скрытые свойства со знака «_» подчеркивания.

И так с инкапсуляцией мы разобрались. Теперь нам нужно решить вопрос с самым главным – наследованием. Смотрим следующий текст модуля:

Общий модуль "Класс_Сотрудник"

Функция КлассРодитель()
	Возврат Класс_ФизическоеЛицо.ЭтотОбъект;
КонецФункции

Функция Конструктор() Экспорт
	МойОбъект = КлассРодитель().Конструктор(); // Родительский конструктор
	МойОбъект.Вставить("Должность", ""); // Добавляем новое свойство
	МойОбъект.Вставить("ф", ЭтотОбъект); // Заменяем модуль набора методов
	Возврат МойОбъект;
КонецФункции

Функция ОбращениеПоШтатке(МойОбъект) Экспорт	// Новый метод этого класса
	Возврат МойОбъект.Должность+" - "+МойОбъект.Ф.Обращение(МойОбъект);
КонецФункции

Функция Пол(МойОбъект, Пол=Неопределено) Экспорт	// Модифицированный метод
	Если (Пол<>Неопределено) и (НЕ (Пол="М" или Пол="Ж")) Тогда
		Сообщить("Недопустимое значение при установке пола сотрудника!");
		Возврат Неопределено;
	КонецЕсли; 
	Возврат КлассРодитель().Пол(МойОбъект, Пол); // Вызываем родительский метод
КонецФункции

Функция Обращение(МойОбъект) Экспорт	// Наследованный метод
	Возврат КлассРодитель().СтрокаФИО(МойОбъект);
КонецФункции

Обратите внимание - каждый класс располагается в отдельном общем модуле. Теперь давайте смотреть, что у нас получилось. Конструктор вызывает родительский конструктор и получает от него все свойства, которые были определены в родительском классе, а если он вызывает своего родителя мы получим и свойства прародителя.. Четвертым недостатком является то, что если вы полностью переопределяете конструктор дочернего класса, то вы должны самостоятельно позаботиться о создании всех свойств, которые создаются родительским конструктором. Пятым недостатком и на мой взгляд самым существенным является то, что ВСЕ методы которые использует потомок необходимо объявлять в модуле потомка (в примере это функция «Обращение»).  Небольшой ложкой меда здесь служит то, что при последующем или повторном наследовании эти методы можно перенести потомку простым копированием. Этот же недостаток заставляет отслеживать самостоятельно создание новых методов и копирование кода наследования в дочерние классы.

-

Но в результате мы получили объектный полиморфизм.

Давайте посмотрим, как будут работать наши классы в прикладном решении:

-

Использование в прикладном решении:

Сотрудник = Класс_Сотрудник.Конструктор();
Сотрудник.Фамилия   = "Иванов";
Сотрудник.Имя       = "Иван";
Сотрудник.Должность = "Программист 1С";

Клиент = Класс_ФизическоеЛицо.Конструктор();
Клиент.Фамилия   = "Петров";
Клиент.Имя       = "Петр";

Сообщить(Сотрудник.ф.Обращение(Сотрудник));	// Иванов, Иван
Сообщить(Клиент.ф.Обращение(Клиент));	// Петров, Петр

Сообщить(Сотрудник.ф.ОбращениеПоШтатке(Сотрудник));	// Программист 1С - Иванов, Иван

Сотрудник.ф.Пол(Сотрудник, "Н");	// Недопустимое значение при установке пола сотрудника!
Сотрудник.ф.Пол(Сотрудник, "М");
Сообщить(Сотрудник.ф.Пол(Сотрудник));	// М

Как видно из примера финальный код почти похож на стандартный ОПП (за исключением буквы «ф» перед методом и передачей самого объекта в качестве первого параметра) и такой подход можно смело назвать Подобием Объектно Ориентированного Программирования в 1С (ПООПс)

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

См. также

Когда понадобился новый оператор

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1160    ZhokhovM    2    

4

Когда разработчик платформы не добавил проверку препроцессоров

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    2690    ZhokhovM    4    

9

Реструктуризация - бесконечная история

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    1910    1CUnlimited    15    

22

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

27.09.2023    6970    Lemmonbri    136    

36

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

19.09.2023    4350    Lemmonbri    16    

31

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

Нашей компании часто приходится сталкиваться с обновлением конфигураций разной степени переписанности. Какие-то из них обновляются легко, какие-то — не очень. Расскажем о некоторых принципах модификации программы, которые помогут сделать последующий процесс обновления легче. Или тяжелее, если стараться их не соблюдать.

10.08.2023    9590    0    1c-izhtc    37    

21

Задача на ошибки и неоптимальности при проведении приходной накладной

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Задачу эту дают на собеседованиях, видимо, те франчи, которые не в состоянии оценить человека по резюме и в ходе беседы. По идее задачи, подобные этой, должны давать начинающим студентам. Но дают всем подряд. Итак: мои 5 копеек. Критика приветствуется.

11.07.2023    2214    magic1s    32    

11
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Armando 1399 24.07.16 22:27 Сейчас в теме
2. ётун 24.07.16 22:48 Сейчас в теме
А что произойдет при передаче такого "объекта" с клиента на сервер и обратно?
pbazeliuk; +1 Ответить
3. adam26 42 24.07.16 23:18 Сейчас в теме
(2) ётун, Не проверял, но предполагаю что если свойства Вашего "Объекта" будет состоять из примитивных типов, а модуль будет доступен как на клиенте так и на сервере, то вы сможете использовать серверные методы на сервере, а клиентские на клиенте, а свойства будут общие. То есть объект будет доступен и на клиенте и на сервере. В документации написано и тест показал что на сервере свойство "ЭтотОбъект" общего модуля не доступно. Следовательно "Объект" будет работать только на стороне клиента.
4. ётун 24.07.16 23:55 Сейчас в теме
(3) Спасибо!
Отсюда вытекает шестой и фатальный недостаток этой схемы. В то время, как бизнес-логика целиком обрабатывается на стороне сервера (фоновые, вебсервисы и т.п.) играться с этим на только на клиенте нет смысла.
5. adam26 42 25.07.16 03:46 Сейчас в теме
(4) ётун, Не согласен. Общий модуль может быть клиентским и серверным. По клиентской части Вы попадаете в модуль, а по серверной части выполняйте работы на стороне сервера. Находясь в одном модуле можно же вызвать из клиентской части серверную. Например так:

&НаКлиенте
Функция ПрочитатьНаКлиенте(Мойобъект) Экспорт
	Мойобъект = ПрочитатьНаСервере(Мойобъект);
КонецФункции

&НаСервере
Функция ПрочитатьНаСервере(Мойобъект)
	//
	// Читаем данные из базы и присваиваем свойствам полученные значения
	//
	Возврат МойОбъект;
КонецФункции
Показать
6. ётун 25.07.16 08:10 Сейчас в теме
(5) Примените, пожалуйста, то, что вы сейчас нафантазировали к вашей же методике и посмотрите, что получится.
13. adam26 42 26.07.16 02:15 Сейчас в теме
(6) ётун, Ваши комментарии самые ценные. Огромное спасибо! Дело в том, что до публикации статьи метод формировался и реализовывался действительно только для клиентской части приложения. Скажем так что методика была опробована при работе с табличным документом на стороне клиента где необходимо было управлять множеством областей у которых были как общие (одинаковые) свойства и методы, так и некоторые различия в них, плюс собственные свойства с методами принадлежащие только определенным типам областей. Изначально в глаза сразу бросалось дерево потомков. Вопрос работы с сервером не ставился. И огромное Вам СПАСИБО за указанные замечания.
В предыдущем ответе я действительно наивно думал что можно используя конструкции &НаКлиенте &НаСервере можно решить вопрос общения с сервером. Но прочитав Ваш последний комментарий и вспомнив о том что ВСЕ функции общего модуля с установленными свойствами "Сервер" и "Клиент" должны выполняться как на клиенте, так и на сервере, при этом находясь в клиентском контексте вызвать серверный контекст невозможно, я приуныл и подумал что ПООПс можно использовать только для клиентской части приложения.
Почитав еще раз документацию (как говориться: "Если ни чего не помогает, то прочти документацию"), пришел к следующему решению:
1. Если необходимо работать и на клиенте и на сервере, то модули должны разделяться соответственно на клиентский и серверный.
2. Для вызова серверного модуля из клиентского необходимо проводить промежуточное хранение ссылки на общий модуль клиентской части, а именно "ф".
	ф = МойОбъект.ф;
	МойОбъект.Удалить("ф");
	Класс_ФизическоеЛицо_Сервер.ПолучитьПервогоНаСервере(МойОбъект);
	МойОбъект.Вставить("ф", ф);


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

И еще, в документации написано, что ссылки на объекты (документы, элементы справочника, планы счетов, и так далее) доступны как на клиенте, так и на сервере, а следовательно если в "объекте" ПООПс у вас будет ссылка на объект базы данных (например ссылка на справочник) то вы можете спокойно передавать такой объект с клиента на сервер и обратно. Нужно только следить за тем, что бы то что передается с клиента на сервер и обратно было доступно и там и там.
52. kote 536 07.03.17 15:12 Сейчас в теме
(3)
В документации написано и тест показал что на сервере свойство "ЭтотОбъект" общего модуля не доступно. Следовательно "Объект" будет работать только на стороне клиента.


Используйте модуль обработки - он доступен везде. Сам использую их в качестве псевдоклассов (без наследования) - очень удобно, IMHO
53. adam26 42 07.03.17 15:33 Сейчас в теме
(52) Спасибо, я с этим знаком.
7. ardn 622 25.07.16 08:40 Сейчас в теме
Вы приводите недостатки предложенного метода. А достоинства вообще есть?
sigmov; adhocprog; BigB; +3 Ответить
8. pumbaE 25.07.16 08:58 Сейчас в теме
А чем обработки не подходят, вместо модуля? Надо статические методы - в модуль менеджера, надо работать с объектом на сервере без проблем, надо работать на клиенте, создаем форму пустую и там экспортные переменные и функции.
CyberCerber; HAMMER_59; Артано; Yashazz; cleaner_it; dj_serega; adhocprog; zarius; artbear; Трактор; Dementor; kuntashov; sorb; Tavalik; JohnyDeath; pbazeliuk; NeviD; zqzq; nixel; +19 Ответить
9. nixel 1403 25.07.16 09:44 Сейчас в теме
(8) pumbaE, да, обработки решают часть проблем. Появляются статические методы, нет нужды передавать объект, так как он содержится в виде объекта или формы. Но остальные недостатки те же. Наследования нет, полиморфизма нет, об абстракции даже и думать нельзя. В итоге и остается, что более-менее нативно в 1с можно сделать только инкапсуляцию, а все остальное - только через неудобные костыли :(
10. Makushimo 160 25.07.16 09:44 Сейчас в теме
один вопрос: а зачем?

зачем пытаться сделать ООП из того, что как ООП не проэктировалось.
Вы не занимались в гараже тюнингом ВАЗ 2108, случайно?

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

Оно было придумано не для ООП а для конкретных задач бизнеса.

Для ООП есть тот же С++, на котором, если не ошибаюсь и написана 1С.
Учите его и пишите на нем, если так хочется поездить на иномарке поиграть в ООП.
ImHunter; NoRazum; RainyAugust22; Yashazz; cleaner_it; dj_serega; Dementor; h00k; spy-83; ётун; BigB; +11 2 Ответить
17. JohnyDeath 301 26.07.16 23:34 Сейчас в теме
(10) Makushimo,
зачем пытаться сделать ООП из того, что как ООП не проэктировалось.
Вы не занимались в гараже тюнингом ВАЗ 2108, случайно?

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

Оно было придумано не для ООП а для конкретных задач бизнеса

Не скажи. В 1с 7.7 был и есть 1с++. Весьма полезная и удобная штука. Наследование часто снимало часть костылей, особенно в 7.7, где был только один глобальный (общий) модули ;)
24. Dementor 1015 27.07.16 10:38 Сейчас в теме

Не скажи. В 1с 7.7 был и есть 1с++. Весьма полезная и удобная штука. Наследование часто снимало часть костылей, особенно в 7.7, где был только один глобальный (общий) модули ;)

(17) JohnyDeath, именно по этой причине в 8-ке добавили множество общих модулей, а когда поняли, что этого недостаточно, то добавили еще инкапсуляцию кода в рамках метаданных в модулях менеджеров объектов. Хотя, как показала БСП со своими сериями одноименных общих модулей для переопределения, этого все таки немного не хвататет...
20. ADirks 186 27.07.16 09:33 Сейчас в теме
(10) Я конечно далёк от восьмёрки, но таки немножко заглядывал в БСП. Между прочим, там как раз разработчики (из самой 1С) пытаются реализовать полиморфизм. Выглядит совершенно ужасно.

ООП не серебряная пуля конечно, но иногда очень полезно. Даже инкапсуляция - и то уже неплохо.
11. zqzq 23 25.07.16 10:55 Сейчас в теме
По примеру
Сотрудник = Класс_Сотрудник.Конструктор();
...
Сотрудник.ф.ОбращениеПоШтатке(Сотрудник)

Чем это лучще, чем поместить функцию ОбращениеПоШтатке в модуль объекта Справочник.Сотрудники и вызывать
Сотрудник = Справочники.Сотрудники.СоздатьЭлемент();
...
Сотрудник.ОбращениеПоШтатке()

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

upd: OK, тут нет привязки к метаданным, но обычно всё-таки есть задача сохранения в БД данных, и городить огород с прослойкой ООП сомнительно. Ну и если без наследования и полиморфизма и без сохранения в БД, то есть штатная возможность -- обработки, как уже отмечали.

upd2: Также, для любителей ООП есть внешние компоненты, но тут плохо знаком.
15. adam26 42 26.07.16 02:49 Сейчас в теме
(11) zqzq, Одно из достоинств ООП в том, что метод описанный в базовом классе (в нашем примере это "Обращение") описывается один раз. И если потомок его не изменяет, то он автоматически обрабатывается базовым классом. Если бы у Вас были два похожих справочника один из которых физические лица, а другой сотрудники то метод "Обращение" Вам пришлось бы прописывать в каждом из них. В моем примере это простые методы. Но представьте что у Вас метод из 200-500 строк. Представьте что у Вас есть еще 20-30 справочников с похожим функционалом. И Вам в каждом необходимо разместить такой метод. А если нужно изменить метод для всех одновременно? Или в одном из справочников выполнить дополнительные действия с объектом?
Вы сейчас начнете писать что создадите общий модуль и перенесете туда общий метод, но это другой подход к программированию.
В данном случае вопрос не в новом методе которого нет у предка, а в том как можно произвести наследование.

По вопросу привязки к метаданным я ответил (13), про внешние компоненты в (14).
16. Makushimo 160 26.07.16 05:57 Сейчас в теме
(15)
вот прям зудит подискутировать
но не буду ладно, раз автор не готов -)))
ухожу с этой темы.
18. kalimehtar 22 27.07.16 08:39 Сейчас в теме
(15)
Если бы у Вас были два похожих справочника один из которых физические лица, а другой сотрудники то метод "Обращение" Вам пришлось бы прописывать в каждом из них. В моем примере это простые методы. Но представьте что у Вас метод из 200-500 строк


Общий модуль Люди:
Процедура Обращение(Объект) Экспорт
   ...
   500 строк
  ...
КонецПроцедуры

Модуль справочника Физлица:
Процедура Обращение() Экспорт
   Люди.Обращение(ЭтотОбъект)
КонецПроцедуры

Модуль справочника Сотрудники:
Процедура Обращение() Экспорт
   Люди.Обращение(ЭтотОбъект)
КонецПроцедуры
Показать


Вообще-то все современные конфигурации 1С в таком стиле и написаны.
19. kalimehtar 22 27.07.16 08:58 Сейчас в теме
(15)

В данном случае вопрос не в новом методе которого нет у предка, а в том как можно произвести наследование.

Можно и "наследованием":

Справочник Сотрудник
  Реквизит
    Физлицо

Процедура Обращение() Экспорт 
   Физлицо.Обращение() 
КонецПроцедуры 
21. adam26 42 27.07.16 09:56 Сейчас в теме
(19) kalimehtar, Вы считаете ЭТО наследованием? Если ЭТО
Справочник Сотрудник
  Реквизит
    Физлицо

Процедура Обращение() Экспорт 
   Физлицо.Обращение() 
КонецПроцедуры 

наследование, то как обращаться к свойствам которые установлены в классе "ФизЛицо" из класса "Сотрудник"? При наследовании я бы обратился
Сотрудник.Фамилия 
или
Сотрудник.Имя
. В том примере который описали Вы кроме как
Сотрудник.ФизЛицо.Фамилия
или
Сотрудник.ФизЛицо.Имя
других вариантов нет. И что будет с Вашим кодом если будет 4-6 наследников? Если говорить о вашем предыдущем комментарии про общий модуль "Люди" то вы путаете "брата" и "потомка".
40. zqzq 23 28.07.16 09:28 Сейчас в теме
(19) kalimehtar, вы сейчас описали не наследование, а "включение". Наследование = А является Б (базовый класс), включение = А содержит Б. Кстати, включение более просто по поддержке и лучше поддерживает сокрытие данных/реализации, т.к. доступен только внешний интерфейс включаемого класса.
23. ToTMoM 27.07.16 10:35 Сейчас в теме
(15) В ООП как подходе к программированию есть одна фундаментальная проблема, о ней даже авторы ООП и функциональных языков писали (с ходу не могу найти интервью и публикации) - это подход "идти от аксиом".

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

В ООП же определение этих "базовых" аксиом ложится на КОНКРЕТНЫХ, зачастую МАЛОЧИСЛЕННЫХ людей в течение КОРОТКОГО исторического промежутка времени...Плюс строительство начинается не с самых общих понятий, как в математике, и которые тоже не всегда со временем оказываются действительно самыми общими, а с некоторого уровня абстракции...


Что увеличивает вероятность ошибки в выборе абстрактных обобщающих параметров, и т.п. И тут 2 проблемы:

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

- если вы ошиблись в своем аксиоматическом предположении, то и все следствия из него, все унаследованное также неверно...Т.е. может оказаться со временем что ваше первичное предположение было неверно и тогда весь ваш труд "следствий" можно также полностью выкинуть, как несоответствующей действительности.
26. ADirks 186 27.07.16 11:25 Сейчас в теме
(23) Дык это, если начальные посылки не верны, то с любым подходом потом придётся всё переделывать.

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

главное:
1. без фанатизма
2. думать головой, и не следовать слепо

а ещё заметил, что большинство ругающих ООП просто вообще ничерта в этом не понимает.
kote; 33lab; JohnyDeath; +3 Ответить
27. artbear 1448 27.07.16 11:40 Сейчас в теме
(26) ADirks,
а ещё заметил, что большинство ругающих ООП просто вообще ничерта в этом не понимает.

+1

PS Алексей, привет! Давно тебя не было слышно :)
30. ToTMoM 27.07.16 12:22 Сейчас в теме
(26) ADirks, тут то и важно, откуда идешь. Если идешь от корней к листьям, то при неправильно предсказанном корне надо не просто "трансформировать", а иногда и полностью выкинуть весь последующий код, так ты предположил - а жизнь оказалась другой. Если ты идешь от листьев (наблюдаемых экспериментов, как в подходе физики), то завтра, если у тебя появился новый листик, то с следующими от них "общими" ветками может случиться лишь:
- надо две ветки 1 уровня "срастить" в более "толстую" ветку второго уровня... т.е. вынести обобщение
- надо ветку текущего(и если надо по цепочке далее) уровня сделать "потолще", т.е. расширить состав свойств, реквизитов... Вчера у вас например был "Красный листик" И "Зеленый листик" и у нас было только свойство Цвет. Завтра мы нашли другой листик, он оказался другим по Форме, добавляем еще свойство Форма и все.

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

В варианте же текущего понимания ООП, вы пишете в 1998 код, определяете класс Машина, делаете у нее Двигатель, с цилиндрами и прочей фигней, всякие там Карбюраторы, потом наследуете Бензиновые и Дизельные двигатели...А потом появляется электромобиль, и вы офигеваете, пробуя его впихнуть в свою систему классов xD
35. ADirks 186 27.07.16 13:53 Сейчас в теме
(30) Ну я снова спрашиваю: причём тут ООП? Проектирование снизу вверх, и сверху вниз ну никак не связано с ООП. Если модель целевой системы построена неправильно, то при любой реализации будут проблемы. Если в ходе жизни целевая система кардинально изменилась, то и модель надо кардинально менять. Это свойственно любой модели, и избежать этого невозможно.
37. ToTMoM 27.07.16 17:07 Сейчас в теме
(35) ADirks, так и я о том, причем тут ООП! Что тогда по вашему ООП? Для меня парадигма программирования = определенный взгляд на организацию обмена и обработки данных. А не "полезные приемы структурирования кода"...Структура кода - это одно, взгляд на "организацию процесса" - другое. Первое должно решаться средствами компиляторов, синтаксис-анализаторов и т.п.

Теперь я просто оставлю еще и это здесь:
https://habrahabr.ru/company/hexlet/blog/303754/
http://rainman-rocks.livejournal.com/122876.html


  • Я считал объекты чем-то вроде биологических клеток, и/или отдельных компьютеров в сети, которые могут общаться только через сообщения.
  • ООП для меня это сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего.

    И ничего про наследование. Это не тот ООП, который мы знаем сегодня:
  • Мне жаль, что давным давно я использовал термин «объект» для этой темы, потому что из-за этого многие люди фокусируются на меньшей из идей.
  • Большая идея это «сообщения». Ключ к созданию хороших масштабируемых систем это проработка механизмов общения модулей, а не проработка их внутренних свойств и поведения.


Вот вам пример.
Есть объект:
  • Прямая
У объекта Прямая есть 2 "разъема":
  • Прямая.Начало
  • Прямая.Конец,
куда может "подключится" любой объект, удовлетворяющий правилам:
  • при получение запроса "Сообщи свои координаты, N = 5, Формат = double" от объекта Прямая объект, подключенный в "разъем" Прямая.Начало/Конец должен ответить N числами типа double.
Допустим в нашей задаче N - размерность пространства в котором расположен объект Прямая. Все.

Любой объект, какой бы структурой и функционалом он не обладал, может подключиться к нашему объекту Прямая в "разъем" желаемый разъем и исполнять роль составного компонента объекта Прямая, если он удовлетворяет заданному объектом Прямая условию. Это может быть объект Многоугольник, который по запросу предоставит координаты какой-нибудь своей вершины , это может быть ГенераторСлучайныхЧисел, возвращающий по запросу N случайных чисел, это неважно, важно что требуемые условия выполняются.

Если изменятся требования объекта Прямая, то:
  • Если составной компонент продолжает удовлетворять условиям - работаем дальше
  • Если нет - тогда в объекте Прямая описано дальнейшее поведение.

Вот это и есть ООП. Не "шаблоны и иерархия для структурирования и мнимых красоты и удобства кода", а реальные сущности-объекты, взаимодействующие между собой.

А то что вы подразумеваете под ООП как алгоритмы структурирования кода и удобства разработки - это не ООП.
  • Инкапсуляция - полезна во всех подходах и не зависит от поддержки ООП, это управление видимостью и доступностью (namespace-ы и т.п.).
  • Наследование так или иначе сводится к полиморфизму, просто там где есть поддержка "ООП" - это не надо "имитировать" вручную, оно имитируется на уровне фреймворка. Причем сама идея наследования - самое плохое в ООП. Изменяя что-то на определенном уровне - ты никогда не можешь быть уверен, что наследники сохраняют корректное поведение. Не зря Банда Четырех (казалось бы, проповедники ООП) в своей книге рекомендуют при возможности заменять его на делегирование.
  • Полиморфизм же живет независимо от ОО подхода, и опять же единственная польза именно от "ООП" - предоставление "декларативных" возможностей фреймворка, поддерживающего это "ООП" для более удобной работы с кодом... Но работа с кодом - приоритет синтаксиса и его анализатора, а парадигма, опять же повторюсь - особый взгляд на организацию обмена и обработки данных, синтаксис языка и удобство работы с кодом тут не причем, это отдельный компонент.
  • Если же преимущество ООП в повторном использовании кода, то опять причем тут сама парадигма!

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

    Хотя иногда объектно-ориентированный код действительно годится для повторного использования, таким его делает вовсе не объектно-ориентированность, а программирование в стиле „снизу вверх“. Возьмём, например, библиотеки: их можно подгружать и повторно использовать сколько угодно, потому что, по сути, они представляют собой отдельный язык. И при этом, совсем неважно, написаны ли они в объектно-ориентированном стиле или нет.

12. BigB 191 25.07.16 14:11 Сейчас в теме
(0) Без обид, но это бред какой то
Dmitrij-2; cleaner_it; +2 Ответить
14. adam26 42 26.07.16 02:32 Сейчас в теме
Уважаемые читатели, я не готов дискутировать на тему зачем ООП в 1С. Тем более что ВСЕ кто кодит в 1С используют "Lite" версию ООП в своей работе. Так например Любой справочник (например Организации) который вы создаете, является потомком класса Справочники у которых есть общие свойства и методы. Но вот сделать своего потомка от готового справочника у Вас увы не получится. Что касается других языков программирования, то написание на них модулей в стиле ООП действительно помогает, но встроить их в 1С можно только как внешние модули, а для некоторых решений с точки зрения политики безопасности и администрирования это не допустимо.
И последнее, те кто обратил внимание только на "Недостатки" должны попробовать полноценный ООП для того что бы понять его достоинства.
22. ToTMoM 27.07.16 10:10 Сейчас в теме
(0) Я просто оставлю это здесь...
https://habrahabr.ru/post/141505/
https://habrahabr.ru/post/141477/
LuxVeritatis; fzt; kraynev-navi; papami; dj_serega; adhocprog; +6 Ответить
25. adam26 42 27.07.16 10:48 Сейчас в теме
(22) ToTMoM, Смешно! Однако когда у Вас возникает вопрос о том как нарезать хлеб, батон, торт, пирог, пиццу, и так далее вы наверно задумаетесь как реализовывать этот процесс. Делать универсальную Резку или для каждого вида хлебобулочных изделий описать свой способ этого процесса (или наследовать его от предка). Вопрос ведь в том что резать можно так: Изделие.Нарезать() и не важно какое это изделие хлеб, батон, торт и так далее. А можно так как: УниверсальнаяРезка(Изделие). Это разные подходы к программированию.
Мне вот интересно как бы вы реализовывали с помощью "УниверсальныхРезалок" работу с графикой? Где есть такие различные фигуры как круг, прямоугольник, многоугольник и так далее. Вы бы тоже делали "УниверсальныйЗакрашиватель()" , "УниверсальныйРасчетПлощади()", "УниверсальныйРасчетВерхнегоЛевогоУгла()" и так далее?!...
28. ToTMoM 27.07.16 11:51 Сейчас в теме
(25) Дело в том, что изначально объекты в ООП задумывались не как "полиморфизм, наследование, инкапсуляция", а как типа реальные объекты, которые посылают друг другу потоки данных и т.п. Т.е. как есть внутренности(как и у человека), и есть внешний интерфейс, и посредством внешнего интерфейса они общаются...Все. Просто есть процессы, привязанные к объекту, осуществляемые самим(!) объектом, типа Кошка.Прыгнуть()... А есть процессы, которые КТО-ТО ДРУГОЙ выполняет НАД объектом...

Вы же не делаете микроволновку к каждому виду продукта...У вас есть продукты, есть микроволновка и есть алгоритм их взаимодействия. Т.е. вы должны у для конкретного Овощ описать ИНСТРУКЦИЮ для приготовления (в нашем случае для разогрева), а нагревать Овощ должна Микроволновка...
Микроволновка.Нагреть(ЭтотОвощ,ЭтотОвощ.ПолучитьИнструкциюПриготовления("НагревВМикроволновке")).

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

Т.е. изначально это задумывалось как независимые объекты которые друг другу что-то передают, просят что-то с этим проделать и получают назад результаты. В некотором смысле Контрактное программирование с потоками данных между независимыми объектами.
А нынче, мало того что пропускают Микроволновки и заставляют Овощи греться самим, описывая внутреннее декларативное преобразование Овоща, а отнюдь не взаимодействие объектов...Так еще и наследуют Прямые от Точек, механизмы(а не "инструкции по") отрисовки Точек располагают в самих Точках, так еще и наследуют эти механизмы отрисовки к Прямой...

Вот есть например Точка, есть Прямая, это два независимых объекта. Объект Прямая объявляет: я могу состоять из двух объектов, которые подадут мне по моему запросу n-чисел типа double, где n = текущей размерности пространства, в котором я Прямая нахожусь. Если такие объекты есть и они выполняют наши договоренности - то я могу делать то-то и то-то. Если они не выполняют - то я могу делать только то-то, например сообщить об ошибке или еще что-то. Но это не родитель и предок, это один независимый объект, и второй объект, имеющий в составе другие объекты и зависящий от их поведения...
29. ToTMoM 27.07.16 12:03 Сейчас в теме
(25) что касается вопроса ОРГАНИЗАЦИИ ТЕКСТА КОДА и работы с ним, то тут нужно именно средство ОРГАНИЗАЦИИ ТЕКСТА КОДА.

Т.е. если методы повторяются, то явно в коде они не должны дублироваться, но ДЛЯ ПРОГРАММИСТА при желании они должны отображаться как дублированные. И программист, меняя метод ИЗ ЛЮБОГО МЕСТА ПРОГРАММЫ, включив режим "Отображение дублирования" указывает, меняет ли он поведение САМ МЕТОД, т.е. для всех, или он меняет ПОВЕДЕНИЕ этого метода для этого конкретного Объекта либо группы Объектов.

В итоге средство анализа синтаксиса САМО должно создать новую вторую, измененную процедуру и заменить вызовы у указанных объектов и в указанных местах. А иногда и далее САМО проанализировать код этих двух процедур, найти ОБЩУЮ часть, вынести её в новый метод и обернуть первые две процедуры, посредством вызовов третьей с разными параметрами либо еще как-нибудь...И все.

НО это все должно САМО делать средство синтаксического анализа кода. А программист в каждом конкретном месте должен мочь видеть не только обертки и вызовы функций и потом нажимая F12 скакать по ним, он должен мочь включить режим "Развернуть первый уровень вызовов" и увидеть в данном месте полный, реально выполняющийся код...И потом, если надо, внести изменения прям тут. А средство синтаксис. анализа должно САМО эти изменения преобразовать...

Вынесение общих процедур, наследование методов и дублирование кода - всем этим должно заниматься средство анализа, а не программист. Цель работы программиста - в работающем алгоритме, а организацию и удобство внесения изменений в код, структурирование обобщением и обертками должно выполнять специально обученное средство.
А суть ООП в данном случае - как классно что можно повесить все это на программиста! ...
31. vadim1011985 99 27.07.16 12:46 Сейчас в теме
тут то и важно, откуда идешь. Если идешь от корней к листьям, то при неправильно предсказанном корне надо не просто "трансформировать", а иногда и полностью выкинуть весь последующий код, так ты предположил - а жизнь оказалась другой


А можно просто в нужном классе переопределить или скрыть нужные методы что существенно сокращает время работы )) В этот и удобство ООП.
33. ToTMoM 27.07.16 13:09 Сейчас в теме
(31) vadim1011985, например, у тебя был класс Двигатель, у него были некоторые конструктивные внутренние части и механизмы работы с ними, например датчики температур, система подачи топлива и т.д.
Теперь у тебя появляется ЭлектроДвигатель. В принципе в данном случае можно расширить доступные типы Топлива, доопределить механизм работы "Системы подачи топлива" с учетом нового типа топлива "Электричество", но а во всем остальном? Просто добавить новых конструктивных элементов присущих ЭлектроДвигателю и скрывать другие части в зависимости от типа? Типа если это ЭлектроДвигатель, то явно я у него не увижу цилиндров и поршней, но по факту они есть? мдя...

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

И так каждый раз)
34. vadim1011985 99 27.07.16 13:31 Сейчас в теме
(33) ToTMoM,

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


Не совсем если на примере то можно объяснить так например есть класс TPoint c полями f_X f_Y и F_Color и Методом Paint (X,Y) и свойство SetColor который по заданным координатам закрашивает точку по заданному цвету

От него наследуется Класс TLine первоначально все методы и свойства этого класса открыты но например я не хочу что бы линия меняла цвет поэтому метод setColorя помещаю в секцию Privat и уже для класса TLine Этот метод недоступен. т.е. а Метод Paint (X,Y) переопределяем таким образом что он строит линию закрашивает точки от одной координаты до другой - таким образом образуя линию


Инкапсуляция

Инкапсуляция (encapsulation) - это механизм, который объединяет данные и код, манипулирующий зтими данными, а также защищает и то, и другое от внешнего вмешательства или неправильного использования. В объектно-ориентированном программировании код и данные могут быть объединены вместе; в этом случае говорят, что создаётся так называемый "чёрный ящик". Когда коды и данные объединяются таким способом, создаётся объект (object). Другими словами, объект - это то, что поддерживает инкапсуляцию.

Внутри объекта коды и данные могут быть закрытыми (private). Закрытые коды или данные доступны только для других частей этого объекта. Таким образом, закрытые коды и данные недоступны для тех частей программы, которые существуют вне объекта. Если коды и данные являются открытыми, то, несмотря на то, что они заданы внутри объекта, они доступны и для других частей программы. Характерной является ситуация, когда открытая часть объекта используется для того, чтобы обеспечить контролируемый интерфейс закрытых элементов объекта.
32. v3rter 27.07.16 12:50 Сейчас в теме
Изначальное предназначение ООП - упрощение однородных действий над разнородными объектами. Уменьшая на несколько процентов быстродействие, ООП в разы ускоряет разработку и поддержку.

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

И если за десятки лет существования среды в ней не стали реализовывать ООП, то причины явно не в невозможности реализации.
Для повышения порога входа для всех - начинающих и программистов из других экосистем, чтобы не снижать капитализацию, например. Или для поддержания стоимости разработки на определенном уровне. Или придумайте сами.
36. alex_sayan 27.07.16 15:48 Сейчас в теме
А чем, собственно, ООП будет полезно в рамках 1с?
38. karapuzzzz 63 28.07.16 02:01 Сейчас в теме
Зачем так издеваться над собой? 1С придумана для удешевления готового продукта. В SAP есть чистый ООП. Но стоимость внедрения/владения 1С в разы меньше. И именно такими жесткими мерами и был достигнут такой результат. "Дорогие" программисты на с++ создали продукт, который позволить делать готовые решения используя более "дешевых" программистов.

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

P.S.: Я анализировал 1С на присутствие ООП и понял, что все элементы в нем есть. Это и наследование (когда создается новый справочник, то он наследует методы, присущие справочнику). Есть классы "Структура", "Соответствие", "Таблица значений", которые являются явным примером применения инкапсуляции и полиморфизма. И хоть программист не может создвать перегруженные функции, но в 1С такие используются. Например, функция "Скопировать" таблицы значений. Можно передать Перечень строк и колонок, а можно структуру, содержащую параметры отбора. 1С это ООП, но с ограничениями для разработчика.
alex_sayan; +1 Ответить
39. vadim1011985 99 28.07.16 09:09 Сейчас в теме
(38) karapuzzzz, я бы сказал что 1с это результат ООП . Про наследование я бы поспорил, так как при создании справочника вы создаете очередной объект класса "Справочник" которому присуще свои поля (Наименование и код) , методы (НайтиПоКоду , НайтиПоНаименованию и т.д) и свои свойства о наследовании тут речи нет. Тоже касается и структур и соответствий вы создаете объекты некоторых классов и работаете с ними.
41. v3rter 28.07.16 13:43 Сейчас в теме
(38) karapuzzzz,
1С придумана для удешевления готового продукта.
Не думаю. Стоимость продукта зависит от платежеспособности целевой аудитории.
Качество продукта зависит от объемов бюджетов на его обслуживание, на которые готова целевая аудитория.
42. alex_sayan 29.07.16 06:00 Сейчас в теме
(41) v3rter,
Не думаю. Стоимость продукта зависит от платежеспособности целевой аудитории.

Не обязательно. Более-менее объективной системы оценки-то не существует. Я несколько раз сталкивался с решением одной и той же задачи (скажем, развитие существующего функционала в уже готовых решениях) на разных платформах (1с и другие), стоимость которых жутко различалась. Причём разница в стоимости была не однозначной: ни 1с, ни другая платформа не претендуют на звание "всегда дешевле". Были и архидорогие реализации на 1с против довольно дешёвых на другой платформе, была и дешевая реализация на 1с против дорогой на другой платформе. Два случая можно отнести к грамотному впариванию (при этом нельзя сказать, что впаривалось особо жирному клиенту, у которого денег куры не клюют). Думаю, что всё дело тут в подходах менеджмента. Боссы, курирующие проекты, часто поступаются принципами научного менеджмента, и пренебрегают поиском и изучением альтернатив. Если бы они, прежде чем пускать разрабов в свой огород, удосужились прибегнуть к оценке стоимости работы другими разрабами, то и стоимость, возможно, была бы совсем другой.
43. adam26 42 01.08.16 01:51 Сейчас в теме
Все это время не было возможности писать ответы, но читал с большим удовольствием. Многое было переосмыслено (за это Огромное спасибо ToTMoM).

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

1. Данная методика позволяет спокойно манипулировать данными как на клиенте, так и на сервере.
2. Созданные «Объекты» имеют признак инкапсуляции и как говорилось в комментариях «полезна во всех подходах».
3. В данном случае следствием инкапсуляции является полиморфизм.
4. И, к сожалению, если необходимо наследование его нужно имитировать вручную.

Методика позволяет с указанными ограничениями работать в стиле ООП. Для тех кто придерживается другой точки зрения, данный пост позволяет нестандартно манипулировать данными в своей работе.
44. Артано 760 01.08.16 02:06 Сейчас в теме
Методика, конечно интересная, но как уже отписались выше, в 1С есть менее затратные средства тоже приближенные по духу к ООП. Это и обработки, и модули предопределенных объектов. Разумеется большая часть средств уже зашита в платформу в качестве предопределенных классов, но это лишь специфика среды разработки.
С реальной, а не религиозной потребностью в чистом ООП в 1С сталкивался лишь тогда когда пытался на ней решать нетиповые для платформы задачи. Например, когда писал игрушку для бухов
45. pro1c@inbox.ru 185 01.08.16 21:42 Сейчас в теме
да не надо для учетной системы ООП!
не надо!
46. el-gamberro 56 22.08.16 08:19 Сейчас в теме
ООП это простой другой путь мышления и соот-но архитектуры приложения.
В 1С мы имеем чистый процедурный подход и пытаться пристроить сюда ООП бессмысленно.

ЗЫ Я видел приложения на андроид/джава после процедурщиков.
С точки зрения ООП жуть берет. Писать на джава в духе процедур это тоже известная проблема.
47. Артано 760 22.08.16 09:03 Сейчас в теме
(46) Вы озвучили ключевую фразу. Скомпилирую её до утверждения "ООП это (в первую очередь)- тип мышления". Отсюда мы придем к тому, что даже в турбо-бейсике, можно использовать идеологию ООП. Я конечно утрирую, но привычки и подход к работе кочуют за человеком, а не языком (средой разработки). Лишь долгая работа в какой-то среде, может привести к пониманию духа и "родного" стиля инструмента.

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

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

Отсюда же следует, что проблема "в 1С нет ООП" исходит от разработчиков изучивших конкретный (отличный от 1С) инструмент, но не постигших суть ОПП. Отсюда и костыли, ненужные в такой предметно-заточенной среде как 1С, и несбывшиеся ожидания. Об этом я и писал уже, менее развернуто в (44).
48. pro1c@inbox.ru 185 29.08.16 14:03 Сейчас в теме
(47) Артано,

Ню-ню... высшая каста прямо программисткая...
..."не постигших суть ОПП"....
:))))
49. Артано 760 30.08.16 02:37 Сейчас в теме
(48) Нет, я всего лишь двигаюсь в направлении первичности понимания принципов, над отдельными фактами. И это не только к программированию относится. Использование любого инструмента, будь то методика анализа, среда разработки, даже лопата, в конце концов, без понимания фундаментальных принципов просто сведется к запоминанию "куда надо нажать чтобы заработало".
50. pro1c@inbox.ru 185 01.09.16 13:49 Сейчас в теме
(49) Артано,
"в направлении первичности понимания принципов, над отдельными фактами" :)))) - 1С не лучший помощник в этом!
Вы не в ту сторону двигаетесь! (уж извините) :))

некоторым очень не хватает умения: "куда надо нажать чтобы заработало"!
:)))
51. Aphanas 92 16.02.17 09:30 Сейчас в теме
Суть ООП в полиморфизме. При процедурном подходе полиморфизм невозможен. Полиморфизм - это, по сути, управление потоком выполнения - код, который будет выполнен в результате вызова функции, определяется не в функции, а вне её. Это позволяет манипулировать абстракциями высшего порядка. Вот и всё.
Наследование - это специфическое и довольно странное средство обеспечения полиморфизма, инкапсуляция - пустышка и ересь.
54. v3rter 09.03.17 11:19 Сейчас в теме
При процедурном подходе полиморфизм невозможен.
Почему невозможен? Если доступен eval() | Выполнить(), то очень даже возможен, другое дело, что со скоростью интерпретатора. И даже когда eval недоступен, доступны гигантские CASE | ЕСЛИ ИНАЧЕЕСЛИ ИНАЧЕЕСЛИ ... КОНЕЦЕСЛИ, то есть возможен, но с "костылями". ООП перекладывает это на уровень компилятора. А вот написание кода в стиле описания объектов и переопределения методов изначально было побочным эффектом, который настолько всем понравился, что превратился в основной, оброс идеологией, методологией и вошел в учебники )
Оставьте свое сообщение