Продолжая эту тему.

К примеру есть процедура в установке цен которая контролит нужно -ли использовать характеристику и сообщает об ошибке.

По бизнес-логике приложения у меня предполагается по виду цен задавать наценки для товара (ну конечно же по товару в целом без его характеристик)

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

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

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

&Перед или &После это частные случаи &Вместо + ПродолжитьВызов

1С-ники велосипедисты. Во всем мире это override (переопределение)

(2) а я разве написал на форум по вопросу который относиться не к 1С? Какой смысл этого высказывания?...

(3) Такой, что не один ты задаёшь такой вопрос, остальные тоже недоумевают.

В даном случае идет разговор, о том, что &Вместо + ?(Не БезусловнаяЗамена, + ПродолжитьВызов, ОбработатьВМодуле)

Что именно оно ббудет использовано думаю в 80% случаев (возможно это занижено) чем &Перед или &После

Просто разработчики пальцом настараживают мол так делать можно но это плохо...

(4) я не в доумении...  совершенно верно.

Собственно вот цитата из зазеркалья, которы мне скинули постом выше:

И, наконец, самый «нехороший» вариант – это полное перекрытие типового метода перехватчиком &Вместо.

https://wonderland.v8.1c.ru/blog/rasshirenie-moduley/

Что лучше, &Перед, &После или &Вместо?

Когда вы перехватываете методы типовой конфигурации, всегда полезно помнить о двух вещах:

    После того, как вы написали своё расширение, типовая конфигурация будет изменяться;
    Ваша цель – добавить свою функциональность, а не навсегда отказаться от того, что есть, и что будет в типовой конфигурации.

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

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

И, наконец, самый «нехороший» вариант – это полное перекрытие типового метода перехватчиком &Вместо. В этом случае типовой обработчик безусловно не будет выполняться ни сейчас, ни в будущих версиях. То есть всю ответственность за работу будущих версий конфигурации вы берёте на себя, на своё расширение. Наверняка есть ситуации, когда такое полное перекрытие необходимо, но мы призываем вас подходить к его использованию очень взвешенно и осторожно.

(5) скорее всего &Перед или &После это последовательное выполнение методов, а &Вместо + ПродолжитьВызов это увеличение стека вызовов методов

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

вполне приемлемым является использование перехватчика &Вместо и метода ПродолжитьВызов()

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

вот и всё

(8) и как без подобных указаний живут разработчики C#/Java бедные

(14) В ООП нет &Перед и &После, только &Вместо. Ну и ключевое слово для вызова оригинального метода.

проблема в том, что люди разучились читать тексты длиннее 140 символов...

Fragster -  я не понял какого икса ты тут переписываешь,  то что в статье!

(16) проблема в том, что есть умники которые сидят в очках с толщинной линз в двадцать сантиметров и которым не чем заняться и тупо памят форумы.

(14) это большая тема для разговора.

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

(17) потому что в статье написано, что это всё монопенисуально, единственная проблема которая может быть в том, что оригинальная база имеет свойство обновляться, и ты должен это учитывать.

(15) я уже писал в (2)

(20) да ладно, а что действительно база еще и обновляется....

Умники: "  Fragster" и "  В тылу врага"
когда потребуется обсуждать языки использующие ООП я обязательно обращусь именно к Вам!

Начинается ка кобычно тупо - срач. Модеры закрывайте веть!

(23) а тогда в чем у тебя вопрос в (0)?

этот форум с такими умники все чаще стает просто безсмыслен.

обязательно

А в том, что 1С говорят лучше этого не использовать, потому как при обновлениях может возникнуть лажа. Ну так это и все вкурсе.

И они мол такие используйте лучше &Перед или &После

А пофакту-то, использоваться они будут крайне редко

(28) если в одном случае они не подходят, не значит, что они будут использоваться редко. На моей практике при доработке типовых в итоге как раз чаще всего вставлялась одна-две строки в начало или в конец типовой функции (с вызовом функции своего общего модуля).

(29) Собственно дополнения должны использоваться, чтоб какраз-таки не менять типовой функционал и удобно обновляться.

Проще дорабатывать расширения, чем обновляться нетипово.