オブジェクト指向コードではなく手続き型コードを使用していることを示すのに役立つ指標はどれですか? 分析されたコードに、適切なオブジェクト指向の設計原則に従っているのではなく、手続き型のトランザクション スクリプトと貧弱なドメイン モデルが含まれている可能性が高いことを示す、単純なメトリックのセットが必要です。
測定に役立つ指標とツールのセットがあれば幸いです。
ありがとう、トーマス!
オブジェクト指向コードではなく手続き型コードを使用していることを示すのに役立つ指標はどれですか? 分析されたコードに、適切なオブジェクト指向の設計原則に従っているのではなく、手続き型のトランザクション スクリプトと貧弱なドメイン モデルが含まれている可能性が高いことを示す、単純なメトリックのセットが必要です。
測定に役立つ指標とツールのセットがあれば幸いです。
ありがとう、トーマス!
結束と結合に焦点を当てたメトリクスは、関数のコレクションではなく、クラスが本物であることを示す良い指標となるはずです。ここに非常に読みやすい論文があります。これを以下に引用して、結束力が優れた指標であると考える理由を示します。
「結束」とは、モジュール コンポーネントの関連性を指します。凝集性の高いコンポーネントとは、1 つの基本機能を備えたコンポーネントです。粘着性のあるコンポーネントを分割するのは難しいはずです。結束は、最も望ましくないカテゴリ (偶然の結束) から最も望ましい (機能的な結束) までの順序尺度を使用して分類できます。」
結束の古典的な尺度は、Chidamber と Kemerer の "Lack of Cohesion in Methods" (LCOM)です。クラス内のメソッド間のリンケージを測定するクラスの応答 (RFC)も確認できます。
NOC や DIT などの設計指標を検討することもできますが、私自身の経験では、それらはあまりにも粗雑で、サードパーティ フレームワーク内のクラスと簡単に混同されてしまいます。
どの言語を使用しているかは述べていませんが、Eclipse を中心に構築されたツールがいくつかあるため、Eclipse ベースのオブジェクト指向メトリックを Web ですばやく検索すると、役立つ情報が得られるはずです。
いくつかはちょうど私の心の外に
これらは、コードがよりオブジェクト指向またはより手続き的であることを保証するものではありませんが、それらを支援する可能性があります。