[データベース トリガーは悪] と仮定しましょう。1
これは、Java または C# オブジェクトにプロパティを設定する際の副作用も悪ということですか?
すべて同じ問題が存在するように私には思えます。
[データベース トリガーは悪] と仮定しましょう。1
これは、Java または C# オブジェクトにプロパティを設定する際の副作用も悪ということですか?
すべて同じ問題が存在するように私には思えます。
ここで穀物に逆らって...
プロパティは副作用を引き起こしてはなりません。それがメソッドの目的です。
プロパティに副作用を引き起こすことにより、コードが本質的に隠されている状況に陥ります。人々は、プロパティが何らかのプロセスを開始したり、何か他のものを反転させたりすることを期待することはめったにありません。これを文書化する必要がある場合、それは明白ではなく、無視される可能性があります。
ただし、メソッドを呼び出すときに何かが発生することを期待しています。
@astanderの例をとると、彼は、「価格」を変更する行為によって、別のプロパティ「コスト」が変更されるはずだと言います。ただし、後で「割引」という新しいプロパティを追加するとどうなりますか?PriceプロパティとAmountプロパティの周りのコードを変更する必要があります。これはあまり発見できません。
ただし、コストがそれ自体で計算された場合は、すべてがうまくいきます。
場合によります。確かに、ユーザーを驚かせる副作用があり、それらのIMOを避けるのが最善です。
読者の観点からは(とにかくC#で)同じように見えるので、プロパティはフィールドと非常によく似た動作をすることを好みます。プロパティに明らかでない副作用がある場合は、プロパティよりもメソッドの方が適しています。
いいえ。多くのプロパティが副作用を引き起こす可能性があり、またそうすべきです。
例: 子が親に含まれる 2 つの視覚要素を想像してください。parent.Visible = false を設定すると、おそらく child.Visible = false も設定する必要があります。
多くの場合、これらの副作用は、イベント (System.Windows.Forms は PropertyChanged イベントでいっぱいです) またはインターフェイス (INotifyPropertyChanged など) を介して明示されます。
必ずしもそうではありません。Price
またはAmount
プロパティがあり、それを変更すると、それに応じて も変更されるように見えますCost
か?
それとも、この投稿であなたが念頭に置いていた別の何かがありますか?
プロパティは有用な場合もありますが、チーム環境での日々のコーディングでは、プロパティの目的と適切な使用法を必ずしも全員が同じように解釈するとは限らないため、不確実性が生じます。
これは、発生する多くの問題の 1 つです。
最終的に、上記の 2 点は、メソッドにも同じことが当てはまるはずなので、副作用やコストのかかる可能性のある操作が文書化されている限り、それほど重要ではないと思います。
安全に行うことができる仮定が多いほど、コードの複雑さは軽減されますが、その利点は、追加の通信オーバーヘッドによってある程度打ち消されます。チームの全員が同じページにいて、同じページにとどまっている場合にのみ機能します。
プロパティは、解決するよりも多くの問題を引き起こすと思うことがあります。
上記の Chris のコメントに加えて、トリガーが少し悪意があると見なされる原因となった別の側面があることに同意します。それは、トリガーが明白でないという事実です。
これにより、忘れやすくなり、デバッグが非常に難しくなります。
人々 (私もその 1 人であり、確かに唯一の人ではありません) は、問題のデバッグに何時間も費やし、フローの最初から最後まで (明らかな終わり、つまりデータベース プロシージャ/DML クエリ) を調べて、ずっと問題の原因を認識してきました。トリガーでした-それらは本質的にバックグラウンド操作であるためです。
また、トリガーを適切にログに記録することで、この種の問題を簡単に回避できると主張することもできますが、通常、ログはデータベース層自体で行われることはないため、トラブルシューティングのこの側面が少し複雑になります。