Комментарии
Избранное
Подписка
Сортировка:
Древо
ООП создавалось не ради классов, наследований, перегрузки, конструкторов/деструкторов. Нет, -- оно ставило задачи повторного использования кода и улучшения читаемости/сопровождаемости миллион-строчных программ. В те же годы предпринимались усилия для анализа и структурирования кода программ (открытые-закрытые члены, модель документ-представление и т.д). Криво спроектированная система классов (ООП) способна действовать в направлении, обратном вышесказанному. Хотя возможно будет радовать создателя -- "могу же! ведь ООП же!"
(4) Автор хороший пример привел - списание по партиям.
Вспомните, неужели у вас не было случаев, когда похожие (но таки разные!) алгоритмы использовались в разных местах? Да, можно это совместить в одну процедуру, которая будет менять своё поведение в зависимости от переданных параметров. Но намного удобнее сделать один класс со "стандартным" поведением, и несколько производных, с частично измененным.
Вспомните, неужели у вас не было случаев, когда похожие (но таки разные!) алгоритмы использовались в разных местах? Да, можно это совместить в одну процедуру, которая будет менять своё поведение в зависимости от переданных параметров. Но намного удобнее сделать один класс со "стандартным" поведением, и несколько производных, с частично измененным.
(7) Вопрос в том, насколько широкой должна быть возможность изменения поведения.
Целесообразность должна определяться конкретной задачей, нет "серебрянной пули" на все случаи.
(0)
Не факт. Я не знаю внутренностей метода "Выполнить", но следуя здравой логике - замедление не должно быть сколько-нибудь заметным. Ведь сам код находится внутри функции вызываемого метода, и никто не мешает выполнять его скомпилированным. Замедление будет только на этапе самого вызова функции, и то не факт.
Другое дело если передавать в "Выполнить" не имя функции, а сам программный текст - тогда да, замедление будет.
Целесообразность должна определяться конкретной задачей, нет "серебрянной пули" на все случаи.
(0)
Единственно, нужно учитывать, что объектно-ориентированный подход в нашем случае нужно применять там, где прозрачность и понятность разработки важнее быстродействия, т.к. методы интерпретатора Выполнить все же медленнее скомпилированного кода 1С.
Не факт. Я не знаю внутренностей метода "Выполнить", но следуя здравой логике - замедление не должно быть сколько-нибудь заметным. Ведь сам код находится внутри функции вызываемого метода, и никто не мешает выполнять его скомпилированным. Замедление будет только на этапе самого вызова функции, и то не факт.
Другое дело если передавать в "Выполнить" не имя функции, а сам программный текст - тогда да, замедление будет.
Плюс за то что заставляет 1С-программистов задумываться о том чего не хватает.
Лично мне ООП не хватает больше всего. Хоть и есть в 1С различные модули, но структурирование логики программы дается с большим трудом. А большинство вообще не забивают голову и превращают программы на 1С в мешанину функций и процедур.
Лично мне ООП не хватает больше всего. Хоть и есть в 1С различные модули, но структурирование логики программы дается с большим трудом. А большинство вообще не забивают голову и превращают программы на 1С в мешанину функций и процедур.
какие-то классы надуманные.
Я бы начал с того, что создал класс, например, "счет10", -- который умеет приходовать на этот счет, и списывать с него (при списании умееет посчитать остатки). Если надо -- сделает это в налоговом плане счетов, если надо в бухгалтерском.
"Выше" идет класс "проводка10_60", который соединит "счет10" и "счет60"(умеет считать авансы). При создании (в конструкторе) они обменяются настроечной информацией (все ли поля заполнены и т.д.). Есть "проводкаНДС", котороый считает НДС.
Ещё "выше" -- класс "документ" и.д. В принципе, класс "документ_ручная_проводка" должен быть базовым для всех "документов", но может вызываться самостоятельно.
Что-то из вышесказанного можно реализовать через "модуль менеджера".
Я бы начал с того, что создал класс, например, "счет10", -- который умеет приходовать на этот счет, и списывать с него (при списании умееет посчитать остатки). Если надо -- сделает это в налоговом плане счетов, если надо в бухгалтерском.
"Выше" идет класс "проводка10_60", который соединит "счет10" и "счет60"(умеет считать авансы). При создании (в конструкторе) они обменяются настроечной информацией (все ли поля заполнены и т.д.). Есть "проводкаНДС", котороый считает НДС.
Ещё "выше" -- класс "документ" и.д. В принципе, класс "документ_ручная_проводка" должен быть базовым для всех "документов", но может вызываться самостоятельно.
Что-то из вышесказанного можно реализовать через "модуль менеджера".
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|