1С+Классы. Версия-0

0. IntelInside (G) (IntelInside) 126 27.10.16 17:24 Сейчас в теме
Разработано ООП-расширение языка 1С, включающее (но не ограничивающееся):
Классы как абстрактные типы данных с элементами «переменная», «свойство», «функция», «процедура»; Интерфейсы как абстрактные классы без элементов состояния («переменная») и без привязки к реализации методов (свойств, процедур, функций) при определении; Имплементация (реализация) интерфейсов классами;
- одиночное открытое наследование; Области видимости «внутренняя» (private), «экспорт» (public), «защищенная» (protected); Статические элементы классов (общие для всех экземпляров класса); Замещение (переопределение реализации) методов при наследовании – «виртуальные методы, свойства»; Сокрытие (затенение) обычных (не замещаемых) элементов при наследовании; Перегрузка процедур и функций по количеству и типам данных аргументов; Конструкторы класса; Деструктор класса; Слабые ссылки; Делегаты.

Перейти к публикации

Комментарии
1. Алексей Апанасович (Aphanas) 113 28.10.16 11:21 Сейчас в теме
Когда-то пытался реализовать подобие ООП на Windows Script Component (WSC), язык использовался JScript. Определения классов задавал похожим образом, только использовался синтаксис WSC (т. е. XML, по сути).
Бросил, когда понял, что если делать ООП, то это нужно делать с возможностью наследовать штатные объекты 1С. Да еще желательно так, чтобы получившиеся потомки могли быть использованы вместо штатных объектов (т. е. в качестве параметров стандартных функций и т. п.). Кроме того, при использовании COM, нужно забыть про кроссплатформенность, а также про веб-клиент, что весьма печально.
Однако, это лишь мой личный выбор, Бывают задачи, когда ООП реально не хватает. Согласен насчет мышления в стиле ООП. Каскадные вызовы общих модулей в типовых конфигурациях - ничто иное как суррогатная замена некоторых механизмов ООП.
Успехов, видно проделана большая работа.
dj_serega; JohnyDeath; ybatiaev; CyberCerber; Lem0n; +5 Ответить
3. IntelInside (G) (IntelInside) 126 28.10.16 13:51 Сейчас в теме
(1) Aphanas, Спасибо. Успех, удача и все что их сопровождает мне бы очень не помешали.
Относительно поддержки штатных объектов 1С - это пункт <задумано-но-не-сделано>::<поддержка-наитивных-...>. Технически это не составляет большого труда в отношении основных объектов (Массив, Структора, Запрос, т.д.). Все (практически все за редким исключением) объекты 1С поддерживают COM-аггрегирование. Это будущая конструкция Класс МойМассив НАСЛЕДУЕТ 1С.Массив. Здесь нужно понимать, что 1С.Массив это объект реализующий не один интерфейс. Как минимум на первых порах поддержки сериализации не будет (см.ниже). Другая возможная конструкция Класс МойМассив НАСЛЕДУЕТ ИНТЕРФЕЙС 1С.Массив. Реализацию такой конструкции можно начинать делать хоть сейчас и все встроенные методы 1С, которым нужен только интерфейс массива не отличат это от родного массива. Не сделал это в версии-0 только потому, что это увеличит связность с платформой. На данном этапе мне хотелось бы "расшириться" на разные версии платформы, разные ОС и т.д. Вычухать баги. Обрасти юнит-тестами и только потом "углубляться".
ПС: код 1С уже не отличает где класс компоненты имитируюший к примеру Структуру, а где Структура 1С. В демке это есть. Моя технология родная для 1С. Ну почти-почти родная..
Относительно кроссплатформенности я не до конца понял.
Если имеется ввиду .so для линукса и т.д., то плюсы работают везде где есть процессор. Можно хоть сейчас начинать готовить выпуск для STM32 и через n времени оно откомпилируется. Линукс это моя первоочередная задача. С Андроидом посложнее (и это вызов!), но тоже возможно. Но это будет версия-зависимый эксклюзив.
Если имеется ввиду поддержка клиент-серверных возможностей 1С, то это а) поддержка наитивных интерфейсов сериализации. б) регистрация некоторых объектов во внутреннем реестре 1С и, естесственно, загрузка компоненты на всех машинах. Все решаемо. Это я планирую для версии-1. Пока просто рано тратить время. Пока на боевой сервер мою компоненту не будут грузить не потому что она что-то не поддерживает. Надо достичь стабильности и доверия.
Спасибо.
4. Игорь Steelvan (Steelvan) 31 28.10.16 14:27 Сейчас в теме
(3)

Жесть, насколько тяжело читается текст последнего вашего сообщения.
Попробуйте меньше использовать "не" и текст сразу станет чище и понятнее.
http://foolks.org/samorazvitie/psixologiya-vliyaniya-negativnye-chasticy-ne-ne-ispolzovat-chasticu-ne/
2. bulpi bulpi (bulpi) 124 28.10.16 13:18 Сейчас в теме
Плюс поставил. Автор, конечно , гигант, но...
1)Хотел бы я иметь столько времени для всякой фигни :)
2)Все эти "игры разума" никак не помогут для внедрения 1с в жизнь реального предприятия. Впрочем, сильно и не помешают.
5. Vladimir Vasiliev (vasvl123) 67 28.10.16 15:59 Сейчас в теме
А отдельно от платформы работает? Например из 1script?
6. c+ + (ture) 231 28.10.16 16:45 Сейчас в теме
(0) Зачем?

Код ООП красив в первую очередь наглядностью и уже потом своей парадигмой конструирования решения. Цена тоже известна - огромное количество переходов (вызовов функций и возвратов из них). Ваша реализация обещает только второе, но кому? Тем, кто не силен в процедурном программирование или у него ООП головного мозга? Аналогичное решение на 1С77 было изящней, но программисты 1С избегали и его всеми силами.
kuzyara; klimsrv; awk; Spacer; CyberCerber; +5 Ответить
7. IntelInside (G) (IntelInside) 126 28.10.16 21:21 Сейчас в теме
(6) ture,
OOP, or not OOP: that is the question!
... but baltik number nine my best suggestion!
dgolovanov; +1 Ответить
10. Олег Николаев (o.nikolaev) 205 29.10.16 14:00 Сейчас в теме
21. Юрий Батяев (ybatiaev) 42 31.10.16 15:28 Сейчас в теме
(6) ture, напишу свой взгляд на проблему
ООП головного мозга

1С приближается к международному стандарту программирования, что уже радует.
И написать советы ЧТО надо бы сделать не приветствуются ни самими разработчиками 1С, ни сообществом обученных процедурному программированию.
Желания клиентов, не в расхождении с законом, всегда было в приоритете. Есть желание - должно быть простое решение. Точнее те, у кого "ООП головного мозга" видит решение в 3-5 строчек кода. Но в связи с процедурным программированием сделать ПРОСТО не получается. Рефакторинг хорошая штука, но в итоге код получается СОВСЕМ НЕ ЧИТАБЕЛЬНЫМ. Те, кто владеет ТОЛЬКО процедурным программированием ограничен и в решениях и в мышлении. И это навязывается при обучении как истинно верное решение. И потом все программеры с заложенным в них процедурным программированием думают, что все дураки (это моё мнение!!!).
Сколько сам писал предложений, всегда говорил, что вот вам идеи бесплатно, но, кроме минусов, ничего. Хотя спустя год-два к этому приходят. Вот написал предложения к расширениям. Минусов куча, но вот внедрили же условие КОГДА доп код запускаться ДО или ПОСЛЕ основного кода. Но изврат расширений так и остаётся. Да, будут "удобства", но если не в том направлении развивается, то зачем развивать именно неправильное направление?
25. c+ + (ture) 231 31.10.16 18:26 Сейчас в теме
(21) Скоро, товарищ, скоро мы увидим как 1С сделает свободные тейблы и предложит самим написать классы, для работы с ними. Смекаешь? (так во всех ерп делают сегодня, а велосипед 1С некогда изобретать).

Классы в 8.4? На подлете точно, или рынок так и не увидит ЕРП от 1С, стоящую на ногах.
pvlunegov; +1 Ответить
8. Олег Соловьев (Solovyeff) 29.10.16 01:38 Сейчас в теме
9. Олег Николаев (o.nikolaev) 205 29.10.16 13:56 Сейчас в теме
За работу ставлю плюс конечно, но... в реальных больших проектах это использовать? Вряд ли... Как задел на будущее? Ну не знаю. Без платформенной поддержки это, на мой взгляд, так останется любопытным концептом. Очередной "вариацией на тему", не более.

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

ООП 1С-ке не хватает-не хватает, это видно по тому же ЕРП 2, где средство (язык & инструментарий-конфигуратор) перестали справляться со сложностью продукта и по исходным кодам видно, как команда мучительно пытается что-то с этим сделать. Рецепта, кроме как повышения уровня абстракции, а в данном случае это ООП, нет. Но позвольте, ЕРП 2 только-только задышала, а тут что, опять переписывать? Да никто не пойдет на это, и я прекрасно понимаю почему. Потому что это адЪ. Но пытаются, пытаются конечно хоть что-то сделать. Вон и определяемые типы данных ввели. Видимо задел под ОО? Ну, пожмем-увидим, как говорится.

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

Сейчас народ изгаляется кто как может и кто во что горазд. В кодах одной фирмы, которая занимается ЭДО (не скажу какой) формы обработки сделали "типа классы" и в таком микс-стиле написали все. Работает? А то. Но поддерживать и дорабатывать это? 8-(

В общем, согласно тезиса Великого Кормчего, "расцветают все цветы" и "соревнуются тысячи школ мысли" в бесконечной и неравной борьбе аристотелевой бинарной логики со сложностью квантового реального мира. Но, увы, "серебряной пули" пока нет как нет.
sandybaev; dj_serega; BigB; brr; CSiER; +5 Ответить
11. Константин Гейнрих (CyberCerber) 165 29.10.16 14:41 Сейчас в теме
Насколько я люблю, и насколько мне не хватает ООП в 1С, но ваша разработка меня не воодушевила.
Как уже говорили выше, ООП должно давать легкое понимание и читаемость кода, а здесь этим и не пахнет.
А вообще, мне, например, ООП в 1С нужно, чтобы не создавать какие-то свои классы "Здрасьте", а наследовать существующие объекты платформы, и тем более объекты конфигурации.
Вот как порой не хватает возможности взять и наследовать исходный документ или обработку... Например, есть КассовыйОрдер, а от него Наследуются ПКО и РКО. Сейчас приходится просто заниматься копированием. 1С сделала хоть небольшой шажочек в эту сторону - Расширения, но хочется полноценного наследования.
Плюс поставил, так как очень уважаю таких энтузиастов, которые хотят сделать продукт лучше, но, боюсь, настоящего решения можно ждать только от 1С.
dj_serega; JohnyDeath; amoarok; SunShinne; HAMMER_59; Spacer; CSiER; +7 Ответить
12. Артём Андриянов (CSiER) 15 29.10.16 18:15 Сейчас в теме
За идею и реализацию однозначно плюс! Проект интересен. Планы серьезные (чистое множественное наследование это плохо и не нужно, но это имхо конечно ☺). За всем этим пока не вижу глобальной идеи - положим, появилась на свет стабильная версия (с дженериками, интернал/экстернал интерфейсами, лямбдами, тонной синтаксического сахара и другими прелестями) - какой профит это даст рядовому разработчику (возможность дополнить типовую коллекцию своим итератором и т.д. это хорошо, но хочется большего)? Хорошо, предположим, что образовалось коммьюнити, которое активно будет переносить базовые алгоритмы и структуры данных «от больших братьев» (от хешмэпов из Java, до leftpad из ноды ☺), но ведь вендор этого не поддерживает. Каким Вы видите проект в будущем (как он будет развиваться в прикладном смысле для рядовых 1сников)?
CyberCerber; +1 Ответить
13. Артур Аюханов (artbear) 915 29.10.16 19:14 Сейчас в теме
Автору респект. Но название 1С++ давно захвачено :( с 2001 года продукт существует
22. IntelInside (G) (IntelInside) 126 31.10.16 17:24 Сейчас в теме
(13) artbear, Спасибо за замечание. Само вырвалось. Вообще-то я это учитывал и в коде и в документации использовал везде 1С+классы. С картинкой вообще дурацкая история - редактор Инфостарт не хочет принимать статью без логотипа. Когда я скармливал ему первую статью, то уперся в это в последний момент и пришлось буквально на ходу фотошопить. А к второй статье подзабыл и пришлось старую вставлять. В названии статьи как-то само вырвалось. Отредактирую и текст пересмотрю. Картинку как доберусь до фотошопа переделаю на один плюс. Итак - проект называется 1С+классы. Картинка 1С+. Если, бог даст, будут у меня еще проекты то они будут идти под этой картинкой и именоваться 1С+<вербальное-имя-проекта>. Еще раз прошу прощения. Надеюсь на этом инцидент будет исчерпан.
Спасибо.
14. DenisCh Гейтс (DenisCh) 29.10.16 19:58 Сейчас в теме
Почитал. Ещё раз убедился, что в проблемно-ориентированном программировании (каким является 1с) - ООП нужен до уровня ширинки.
Сурикат; +1 Ответить
15. Владимир Snegnii (tradeagent) 30.10.16 21:57 Сейчас в теме
Автор, прошу простить меня за сказанное далее. Но получившийся у вас код выглядит ужасно не читабельно по отношению к привычному типовому коду 1С. Я бы от поддержки такого кода всеми силами бы старался отказаться. Ничего плохого про самое решение сказать не могу.
CyberCerber; +1 Ответить
16. eugenie zheludkov (eugeniezheludkov) 33 31.10.16 06:48 Сейчас в теме
ОФФТОП: Всегда ненавидел эти Си++ заголовочные файлы где сначала обьявляют, что будет (нет не интерфейс, а именно тупо обьявление что будет реализовано), а потом в ЦПП файле реализация. Если хочешь добавить новый метод, приходится добавлять его дважды, неудобно и нечитабильно ИМХО. Когда пишу что-то свое с нуля то пишу этот класс в одном .h файле и не парюсь.
38. IntelInside (G) (IntelInside) 126 02.11.16 18:36 Сейчас в теме
(16) eugeniezheludkov,
:) Вся компонента так написана. Пока. Но придет черед сурового gcc и придется рефакторить. Но это даже хорошо. Чем больше рефакторишь, тем меньше кода. А чем меньше кода, тем меньше глюков.
39. eugenie zheludkov (eugeniezheludkov) 33 07.11.16 10:18 Сейчас в теме
(38) так я как -раз в суровом gcc и компилю где у меня .h файл сразу же содержит реализацию класса без объявления этого не наследуемого "недоинтерфеса"
17. Андрей Овсянкин (Evil Beaver) 4759 31.10.16 10:44 Сейчас в теме
автор просит, всех кто находит предложенную технологию интересной и полезной, о пожертвовании на ее разработку и совершенствование


Я бы с удовольствием, но как мне понять - полезная ли это технология? Пока я читал статью, у меня взорвался мозг. И это при том, что я знаю, что означает "sizeof(uintptr_t)" и "virtual call".
Можете пояснить в двух словах, как мне (абстрактному "мне") это пригодится в жизни? ООП в 1С само по себе сомнительная штука, но даже если оно и нужно, то код из примеров вызывает у меня кровь из глаз.

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

А так - очень круто, я помню еще первую вашу статью по внедрению в 1С:Платформу. Теперь бы эту энергию да в мирных целях куда-нибудь применить ))
JohnyDeath; eugeniezheludkov; awk; CyberCerber; +4 Ответить
20. IntelInside (G) (IntelInside) 126 31.10.16 14:01 Сейчас в теме
(17) Evil Beaver,
За пример к статье мне похоже нужно начинать извиняться. Это была попытка пошутить и, по видимому, неудачная. Вдохновением мне послужила шутка <Hello World Enterprise Edition> на java. То есть это не просто ООП, а его наихудшее enterprise проявление. Я только попытался придать хоть какой-то практический смысл этому нагромождению классов. Также хотел продемонстрировать использование паттернов, но код начал катострофически разрастаться - не для статьи. В дальнейшем примеры буду перефразировать отсюда <Паттерны проектирования в ABAP примерах>. Но это уже цикл из 20-30 статей. Ко всему прочему это действительно первая программа для этого языка. До этого были только отдельные тестовые пописульки на колене. Естественно вылезло с десяток ошибок и недоработок, которые приходилось на ходу править. Потом IDE 1С все это не поддерживает. Определения классов и реализацию можно было-бы разнести хоть в разные модули, но в статье все равно их показывать вместе.. Затем редактор Инфостарта все поковеркал перенося длинные строки. В общем АДъ. Поэтому даже название модуля я сделал двусмысленно сокращенным - ОопХелл. На тот момент мне все это казалось забавным. Но более никому это так не показалось и, похоже скоро меня начнут бить подозревая что я над всеми издеваюсь. Поэтому еще раз, официально, приношу извинения за неудачный пример к статье. Постараюсь исправиться.
Теперь почему я все время говорю о языке. Дело в том, что это третья версия. Первая моя попытка была формировать типа классы через некоторое API (продолжение техники из перфой статьи). Вторая - некие самобытные самоконструирующиеся объекты-классы. Типа присвоил значение свойству - и свойство появилось, присвоил делегат - и метод появился. Все это я торжественно отнес на помойку. Это несистемные решения. Такое может пригодиться разве что мне и еще паре гиков. Но уж точно не заказчику\работодателю. Это в высшей степени причудливый велосипед от велосипедиста неотделимый. Поэтому я засел за реализацию ООП с нуля пользуясь только стандартом С++ и своими соображениями относительно синтаксиса и призвания Бейсика, ну и конечно поглядывая на java, vb.net, etc. То что у меня получилось, как мне кажется, это полноценная реализация ООП для COM. Т.е. это то чем должен был бы быть VB7, если бы MS его не угробил. Из этого вытекают следующие следствия.
Перенос кода из/в 1С+, MorphX and X++, ABAP, JAVA, т.д. не требует смены парадигмы и может быть выполнен в (полу)автоматическом режиме плюс напильник. Фактически большая часть проблем будет с библиотекой времени исполнения, но у 1С она уже достаточно развита, а недостающие части можно и дописать. Для .net платформы такие трансляторы c# <-> vb <-> java существуют и выдают неплохие заготовки. Далее. Я не писал вычислительное ядро (ну то что 2+2 считает). Т.е. представленную реализацию можно назвать 1С+классы для виртуальной машины 1С. Но вычислительное ядро может быть любым умеющим делать с++ virtual call. Реализацию потенциально можно выполнять хоть на java, хоть в машинные коды откомпилировать - ironEs.
Следующее следствие. Поскольку компонента реализует полноценный "взрослый" ООП для COM-интерфейсов, то разработчики 1С практически лишены возможности сделать что-то иное. Кратчайшее расстояние между двумя точками есть прямая. Ну разве что в зазеркалье иная метрика пространства и "значение синуса может достигать 4". Т.е. если ООП появится в платформе, то решения возможно будет оттранслировать 1С+ <-> 1Сv9.
Практика наработанная с 1С+ также применима в других языках, программах, организациях, государствах. Т.е. "среднестатистический одинэсник" может стать senior odines developer -ом. С соответствующим ростом ЗП.
Возможна наработка практики и кодовой базы под серверные расширения 1С 8.4.*
Об 1script. Если нас скрестить, то получится вполне себе полноценный и современный новый язык программирования высокого уровня. Тот самый "национальный Бейсик" о котором я упоминал в статье. Как мне кажется это направление имеет самостоятельную ценность. Правда только для .net платформы т.к. 1script написан на и для net.
Вообще мы сейчас имеем странную и парадоксальную ситуацию. У меня есть классы, у 1script виртуальная машина, у Снегопата IDE, у 1С++ 7.7 наработки по ООП. Все это вкупе решает основную проблему 1С - язык. Но сама 1С этого не хочет. Революционная, короче, ситуация. Прямо в смысле марксизма-ленинизма.
Об ООП я чуть позже напишу. Очень вкратце - я не поборник ООП - уменя очень негативный опыт его бездумного использования, но поддержка его есть во всех современных языках программирования. Потом - почему все считают что в 1С нет ООП. Уверяю вас под капотом платформы его столько, что голова кругом идет. Только на данный момент программист его использовать может только валяясь на коленях перед отделом разработки 1С. Можно еще попробовать взятки давать, чтобы они нужный до зарезу класс сделали. Моя же компонента дает возможность сделать класс самому. Набить свою шишку, переделать, сделать лучше. Как я уже говорил взаимодействие с объектами платформы это всего лишь вопрос времени. А для меня (вернее в первую очередь для моей жены) это вопрос денег. Я бы этим только из чувства прекрасного занимался, но нужно быть серьезным - большие дела в одиночку, урывками, вместо сна не делаются. Некоторых своих сугубо личных целей я уже достиг - если нужно высокопроизводительную числодробилку подключить - умею, нужно замысловатую иерархию классов - пожалуйста. Т.е. работать с 1С как с бейсиком я научился. А мечт вообще громадье. Хотя я и подустал, но до некоторой логической точки "версия-1" проект доведу. Вероятно нужно кроме теоретической части сделать еще некоторую практическую опцию.
Спасибо.
PS. Я на все вопросы постараюсь отвечать, возможно только не сразу. Возможно нужно FAQ делать. И еще раз прошу прощения за неудачный пример.
PPS. ООП кстати не все в институте учили и не все вообще в институте учились. Поэтому некоторую нудность прошу потерпеть.
PPPS. Похоже опять в двух словах не получилось..
zhenyat; dgolovanov; CyberCerber; +3 Ответить
52. Алексей Шардаков (gbiperm) 16.03.17 11:22 Сейчас в теме
(20)
Уважаемый, возмите с++ за пример:
Например я хочу:
1. Модификаторы доступа: private, pablic, protect, static
2. Множественное наследование (Представлю как мозги вскипят, когда я в свой класс унаследую от Справочника, Документа, Плана счетов, и Регистра) :)))
3. Хочу перегрузку операторов :))) методов... и стандартных функций платформы...
4. Указатели...
5. unsafe конструкции
6. Динамическу работу с памятью :)

7. Хочу при выстреле в ногу, отстрелить ноги всей команде...

Это шутка... не огорчайтесь...

Но ООП 1С скорее не будет реализовывать...тогда все от нее просто разбегутся...
ООП мне не хватало в 1с77 при интеграции со внешними системами... в 1с8 это поправили...

А что касаемо Java EE 7.
Java Platform, Enterprise Edition, сокращенно Java EE (до версии 5.0 — Java 2 Enterprise Edition или J2EE) — набор спецификаций и соответствующей документации для языка Java, описывающей архитектуру серверной платформы для задач средних и крупных предприятий.

Спецификации детализированы настолько, чтобы обеспечить переносимость программ с одной реализации платформы на другую. Основная цель спецификаций — обеспечить масштабируемость приложений и целостность данных во время работы системы. JEE во многом ориентирована на использование её через веб, как в интернете, так и в локальных сетях. Вся спецификация создаётся и утверждается через JCP (Java Community Process) в рамках инициативы Sun Microsystems Inc.

Каждая спецификация - одна компонента реализующая какую-то логику.
JSF например веб интерфейс на ней хорошо делают.
GlassFish - сервер приложений.
Hibernate - ORM
Spring, JavaFX -- клиенты любых покроев и пошибов...
Только JAVA EE7 это бум считать, если грубо, платформа общего назначения для построения любых приложений.

При этом в 1С8.* стараются такого же подхода придерживаться на текущий момент.
Тот же строго определенный набор доступных компонент(Объектов, уговорили :)) для решения учетных задач, ну еще и аналитики, хотя OLAP я бы уже на платформе 1С не рискнул бы делать, хотя можно извратиться... Т.е. Не все на 1С можно построить :)))
Сервер приложений то же есть...
ORM - присутствует...

А теперь под занавес С++ и простреленная нога:

class Class {
public:
~Class()
{
printf( "Class::~Class()" );
}
};

int main()
{
delete new Class[1];
return 0;
}

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

Я согласен с EvilBear что в 1С 8.* сомнительное удовольствие...

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

З.Ы. изучаю с++
53. Андрей Овсянкин (Evil Beaver) 4759 16.03.17 12:39 Сейчас в теме
(52) а если так?

delete[] new Class[1]; 
54. Алексей Шардаков (gbiperm) 17.03.17 06:32 Сейчас в теме
(53) Все верно. Смысл был проиллюстрировать что начнет твориться, если взять так сказать Junior 1C программиста... И прилепить ООП полное в 9й версии 1С.

Если честно я не совсем чистый С++ изучаю, QT\C++ - можно считать одним из диалектов С++.
Там много потенциально не безопасных моментов убрано.
Если чего-то не хватает то там самые распространенные библиотеки STL и BOOST.

То, что в QT убрали много не безопасных моментов - это меня да же радует.
Но без базовых знаний С++ например указатели, работа с памятью и т.п. мало что пойму.
Так что тихо едем и читаем Страуструпа и решаем упражнения :)

А сточки зрения работы - Системное администрирование.
Иногда приходится на низком уровне писать - утилиты, или например как вариант модули в SQL сервера - MS SQL и PostgreSQL поддерживают такое расширение. Хотя на практике не доводилось.

Если с точки зрения Системы учета от 1С (Платформа + конфа) - то же подойдет QT(ток поставить нужно не забыть) и все что мне от ООП не хватало, тех объектов, то просто зашить их в компоненту на Ntive API. ИМХО.
55. Сергѣй Батанов (baton_pk) 212 17.03.17 10:23 Сейчас в теме
(54) нафиг Си++ ! Golang изучайте!
56. Алексей Шардаков (gbiperm) 17.03.17 12:08 Сейчас в теме
57. Сергѣй Батанов (baton_pk) 212 17.03.17 13:10 Сейчас в теме
58. Алексей Шардаков (gbiperm) 17.03.17 13:24 Сейчас в теме
(57) Хотя бы компоненты писать на Native API остальное за пределами данного ресурса.
Теперь ваш ответ.
59. Сергѣй Батанов (baton_pk) 212 17.03.17 20:50 Сейчас в теме
(58) мой ответ целиком за пределами данного ресурса. если отвлечься от внешних компонент, на го пишется быстрее и очевиднее.
61. Алексей Шардаков (gbiperm) 21.03.17 16:32 Сейчас в теме
(59) Я себе то же немного жизнь упростил. Взял библиотеку QT да многие небезопасные моменты исключены. Да стандарт то же решил взять посвежее С++11 или С++14.

А чтоб писать быстрее и очевиднее - мне питон нравится. Поглядываю в версию 3.*
И таки да в базовой конфе Unix/Linux идет g++ (отнюдь не gcc-go) и питон.
И так с какими ЯП я чаще буду сталкиваться? Ответ увы очевиден.

Еще чтоб писать проще быстрее и очевиднее есть PHP7 в котором подкрутили
Быстродействие...

И да это мое ИМХО.

А так я не проти Go но увы... задач под него нет...
62. Сергѣй Батанов (baton_pk) 212 21.03.17 16:48 Сейчас в теме
(61)
И таки да в базовой конфе Unix/Linux идет g++

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


(61)
И так с какими ЯП я чаще буду сталкиваться? Ответ увы очевиден.

это bash, видимо.

(61)
Еще чтоб писать проще быстрее и очевиднее есть PHP7

слова "PHP" и "очевиднее" и в одном предложении у меня выдают ошибку компиляции, если честно.

Сойдёмся на том, что Qt - отличная штука :) (кстати, есть порт для Go)
65. Алексей Шардаков (gbiperm) 22.03.17 06:49 Сейчас в теме
(62) sh :)

если на PHP писать как положенно с анотациями и т.п. -- т.е. соблюдать правила оформления кода, то вполне читаемо.
И вполне очевидно:) но да вы правы мало кто так делает :))))

Но примерно так же и фирма 1с требует оформлять код.

А про установку ручками - мне лень. чуть ниже отписался.
Ну да есть библиотечка скриптов(все что нужно чтоб получить требуемую мне базу), под те дистрибы которые использу.
Хостится в гите. Кочует со мной же. Выкачал, пересобрал. И раскатал. Притом пересборка просто пройдет рефлекторно наверное.
63. Андрей Овсянкин (Evil Beaver) 4759 22.03.17 01:02 Сейчас в теме
(61) базовый конфиг Unix/Linux это слакварь или, как минимум, гента. Там никакого g++ нет, не говоря про питон. А еще мне тут @nixel2007 показал вариант scratch. Так там даже echo нет. Вот это базовый так базовый.
64. Алексей Шардаков (gbiperm) 22.03.17 06:39 Сейчас в теме
(63) я чаще использую CentOS то же поправил немного сам дистриб :) . Чисто для академического опыта собирал Gentoo ISO. и правил скрипт, для установки нужных пакетов автоматом. Почему чисто академический - так не используется у нас Gentoo. А когда нада один дистриб раскатать на много станций - тут уже ручками не поставить. Да и обновлять проще из локального дистриба. Дома клон убунты - Linux Mint. все что мне нужно робит. Т.к. дома я отдыхаю. Ну если есть у меня желание можно академические опыты с дистрибом поделать. И от одной убунты останется только ядро + php + mysql + apach+iptables - это к тому что из дистриба выпилить можно все что угодно и собрать как угодно.
18. Сергей Рудаков (fishca) 1090 31.10.16 11:10 Сейчас в теме

Функция _Класс_Здрасьте_()
Возврат ""
"Класс Здрасьте"
"Защищен:"
" Конструктор()"
"экспорт:"
" Функция Идентично(другое_), Абстрактная"
" КонецКласса"
""
"Класс ЗдрасьтеТекст Наследует Здрасьте"
"внутр:"
" Перем м_текст"
"экспорт:"
" Конструктор(текст_) := ЗдрасьтеТекст_Конструктор"
" Функция Идентично(другое_), Замещает := ЗдрасьтеТекст_Идентично"
" Свойство Текст ЧТЕНИЕ := ЗдрасьтеТекст_Текст"
"КонецКласса"
""
"Класс ЗдрасьтеЖест Наследует Здрасьте"
"внутр:"
" Перем м_жест"
"экспорт:"
" Конструктор(жест_) := ЗдрасьтеЖест_Конструктор"
" Функция Идентично(другое_), Замещает := ЗдрасьтеЖест_Идентично"
" Свойство Жест ЧТЕНИЕ := ЗдрасьтеЖест_Жест"
"КонецКласса"
КонецФункции
Показать

просто жуть :(

Если так надо определять классы, то лучше не надо дальше что-либо делать.
Лучше взять идеи 1С++ и улучшить их, а не городить огород костылей и граблей(длинных и коротких).
pvlunegov; awk; Evil Beaver; +3 Ответить
26. IntelInside (G) (IntelInside) 126 31.10.16 19:02 Сейчас в теме
(18) fishca, (18) fishca,
Давайте для начала очистим от вынужденных деталей реализации:

Класс Здрасьте
Защищен:
Конструктор()
экспорт:
Функция Идентично(другое_), Абстрактная
КонецКласса
--
Класс ЗдрасьтеТекст Наследует Здрасьте
внутр:
Перем м_текст
экспорт:
Конструктор(текст_)
Функция Идентично(другое_), Замещает
Свойство Текст ЧТЕНИЕ
КонецКласса

То есть я убрал кавычки и детали привязки к реализации. В самом деле, зачем навязывать откуда взять текст определения класса. Программист и сам может загрузить его из файла, вычитать из таблиц БД или получить по почте в конце концов. Идеальным, конечно, является непосредственная запись в модуле 1С. Но это возможно сделать только в кооперации с проектом Снегопат. Или сама 1С это сделает. Я знаю как это делать и делал это для vb6 (он у меня BOOST и препроцессор использовал), но делать все в одиночку не имею возможности.
Относительно указаний привязки к реализации. Да. Загромождает. В последующих версиях, вероятно, придется допустить авто-подключение. Т.е. компонента сама в пространстве имен переданного объекта реализации будет искать методы с именами вида <имя-класса>_<имя-метода>. О формате еще надо подумать. Вынужденное и рискованное странными ошибками решение. Но да. Это :=бла-бла-бла загружают код катастрофически.
О самом определении класса в текстовом виде. Считаю это методологически верным решением. Функция чтения и письма осваивается детьми в самом раннем возрасте и нам наиболее естественно строить мыслеобразы именно читая текст. Война и мир в комиксах это профанация. Это, конечно, не исключает всевозможных визуальных построителей. Также не исключает некоторого reflection-api, которое внутри компоненты есть и тоже развивается. Но так или иначе определение сущности должно иметь текстовое представление.
Далее. За основу выбран синтаксис и дух Бейсика. Это один из старейших языков программирования и его особенностью является выраженная обучающая функция. В Си можно написать АСС ФУУ(БАЗ БАР) и компилятор Вас поймет. Опытному программисту лишние термины типа function, as и т.п. не мешают строить его и именного его мыслеобразы относительно данной и именно данной проблемы. Но это если в голове уже есть из чего строить эти мыслеобразы. В случае чистой и светлой головы мы должны раз за разом повторять Функция Фуу(Бар Типа Баз) Возвращает Асс. И что интересно. Мозг опытного программиста недостающую информацию автоматически восстанавливает, а по мере накопления опыта мозг начинающего излишнюю информацию начинает автоматически опускать. Результат один - мыслеобраз, составляющий минимальную единицу понимания программы. В случае Бейсика имеем выраженный минус - многословность. Но эту проблему должно решать IDE. Бейсик без толкового IDE это нонсенс. Но есть и бонус - если Вы разбираетесь в чужом коде, или в своем ннадцатилетней давности, или, простите, рисуете программку под шафэ, то возможность побуквенно прочитывать начинает помогать. Проверено.
Далее. Описания секций кода. Выделять их тоже является методологически правильным.
...
Впрочем если вкратце, то я готов объяснять если не понятно, отстаивать если уверен, признавать ошибочность своего мнения если докажут. И так далее. Я открыт для общения. Это версия-0. Оно только-только свое первое здрасьте сказало. Впрочем я готов и к тому, что кто-то останется только и только при своем мнении. Это грустно, но это жизнь. В любом случае спасибо.
19. c+ + (ture) 231 31.10.16 11:41 Сейчас в теме
(0) Я придумал, как тебе исправиться и очистить своё доброе имя на инфостаре.
Пишешь код на псевдо 1С (сам придумай разметку или возьми чистый шарп), код запихиваешь в текстовичек, а текстовичек отдаешь своей компоненте, которая вернет тебе экземпляр этого типа (объект класса). И вуаля!

Это будет медленней, чем писать на 1С раз в 100, т.к но это мерзкая гадость сделана намеренно самой 1С, чтоб не делали компоненты. Но! Какого рожна? Скорость в 1С? Не смешите меня. Это прокатит и будет круче поверь, чувак!
23. IntelInside (G) (IntelInside) 126 31.10.16 17:42 Сейчас в теме
(19) ture, Вообще-то компоненту можно попросить скушать чистый шарп простой заменой грамматических таблиц парсера. По ООП-возможностям языки равноценны или будут почти равноценны. Я по крайней мере к этому стремился и стремлюсь. Сахорку подсыпать только надо да "запрещено то что не разрешено" аккуратно поразрешать.
Сами же языковые возможности у 1С конечно несравненно беднее шарпа (я о виртуальной машине 1С, т.е. о реализации методов). Но имеется потенциальная возможность и компилировать шарпом, или gcc или <ваш-выбор>. Лишь бы удобный Вам язык реализации виртуальные функции вызывать умел (ну то-есть с COM интерфейсами умел работать).
И, простите, а что не так с моим именем?
24. c+ + (ture) 231 31.10.16 18:21 Сейчас в теме
(23) Что нет так? Для специалистов "++" означает с++, а это весьма хмурые ребята, которых тошнит от CLR и с#, ибо это надругательство со стороны m$ над с++. А ты написал совсем что-то недостойное "++". Для программистов 1С, код не читаемый и похож на кашу, что типовые конфигурации и рядом не стояли. Т.е. получается как писали выше "ООП головного мозга".

Короче, прячь публикацию, пока тебя не запомнили потенциальные работодатели. Подредактируй ее на что-нибудь нейтральное и выводи снова (звезды вроде не должен потерять).
27. IntelInside (G) (IntelInside) 126 31.10.16 19:21 Сейчас в теме
(24) ture,
По поводу ++ я уже ответил выше <artbear>. Это досадная ошибка. Нигде в самом коде и внутренней документации два плюса не используется. Название статьи и проекта будет отредактировано на "1С+классы".
По поводу каши почитайте ответ для <fishca>. В общем и целом в кашу код превращает импотентность 1С.
И знаете что... Спасибо! То что мои труд начинают сравнивать с типовыми конфигурациями уже лестно.

...и чего мы хмурые (смотрясь в зеркало), небритые вот только
28. Котэ Пруидзе (kote) 471 01.11.16 01:49 Сейчас в теме
ООП возник как более удобное средство разбиения системы на независимые части (удобно думать про неймспейсы) + идея хранить данные и методы их обрабатывающие рядом..

Ну не знаю.. может оно всё и работает - но пользоваться и поддерживать такой код - я не возьмусь.. страшно неудобно всё.
29. Сергей Рудаков (fishca) 1090 02.11.16 08:48 Сейчас в теме
(0)
1. Для того чтобы сие творение хоть как-то отрывалось от земли, не говоря уже об взлете, я бы для начала пообщался на эту тему с зубрами 1С++
2. Пообщался на эту тему с зубрами опенконфа, снегопата && компани
3. И только после такого тесного сотрудничества и в теснейшем взаимодействии с ними разрабатывал хоть какой-то концепт технологии применительно к восьмерке.

Не надо отбрасывать опыт набития шишек, его необходимо использовать.

А так пока все эти слова про бейсик напоминают "запор мыслей, понос слов", вы уж извините за прямоту.
37. IntelInside (G) (IntelInside) 126 02.11.16 17:50 Сейчас в теме
(29) fishca, Спасибо. Я и пытаюсь с зубрами пообщаться. Только они, зубры, такие... к ним так просто не подойдешь. Без рабочего кода с одним "запором мыслей" вообще вариантов нет. Прошлая статья показала. Да и сейчас не гладко.
А за прорыв "запора мыслей" извините - накопилось. Материала много - я еще VB6 компилятору помогал, во free basic компиляторе копался, вот и с 1С не устоял. Судьба видно.
Нужно какое-то одно яркое практическое зерно. И народ потянется. Я вот только его никак ухватить не могу.
30. Сергей Шмалько (serg61) 29 02.11.16 09:26 Сейчас в теме
Есть серьезные сомнения по поводу применения данных наработок:
1. Крупные компании всегда будут против любых поделок не поддерживаемых официально 1С.
2. По собственному опыту знаю, что ++ далеко не всем нужен. Вообще-то очень редко нужен, только когда проектируется новые объекты. Спасибо фирме 1С, что они взяли на себя эту работу.

Если автору некуда девать свободное время рекомендую написать транслятор с языка 1С (без всяких ++). Коммерческий успех гарантирован. Вижу следующие применения:
1. Использование для пакетной обработки команд, что-то тип .bat на языке 1С
2. Просто что-то надо посчитать студентам типа экономистам.
3. А если он будет встроен в какой-нибудь бесплатный ексел, то ему цены не будет.

33. Александр Орефков (orefkov) 1480 02.11.16 09:53 Сейчас в теме
36. IntelInside (G) (IntelInside) 126 02.11.16 17:22 Сейчас в теме
(30) serg61,
Сторонняя реализация языка 1С - это OneScript. Очень путевый проект. У меня есть большие надежды на сотрудничество с ними. Если мою разработку добавить к их проекту то получится полноценный "национальный Бейсик" с весьма развитыми выразительными возможностями. Если развить еще тему типизации до уровня Nemerle и атрибутов, то на java можно будет посматривать свысока. Их в теме просто еще не было и я не знаю их планов. С моей же стороны требуется сформулировать интерфейсы взаимодействия дабы не публиковать интерфейсы 1С. Тем более они мне немного тесноваты - и вперед.

Я подумываю не о трансляторе, а о компиляторе языка 1С в машинный код. Что-то уже намечается...

А в OpenCalc есть UNO-бейсик, а вся технология UNO сама по себе интересна...

А для крупных компаний таки да - <не нужен>. Или по крайней мере пока <не нужен>. Только если <это> вырастет в полноценный проект и только если они оголодают на тощем рынке. Вот тогда да - в очередь выстроятся. Пока это только "тюнинг" для любителей. Впрочем аналогия с авторынком и рынком авто-тюнинга абсолютно полная. Это одинаковая и описанная в литературе бизнес-модель.

Ну и конечно ООП нужен для ЕРП++, но не перескочить через Предприятие++, но для этого надо Бух++, БСП++ ...
А в начале всего этого надо хоть пяток человек понимающих и 1С и ООП и необходимость такого пути.
31. Стас Гаевой (xOBEHx) 15 02.11.16 09:40 Сейчас в теме
Однозначно плюс, т.к. любой прогресс начинается с энтузиазма одного человека, а далее подхватывается массой.
В любом случае ждем развития идеи. Будет развитие, возникнет и интерес со стороны 1С.
32. Александр Орефков (orefkov) 1480 02.11.16 09:52 Сейчас в теме
Описания классов подгружать из файла, реализации распихивать по модулям обработок - это структурированнее будет и от Класс_Метод позволит избавится.
ЭтотКласс как параметр - ну, в питоне живут с self и ничего. Хотя конечно, можно и исхитрится и обойтись без этого.
Недостаток "ЭтотКласс" - при вызове нельзя выбрать, вызывать ли строго метод из базового класса или возможно переопредлённый в наследнике. Но тоже решаемо.

Только это уже было, реализация на подобном принципе - http://infostart.ru/public/19332/
Допилить то можно до боле-менее приемлемого состояния, но видимо, нет особой нужды в ООП в восьмёрке.
К тому же таки всё через COM - дополнительные задержки плюс линукс в пролёте. А нативные ВК - не поддерживают работу с объектами, только если с закатом солнца вручную, как в http://infostart.ru/public/541518/ - но это костыль ещё похлеще обсуждаемого.
Самое красивое, конечно же, было бы сделать реализацию на внутреннем движке 1С, по принципу снегопата, но релизо-зависимость... Хотя, в части работы с объектами 1С - она не такая сильная - с 8.2 ничего принципиально не менялось.
35. IntelInside (G) (IntelInside) 126 02.11.16 16:32 Сейчас в теме
(32) orefkov, Это вероятно какое-то или неточное прочтение или мое сумбурное описание.
Компонента полностью родная для 1С как и Снегопат. Я иногда использую термин 1С:COM, что подразумевает:
а) наследование от IUnknown
б) 1C:<типы данных> для параметров и возвращаемого значание
в) для возвращаемого значения не HRESULT, а любое допустимое в б)
г) ошибки в виде С++ исключения в 1С:<ошибка> формате (в т.ч. и через границу DLL)
Так построена и 1С и эта компонента, поэтому при компиляции под соответствующую платформу работать она будет везде, где работает и 1С. Сейчас выложена win32. Следущим шагом планирую lin32. Затем lin64. О win64 буду думать гхм... по политическим мотивам. Андроид и iOS не являются технически неразрешимой задачей, но там будет абсолютная версиозависимость. Поэтому это эксклюзив.

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

Вызвать метод базового класса - конструкция ЭтотКласс.МойБазовый.<имя-метода>
Свойство .МойБазовый возвращает именно контекст базового класса, без замещения виртуальных методов. Т.е. вызывается именно версия метода базового класса, а не наследника.
Возможность вызова ЭтотКласс.МойБазовый.МойБазовый.<имя-метода> подавляется принудительно. - разработчик базового явно должен дать такую возможность наследнику.

Подумываю только термин МойБазовый заменить на термин БазовыйКласс в окончательной версии. Т.е. чтобы было ЭтотКласс.БазовыйКласс.<имя-метода>

Если будет развитие проекта, то можно ввести специальную синтаксическую конструкцию для восстановления свойства БазовыйКласс в контексте базового у наследника для удобства разработчика.
Также (при развитии) в случае реализации множественного наследования видится ЭтотКласс.БазовыйКласс('имя-класса').<имя-метода> к примеру, хотя наверное есть и другие варианты.

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

Без нормального IDE и IntelliSense (короче Снегопата) жизнь будет очень скучна при любом методе загрузки.
34. Denis Lebedev (dlebedev8) 02.11.16 14:47 Сейчас в теме
Какой кошмар...
За старания плюс, конечно, но такое ООП в 1С точно не нужно. Вот если бы кто взялся и реализовал модель, основанную на сигналах а-ля Smalltalk, это был бы реальный взрыв мозга. А тут только запутывание похуже злосчастной БСП.
40. Вадим Латышев (pro1c@inbox.ru) 166 11.11.16 12:54 Сейчас в теме
ООП в 1С не нужен! И никогда не понадобится.
41. Максим Хлыстов (max1c) 07.12.16 16:12 Сейчас в теме
Сделайте возможность передать одну функцию в другую как аргумент. И замыкания.
43. Сергѣй Батанов (baton_pk) 212 07.12.16 16:55 Сейчас в теме
Мысль, куда направить силы: есть отдельная каста извращенцев (в том числе больших и корпоративных), которые держат код не в конфигураторе. Даже ходить далеко не надо: взять ту же конвертацию или алгоритмы трансляции во всяких (трибуквы)-финансах. Пишут код в блокнотике, суют его в справочник, потом в конфе где-нибудь видим: Выполнить(Ссылка.ТекстАлгоритма)

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

Честно, я был бы счастлив иметь возможность писать в конвертации хотя бы процедуры :)

PS. извращенцы были в хорошем смысле слова, хотя и плеваться иногда на них охота.
44. zavedeev (zavedeev) 16.12.16 09:35 Сейчас в теме
45. Алексей Роза (DoctorRoza) 17.12.16 15:16 Сейчас в теме
+ в карму! Только один вопрос, просвятите - зачем ООП в 1С? Что нельзя написать и какой профит на выходе?
46. Игорь Нешик (ineshyk) 18.12.16 20:51 Сейчас в теме
Поставил +.
Но как такое юзать в продакшене?

И не может классическое ООП реализовать через интерпретаторы, кем 1с, собственно, и является.

48. Oleg Space (spacecraft) 19.12.16 15:37 Сейчас в теме
(46)
И не может классическое ООП реализовать через интерпретаторы, кем 1с, собственно, и является.

главное чтоб python об этом не узнал, а то работать перестанет. Да и php вместе с js.
Про "интерпретатор 1С" промолчу.
49. Игорь Нешик (ineshyk) 20.12.16 01:54 Сейчас в теме
(48) Ну в js жалкое подобие ООП.

А об "Про "интерпретатор 1С" промолчу." - так Вы не молчите.
50. c+ + (ture) 231 20.12.16 09:27 Сейчас в теме
(49) он просто не забивал голову.
47. c+ + (ture) 231 19.12.16 15:26 Сейчас в теме
(00) Выбор эксперта?

Новый макдиггер это!
51. c+ + (ture) 231 22.12.16 13:39 Сейчас в теме
(0) помнишь, я говорил, что не интересно и избегают? еще есть ощущение, что я не хотел тебе помочь? Последуй совету.
60. Андрей Овсянкин (Evil Beaver) 4759 18.03.17 10:05 Сейчас в теме
А я вот не освоил Го, задач как-то нет под него. Но любопытный язык, да
66. Петр Лунегов (pvlunegov) 108 15.11.17 08:05 Сейчас в теме
С комментариями согласен. Реализация ООП не стоит того, чтобы писать километры кода ради маленького функционала.
Неочевидно, трудно поддерживаемо другими разработчиками, визуально не читаемо.

Автор,
Чтобы код легко читался на интуитивном уровне, нужно как минимум изучить Питон, посмотреть Го.
Пытаться реализовать ООП в виде С++ на 1с нет смысла, потому что когда нет нативной поддержки от платформы будут ГРАБЛИ и КОСТЫЛИ.
Писать такой код тяжело и непотребно, он некрасив и неинтуитивен.

Почему так любят С++, потому что в свое время он был лаконичен, краток и красив (на английском языке).

Для русского языка код С++ не красив, потому что автор - англичанин с английскими образами и понятиями.

Чтобы код программы С++ был как минимум лаконичен и читаем непрограммистами, в вашем случае нужно :
1. Разделить интерфейс классов и реализацию на отдельные файлы.
2. Логически разделить отдельные классы на подклассы. Один класс реализует работу с пользователем, другой - внутренние механизмы работы с графической системой, вводом-выводом.
Третий класс - работу с другими классами.
3. Работа с пользователем должна быть реализована в классе в котором функции реализуют естественные команды на живом языке.
Например
функция повернуть_влево()
функция увеличить_ход()
функция сохраниться() - вызывает функции интерфейса внутреннего класса который реализует сохранение данных на диск и т.п.
функция дать_отчет() - формирует контекст получения данных, формирует пакет данных и выводит отчет.

Такой класс реализует инкапсуляцию внутренних методов во внутренних классах.
Пользователь системы, который видит ее в 1 раз видит:

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

Эта концепция кстати, во всех серьезных книгах по С++ рассказывается авторами как азбука ООП.
Это не входит в парадигму ООП но является ДЖЕНТЕЛЬМЕНСКИМ навыком программирования.
67. IntelInside (G) (IntelInside) 126 16.11.17 13:14 Сейчас в теме
(66)
(66)
Относительно синтаксиса реализации ООП. Язык 1С называется 1С-Бейсик. Поэтому я и пытался делать "по-бейсиковски", а не "по-питоновски".

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

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

И кстати я нашел ответ на вопрос "почему?". На хабре оказывается есть статья от 1С в которой описана политика 1С в отношении языка. Он оказывается сознательно ограничен в функциональности. СОЗНАТЕЛЬНО! <Это своеобразное сочетание мощной платформы и разумно-ограниченного прикладного языка>

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

А собственно об ООП я, извините, в дискуссию ввязываться не хочу. С моей стороны это будет не гуманно.

Посмотрите еще здесь: https://forum.infostart.ru/forum9/topic178313/
68. Петр Лунегов (pvlunegov) 108 16.11.17 14:53 Сейчас в теме
(67) Если обидел, извините. НЕ хотел порочить вашу работу.
Работа хороша, эпична, мощна.
Я просто вставил свои замечания. И вот почему.
1. Я за более 10 лет работы в 1с для себя лично выявил и придерживаюсь простых правил.
а. Нет такого кода, который нельзя было бы улучшить, причесать, надраить, вылизать, сбрызнуть одеколоном.
б. Любой код должен стремиться к красоте, интуитивности, приятности, читабельности.
Это общее стремление любых живых мыслящих организмов - к самоорганизации.
в. Когда программист перестает причесывать код, он покрывается пылью, гарью и спустя года перестает работать, потому что любая система - живая и ее нужно поддерживать (сдувать пыль, перетасовывать и т.п.)
г. Любой список из более чем 3 пунктов плохо читабелен (интуитивно, подсознательно).
Из этого простое правило - превращать любой плоский код, состоящий из большого количества процедур (независимых), в Дерево фунций и процедур (вложенных), который разбиты на файлы, модули и папки.
Каждая папка, модуль и функция в конце концов должны подчинятся правилу САМОДОКУМЕНТИРУЕМОСТИ.

Правило САМОДОКУМЕНТИРУЕМОСТИ:
1. как можно меньше комментариев (в идеале вообще без оных)
2. Названия функций точно и максимально лаконично (без потери смысла!) отражают свой функционал

Если вы внимательно задумаетесь над вышесказанным и ОСОЗНАЕТЕ оное, то поймете, что вашу документацию можно и нужно переделать к САМОДОКУМЕНТИРУЕМОСТИ
а ваш код разбить на Деревья.
Оставьте свое сообщение