問題タブ [cohesion]

メソッドM1を想定し、M2 強く関連する責任を負う

最初の例:

もしも

• M1andM2はクラス内で定義されますA(したがって、クラスAは非常にまとまりがあります) 。

•クラスのB使用A.M1とクラスのC使用A.M2

それから

•とクラスAの両方に結合されているBC

• の署名を変更する には、M1でのみ変更が必要ですが、では必要ありBません。C

2 番目の例:

もしも

•M1クラス内で定義されているA1(したがってBと結合されているA1)

•M2クラスで定義されているA2(したがって、Cと結合されているA2)

それから

• の署名を変更するには、M1でのみ変更が必要ですが、では必要ありBません。C

a) 私の理解では、最後の例のクラスは、最初の例のクラスよりも結合されていません! または、何か不足していますか？

b）私が知る限り、最初の例のクラスは、次の場合にのみ2番目の例のクラスよりも疎結合です。

• M1の署名を変更するには、 の署名も変更する必要があると想定していM2ますが、そう頻繁に起こるとは思いませんか?!

• または、 と の両方が同じタイプ T1 のデータM1をM2操作する場合、T1 を T2 に置き換えるには、M1とM2?!の両方を変更する必要があります。

• または、密接に関連する責任があるため、変更するM1と変更が必要になるM2可能性がはるかに高いと仮定すると（直接的または間接的に呼び出さなくても）?!M1M2M1M2

• または、密接に関連する責任があるために、一部のクラスが と の両方を必要とする可能性がはるかに高いと仮定すると(そのため、M1とを単一のクラスに持つことで結合が減少します)?!M2M1M2M1M2

c) ( withinとwithinを定義する代わりに) M1and withinを定義すると結合が減少する理由は他にありますか?M2AM1A1M2A2

注 - メンテナンスと再利用が容易なため、凝集性の高いモジュールが必要であることは承知しています。

ありがとうございました

高い凝集度は単一責任原則の同義語ですか？そうでない場合、それらはどのように異なりますか？

横断的関心事やアスペクト指向プログラミングに関連して、コードのもつれについてよく読んでいます。この記事1では、コードのもつれについて次のように説明しています。

ソフトウェアシステムのモジュールは、同時にいくつかの要件と相互作用する場合があります。たとえば、多くの場合、開発者はビジネスロジック、パフォーマンス、同期、ロギング、およびセキュリティについて同時に考えます。このような多数の要件により、各懸念事項の実装からの要素が同時に存在し、コードが絡み合うことになります。

それは低凝集度とまったく同じではありませんか？高いもつれと低い凝集度の間に違いはありますか、それとも同じことを表す2つの異なる単語ですか？

これが私の状況です。いくつかのパラメーターを選択するための複数のコンボボックスを備えたフォームフォームを備えた単一のビュー (ビューVと呼びましょう) があります。

これらのコンボ ボックスのオプションを AJAX 呼び出しで動的に読み込みたい (コンボ ボックスで 1 つの項目を選択すると、他の項目にデータが読み込まれます)

各コンボボックスは、フレームワーク上の異なるコントローラー (データを取得するために異なるモデルを呼び出す) に対して AJAX 要求を行います。これらのコントローラーをC1、C2、C3、モデルをM1、M2、M3と呼びましょう。

C1、C2、およびC3のこれらの AJAX スクリプトは、将来の他のビューで使用される可能性が非常に高いです

しかし、これが正しい方法であるかどうかは疑問です。これらの AJAX スクリプトはどこに置くのですか? 各コントローラーまたは個別のコントローラー (おそらく FormAPI などと呼ばれます)

各コントローラーに 1 つの ajax スクリプトを配置すると、V がC1、C2、およびC3と結合されますが、3 つの要求に対して 1 つのコントローラーを作成すると、ビュー V と 1 つのコントローラーのみが結合されます。また、私の観点からは、そのようなコントローラーは非常にまとまりがあります。

ただし、 C1、C2、およびC3には、「 M1、M2、およびM3のリストを取得する」というタイプのリクエストを受け取るロジックが既にあるため、コードを DRY に保持していない可能性があります。これを JSON としてレンダリングしてビューVに返すことができます。

C1、C2、C3、... CNへのリクエストを必要とする別のビューV2がある場合、将来どうなりますか? すぐに私のコードは「スパゲッティ結合」になると思います

どう思いますか？

別の質問: 項目の配列とリストを取得するには、M1、M2、M3 にロジックが必要ですか? たとえば、M1 に M2 の複数のインスタンスがある場合、メソッド M1->getM2asArray() を作成するのは正しいですか?

マイクロコントローラーでプロジェクトに取り組んでおり、いくつかの設定を保持する必要があります。これが iPod だとします。CurrentSongPlaying、 などのさまざまな設定を保存CurrentVolumeして、再度電源を入れたときにそれらの設定を復元できるようにする必要があります。私が遭遇している問題は、すべての不揮発性設定をメモリからシリアル化/逆シリアル化できる単一の構造体に保存することは理にかなっていますが、クラスが実行しないとそれを実現する方法を見つけることができません.サイズ/タイプ情報のために保存する必要がある設定を含むすべてのクラスを含む、不揮発性メモリからのシリアライゼーション/デシリアライゼーション。何を保存しているのかを知らなくても、これらすべての設定をメモリに永続化できる設計パターンはありますか?

JAVAソースコード内のコードのまとまりのあるブロックを識別できるツールがあるかどうか疑問に思っています。たとえば、別のメソッドを抽出したい長いメソッドがある場合、抽出する価値のあるコードの大きなチャンクを自動的に教えてくれるツールはありますか？

このウェブサイトで説明されているように、

（唯一の）手続き的凝集度を備えたモジュールは、異なる、場合によっては無関係なアクティビティをサポートするモジュールであり、制御は1つのアクティビティから次のアクティビティに渡されます。Page-Jonesは、モジュールの例を示しています（その名前は、「休日の食事の準備：」のようなものである可能性があります。

• 以前の食事からのきれいな道具
• トルコを焙煎する準備をする
• 電話をかける
• シャワーを浴びる
• 野菜を刻む
• セットテーブル

さて、私の質問は、これらのアクティビティのそれぞれ、つまり電話をかけることが独自のメソッドに抽出されても、すべてが同じ順序で呼び出されるかどうかです。

この方法はまだ手続き上の結束の例ですか？それとも、問題に関連する1つのタスク（この場合は食事の準備）を実行するためのアクティビティをサポートするため、機能的にまとまりがありますか？

私はツールを見つけようとしてきました (できれば MAC OS X 用ですが、移行してもかまいません)。Maultechもいくつか言及しており、このページもそうですが、私はそれらを機能させることができませんでした。メーターとアカウント (そのページにリストされています) は、私が欲しかったもののほとんどをカバーしているようです。ツールも最新ではないようで、出力がまだ信頼できるかどうか確信が持てません。

無料またはオープンソースでこれを行うことができる現在のCツールはありますか? 私が見つけたもののほとんどは、Java または OO 用です。

単純なメトリックとは、たとえば、文字、空白、関数、メソッド、ステートメントの量、ネストの深さなどの量を計算することを意味します。

サイズとは、コード行とコメントを意味します。

複雑さとは、少なくとも mccabe および halstead メトリックを意味します。

Couple と Cohesion とは、関数呼び出し間の相互作用などを意味します (これは既知の SE 原則です)。

「より大きな」アプリケーションを作成していて、クラスで特定のエラーをログに記録したいとしましょう。現在、ほぼすべてのクラスが Logger にアクセスする必要があります。

1つの簡単な解決策は次のとおりです（PHPですが、それは問題ではありません）：

このアプローチの問題は、Logger を使用するすべてのクラスがそれに依存するようになり、Logger なしで他のプロジェクトで同じクラスを単純に使用できないことです。しっかりと結合されています。また、 の実装を変更せずに、メッセージがログに記録される方法を変更することはできませんSomeClass。

上記のアプローチの「少し」のアップグレードは次のようになります。

SomeClassは単純に に依存し、LoggerFactoryそれに密結合しているため、これで問題が実際に解決されるわけではありません。これの良いところは、クラスLoggerFactoryのさまざまなインスタンスを返すことができるようになったことです。Loggerしたがって、メッセージが記録される方法を変更したい場合、 の実装を変更する必要はありませんSomeClass。

別のアプローチは、依存性注入を使用することです。

SomeClass現在、これは特定のクラスに結合されていません。Loggerインターフェイスを実装するクラスが必要なだけです。Loggerしかし、これに関する問題は、オブジェクトを作成するたびにインスタンスをコンストラクターに渡す必要があることです。

これに関するもう 1 つの問題は、Logger が実際にはandのPositionようなクラスの一部ではないことです。それは単なるユーティリティです。$x$y

そのような状況にどのように対処するのが最善ですか? この場合、カップリングと結束の間の最適な妥協点は何でしょうか?