If database triggers are evil, is it also evil to have side effects when setting a property in java or C#?

Let's assume that [database triggers are evil].1

Does this开发者_运维问答 mean that side effects when setting a property on a java or C# object are also evil?

It seems to me that all the same problems exist.

Going against the grain here...

Properties should NOT trigger side effects. That's what Method's are for.

By having properties cause side effects you end up in a situation were code is essentially hidden. People rarely expect properties to kick off some process or cause something else to flip. If this has to be documented, then its not obvious and subject to being ignored.

However, we do expect something to happen when we call a Method.

Taking @astander's example, he says that the act of changing "Price" should cause a different property "Cost" to change. However, what if we later add a new property called "Discount"? The code around the Price and Amount properties would have to change. Which isn't very discoverable.

However, if Cost calculated itself.. then everything is better off.

Not necessarily, no. If you have a Price or Amount property, and you change that, it would seem that the Cost should change accordingly?

Or is there something different you had in mind with this post?

No. Many properties can and should trigger side effects.

Ex: Imagine two visual elements where a child is contained within a parent. Setting parent.Visible = false should probably also set child.Visible = false.

Often these side effects are made explicit via an event (System.Windows.Forms is full of PropertyChanged events) or an interface (such as INotifyPropertyChanged).

As useful as properties sometimes are, they do introduce some uncertainties in day-to-day coding in a team environment, where not everybody necessarily interprets the purpose and appropriate use of properties in the same way.

This is one of a number of issues that arise:

• Should property setters have non-obvious side-effects.
• Should they do potentially intensive processing?
• Do public fields still have a place, or should all fields be private/protected and accessed via properties? This can have an impact when making use of reflection: it can be handy to know that you never have to search a type's Fields collection.

Ultimately, I think that the above 2 points don't matter that much so long as any side-effects or potentially costly operations are documented, because the same should apply to methods as well.

The more assumptions you can safely make decrease code complexity, but that gain is negated to some degree by additional communication overheads. It only works as long as everybody in the team is on the same page, and stays on the same page.

Sometimes I think properties cause more issues than they solve.

That depends. Certainly there are side effects, that will take the user by surprise and it is best to avoid those IMO.

I prefer that properties behave very much like fields, since they look the same from the reader's point of view (in C# anyway). If a property would have any non-obvious side effect, I would prefer a method over a property.

In additions to Chris's comments above, which I do agree with there is another aspect that has contributed to triggers being considered a bit devious and that is the fact that they are non - obvious.

This makes then very easy to forget which in turn makes them very difficult to debug.

People (and i am one of them and not the only one for sure) have spent hours trying to debug issues and going through the flow start to end (apparent end i.e database procedures / DML queries) to realise what was causing the problem all along were the triggers - because of them inherently being background operations.

You could also argue that proper logging of triggers should result in easy avoidance of this kind of issue but usually logging is never done in the Database layer itself hence complicating this aspect of troubleshooting a bit more.