Если триггеры базы данных являются злыми, то также плохо иметь побочные эффекты при установке свойств в java или C #?

Question

Предположим, что [триггеры базы данных - зло]. 1

Означает ли это, что побочные эффекты при установке свойства объекта Java или C # также являются злыми?

Мне кажется, что все те же проблемы существуют.

Answer 1

Идти против зерна здесь ...

Свойства не должны вызывать побочные эффекты.Вот для чего нужны методы.

Имея свойства, вызывающие побочные эффекты, вы попадаете в ситуацию, когда код по существу скрыт.Люди редко ожидают, что свойства вызовут какой-то процесс или заставят что-то другое перевернуться.Если это должно быть задокументировано, то это неочевидно и может быть проигнорировано.

Однако мы ожидаем, что что-то произойдет, когда мы вызываем метод.

Взяв пример @ astander, он говорит, что действие по изменению "Price" должно привести к изменению другого свойства "Cost".Однако что, если мы позже добавим новое свойство с именем «Скидка»?Код вокруг свойств Price и Amount должен измениться.Что не очень хорошо видно.

Однако, если Стоимость рассчитывается сама ... тогда все будет лучше.

Answer 2

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

Это позволяет очень легко забыть, что, в свою очередь, затрудняет их отладку.

Люди (и я один из них, и не единственный, наверняка) потратили часы на отладку проблем и прохождение потока от начала до конца (очевидный конец, то есть процедуры базы данных / запросы DML), чтобы понять, что вызывало проблемой всегда были триггеры - из-за того, что они изначально были фоновыми операциями.

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

Answer 3

Это зависит. Конечно, есть побочные эффекты, которые застают пользователя врасплох, и лучше всего избегать этих ИМО.

Я предпочитаю, чтобы свойства вели себя как поля, поскольку они выглядят одинаково с точки зрения читателя (в любом случае, в C #). Если бы свойство имело какой-либо неочевидный побочный эффект, я бы предпочел метод, а не свойство.

Answer 4

Как бы ни были полезны свойства, они вносят некоторые неопределенности в повседневное кодирование в командной среде, где не все обязательно интерпретируют цель и правильное использование свойств одинаково.

Это одна из многих проблем, которые возникают:

• Если установщики свойств имеют неочевидные побочные эффекты.
• Должны ли они выполнять потенциально интенсивную обработку?
• Открытые поля все еще имеют место, или все поля должны быть частными / защищенными и доступными через свойства?Это может оказать влияние при использовании отражения: может быть полезно знать, что вам никогда не придется искать коллекцию полей типа.

В конечном счете, я думаю, что вышеупомянутые 2 пункта не имеют значениястолько, сколько документированы любые побочные эффекты или потенциально дорогостоящие операции, потому что то же самое должно относиться и к методам.

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

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

Answer 5

Нет. Многие свойства могут и должны вызывать побочные эффекты.

Пример: представьте себе два визуальных элемента, в которых ребенок содержится внутри родителя. Установка parent.Visible = false, вероятно, также должна устанавливать child.Visible = false.

Часто эти побочные эффекты выражаются явным образом через событие (System.Windows.Forms полна событий PropertyChanged) или интерфейс (например, INotifyPropertyChanged).

Answer 6

Не обязательно, нет.Если у вас есть свойство Price или Amount, и вы измените его, может показаться, что значение Cost должно измениться соответственно?

Или есть что-то другое, что вы имели в виду с этим постом?