プロパティセッターにロジックを追加することは悪い習慣と見なされますか？

プロジェクトに飛び込んだところ、他の開発者が合成プロパティのセッターに多くのロジックを追加していることがわかりました。私はこれがどのように機能するかを理解していますが、プログラムの流れを理解するのが難しくなると思います。コードを読んでいる間、表示されるたびにself.something = whatever、somethingのセッターがオーバーライドされているかどうかを常にチェックしています。

このトピックに関するあなたの意見は何ですか？これは、悪いアーキテクチャのサインであるか、精巧なソリューションであると思いますか？

関連するリンク/ソースがある場合、これについてもっと読んでうれしいです。良いGoogleの結果を得るのはあまりにも難しいので、ここでも尋ねることにしました。

答えてくれてありがとう、あなたがタグを見なかった場合の客観的なCについて話していることに注意してください（これは私が推測する言語固有の問題ではないはずですが）。

プロパティセッターにロジックを追加することは悪い習慣と見なされますか？

いや

プロパティは、クラス設計者がフィールドアクセスと割り当ての便利なインターフェイスにロジックを付加できるようにするために考案されました。

いくらですか？クラスの責任に依存します。プロパティセッターに入れるのが妥当なものを次に示します。

• いくつかの派生値を更新する
• クラスの状態が変更されたことをオブザーバーに通知する
• 含まれているオブジェクトに変更を伝播します
• 変更をバッキングストアに伝播します
• 検証を実行する

クラスが実行できることを呼び出し側に考えさせることなく、クラスに何ができるかを明確にするインターフェースがある場合、プログラミングは簡単です。プロパティセッターの背後にロジックを配置すると、クラスは単純なインターフェイスの背後に実装を隠すことができます。一部のクラスでは、メソッドは不要です。プロパティを設定してノブを回し、プロパティを取得して出力を読み取ります。

セッターは通常、重大な副作用や重い計算なしでオブジェクトの状態を変更するために使用されます。そのためのメソッドと関数を使用します。セッター実装の主な理由は、有効な状態を変えて、維持することです。そのため、範囲の制限、再計算を要求するフラグの設定、または関連するプロパティの調整はまったく問題ありません。

私は客観的なCについては知りませんが、あなたが言うように、それはどんなOO言語にとっても一般的な十分な質問のようです。まず第一に、実際にそれに関連して、最初にセッターとゲッターを置くかどうかは議論の問題です（場合によっては、それらの存在はフレームワークまたはライブラリの使用によって正当化されます）。

メソッドの名前は、メソッドが何をするのか、すべてのメソッドが何をするのかを説明すべきだと思います。さらに、そのメソッドに関連するドキュメントでは、より明示的な方法で説明する必要があります。この意味で、 "set" + {noun}の形式のメソッド名には、変数の値を設定する以外の副作用はなく、それに関連付けられた唯一のアクションである必要があります。引数が有効であることを確認することは許容できますが、そのドキュメントに記載する必要があります。