Показать сообщение отдельно
Старый 31.07.2021, 19:20   #18  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,652 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от mazzy
расскажите почему вы решили что будет дублирование?
Пример с validateWrite + Write явно надуманный. Именно так сильно сомнительно что кто-то будет делать. Ну очень много вопросов именно по этой связке. Значит, речь идет о некоем собственном методе внутри которого выполняется некая проверка и, возможно, модификация данных

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

Нет, чисто теоретически, возможно, что разработчик выполнит рефакторинг кода, выделит отдельные методы и организует их вызов, чтобы исключить дублирование кода, но практически будет реализован один из 2 вариантов

1. Будет добавлен параметр в существующий метод
2. Будет создан метод дубликат, где вместо false вызовут исключение. Или наоборот, вместо исключения вернут false. Смотря по тому, что было изначально

Поскольку в данной теме речь идет именно о создании методов, то и получим дублирование кода

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

Цитата:
Сообщение от Владимир Максимов
Т.е. я за один общий метод с параметрами.
Цитата:
Сообщение от mazzy
ну, ооок...
а вы предпочитете видеть true или false для обозначения с исключением или без?
или стоит создавать специальный enum?
какой стиль лучше на ваш взгляд?

особенно для нескольких параметров.
Сама постановка вопроса не корректная. Как правило, подобные методы редко продумываются на этапе создания архитектуры проекта. Они возникают "естественным путем" по мере возникновения в них необходимости. Соответственно и варианты реализации также возникают "по месту". Вот что в данном случае покажется более уместным, то и делают

Т.е. у меня в данном вопросе нет предпочтений. "Как получится"

Цитата:
Сообщение от mazzy
это да. в X++ да.
поэтому и вопрос - а какие другие причины могут делать тот или иной способ удобнее для читающего?
Принятые правила. Best Practices. "Закон". "Пусть безобразно, зато единообразно" (с)

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

Этот вопрос многократно и по разным поводам поднимался. То, что удобно (читай "привычно") для одного будет неудобно (не привычно) для другого.

Я наблюдаю странные синтаксические конструкции, когда разработчик, привыкший работать в другом языке программирования тащит свои привычки в X++. Иногда что-то получается. Только вот я долго "туплю" над таким кодом, пытаясь понять, а что вообще хотели сделать-то? Именно по той причине, что "не привычно".

Цитата:
Сообщение от mazzy
Тю-тю-тю-тю... Стопэ!
у меня ничего про "сокращение написания кода" не было.
если вы считаете, что было - прошу цитату.
Да. Тут я не прав. Фразу "Чтобы использование было удобным." не так "расшифровал". Хотя насчет удобства - вопрос привычки
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...