Чего нам ждать от 1С:Предприятие 8.3.24
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1) Зачем вам эта ОПП сдалась? Хотите накуролесить классов для повышения ЧСВ?
Я вот жду когда добавят статическую типизацию переменных/параметров, чтобы код был более неубиваемый
А вообще может быть пусть бы 1С в платформе 9.0 вообще втулила язык программирования как в 1С:Предприятие.Элемент
Я вот жду когда добавят статическую типизацию переменных/параметров, чтобы код был более неубиваемый
А вообще может быть пусть бы 1С в платформе 9.0 вообще втулила язык программирования как в 1С:Предприятие.Элемент
(3) Посмотрите на размер БП, а лучше ERP по количеству кода. А после прочтите ниже.
Процедурный язык задумывался для того, чтобы бухгалтера могли писать код. Не вышло, не взлетело. Пишут в конечном итоге люди в стыке между программистами и бухгалтерами. Т.е. или программисты изучившие буху или бухи изучившие язык и ушедшие из бухов.
Что дало бы ООП
1) Три принципа ООП (не буду раскрывать, ибо считаю это может быть обидно для специалистов когда им объяснять про 2*2)
Из которых вытекают
1.1) Уменьшение количества кода. А это очень важно, т.к. в таких монстрах найти откуда все вышло и куда ушло уже становится очень трудно. А со временем может стать невозможно. Попробуй найди ошибку!
1.2) Уменьшение повторений кода (DRY)
1.3) Читаемость и интуитивность. Вот тут остановлюсь. Мы как в каменном веке живем. Создаем документ неявно (т.е. без объявления типа переменной документ) или справочник и синтаксис помощник не дает подсказок и это не исправить. Сделали бы класс наследник и все, проблема бы решилась. И таких проблем очень много
2) Именно ваше желание и у меня такое же. Статическая типизация. Создайте себе классы обработчики по принципу как в Java и вот вам типа данных, свои, родные со своими фишками.
3) Распространение кода. Класс структура самостоятельная, если не наследник другого класса. Можно легко прибавить или убавить из конфы.
Процедурный язык задумывался для того, чтобы бухгалтера могли писать код. Не вышло, не взлетело. Пишут в конечном итоге люди в стыке между программистами и бухгалтерами. Т.е. или программисты изучившие буху или бухи изучившие язык и ушедшие из бухов.
Что дало бы ООП
1) Три принципа ООП (не буду раскрывать, ибо считаю это может быть обидно для специалистов когда им объяснять про 2*2)
Из которых вытекают
1.1) Уменьшение количества кода. А это очень важно, т.к. в таких монстрах найти откуда все вышло и куда ушло уже становится очень трудно. А со временем может стать невозможно. Попробуй найди ошибку!
1.2) Уменьшение повторений кода (DRY)
1.3) Читаемость и интуитивность. Вот тут остановлюсь. Мы как в каменном веке живем. Создаем документ неявно (т.е. без объявления типа переменной документ) или справочник и синтаксис помощник не дает подсказок и это не исправить. Сделали бы класс наследник и все, проблема бы решилась. И таких проблем очень много
2) Именно ваше желание и у меня такое же. Статическая типизация. Создайте себе классы обработчики по принципу как в Java и вот вам типа данных, свои, родные со своими фишками.
3) Распространение кода. Класс структура самостоятельная, если не наследник другого класса. Можно легко прибавить или убавить из конфы.
(4) 1. Те кто не знает и кому надо погуглят - и не нужно принижать уровень знаний 1С программистов, далеко не все как и я начинали свой пусть в программировании с 1С, я покодить успел на нескольких языках и о чудо там были и языки с ООП типа Delphi и С# например. Но как не странно кодить и кормиться получается именно на 1С, о чем не жалею вообще, и вы видимо тоже не голодаете благодаря 1С
1.1. ООП тут не поможет, и в ООП я видел не мало примеров говнокодинга
1.2. ООП тут не поможет, и в ООП я видел не мало примеров говнокодинга
1.3. ООП тут не поможет, и в ООП я видел не мало примеров говнокодинга.
2. Да статическая типизация не повредила бы. Но она бы могла и с прикладными объектами работать теми что мы сейчас в метаданных описываем. К слову сказать иной раз конфигуратор таки угадывает тип переменных и подсказки выводит, но дела хуже обстоят с параметрами методов (функциями и процедурами). Но в целом жить можно и без этого
3. А что будет с кодом использующим ваш класс, перестанет работать. Чета непонятный аргумент у вас в пользу классов. Обычно вроде бы придумывают интерфейсы которые должны быть реализованы в классах, тогда один класс можно убрать а какой нить другой класс реализующий такой же интерфейс может использоваться вместо него безболезненно или же совместно.
В общем за десятилетия программирования на 8 платформе, у меня крайне редко возникают хотелки лепить классы, от слова никогда. В практике своей приходится так много оперировать Структурами, ТаблицамиЗначений, Соответствиями... и мне страшно представить если бы я для каждой переменной объявлял отдельный класс ТаблицыЗначений со своим перечнем колонок или что там мне вздумается. А всякие там лошади, собачки, наследники класса животное. Ну что там при обучении ООП втитают прекрасно заменяются прикладными справочниками, если данные хранить надо, а если хранить и не надо, то такие экземпляры объектов имеют сейчас крайне низкий срок жизни между серверными вызовами, а на клиенте что вы с ними делать думаете.
Поймите правильно, я не против ООП как такового, но я на 146% уверен, что это не решит проблем говнокодинга от слова совсем.
1.1. ООП тут не поможет, и в ООП я видел не мало примеров говнокодинга
1.2. ООП тут не поможет, и в ООП я видел не мало примеров говнокодинга
1.3. ООП тут не поможет, и в ООП я видел не мало примеров говнокодинга.
Создаем документ неявно
Я выше писал про статическую типизацию, но это никак не относится к ООП, она есть и древнем QBasic DIM A AS INTEGER
2. Да статическая типизация не повредила бы. Но она бы могла и с прикладными объектами работать теми что мы сейчас в метаданных описываем. К слову сказать иной раз конфигуратор таки угадывает тип переменных и подсказки выводит, но дела хуже обстоят с параметрами методов (функциями и процедурами). Но в целом жить можно и без этого
3. А что будет с кодом использующим ваш класс, перестанет работать. Чета непонятный аргумент у вас в пользу классов. Обычно вроде бы придумывают интерфейсы которые должны быть реализованы в классах, тогда один класс можно убрать а какой нить другой класс реализующий такой же интерфейс может использоваться вместо него безболезненно или же совместно.
В общем за десятилетия программирования на 8 платформе, у меня крайне редко возникают хотелки лепить классы, от слова никогда. В практике своей приходится так много оперировать Структурами, ТаблицамиЗначений, Соответствиями... и мне страшно представить если бы я для каждой переменной объявлял отдельный класс ТаблицыЗначений со своим перечнем колонок или что там мне вздумается. А всякие там лошади, собачки, наследники класса животное. Ну что там при обучении ООП втитают прекрасно заменяются прикладными справочниками, если данные хранить надо, а если хранить и не надо, то такие экземпляры объектов имеют сейчас крайне низкий срок жизни между серверными вызовами, а на клиенте что вы с ними делать думаете.
Поймите правильно, я не против ООП как такового, но я на 146% уверен, что это не решит проблем говнокодинга от слова совсем.
Вот это полезно "Реализация возможности завершения сеансов, мешающих запустить сеанс при ограничениях на количество сеансов". А кто знает, я вроде видел реализацию в УНФ. А как там реализовано? Я бы хотел ограничить 1 сеанс на 1 username
(6) Да сделать ее не сложно, а вот доказать обоснованность наличия этой чудо возможности сложно, так как в "умелых руках" ничего хорошего не выйдет и думаю в некоторых ситуациях вообще нельзя это использовать.
Спорная возможность.
Тут и так 1С борется за асинхронность выполнения кода и делать что-то тормозящее выполнение программы видимо не хотят.
В некоторых ситуациях выручают обработчики ожидания.
Спорная возможность.
Тут и так 1С борется за асинхронность выполнения кода и делать что-то тормозящее выполнение программы видимо не хотят.
В некоторых ситуациях выручают обработчики ожидания.