27
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

凝集度について

Last updated at Posted at 2020-04-27

#はじめに
良い設計をしていくにあたり「結合度」や「凝集度」といった基準があります。
プログラムを書くにあたり、必ず知っておくべき基本的な設計原則です。
今回はその中でも「凝集度」について説明していきたいと思います。

結合度についてはこちら

#凝集度とは

情報工学においてモジュール内のソースコードが特定の機能を提供すべく如何に協調しているかを表す度合い。
凝集度の高いモジュールは、堅牢性、信頼性、再利用性、読みやすさなどの点で好ましくなります。
(Wikipedia引用)

#凝集度の種類

凝集度は7段階のレベルで表すことが出来ます。

レベル 名前 内容
1 機能的凝集 単一の目的しか持たない機能を実行するモジュール
2 逐次的凝集 同一データを順番的に扱うモジュール
3 通信的凝集 同一データを扱う部分を集めたモジュール
4 手順的凝集 処理の流れをそのまま詰め込んだようなモジュール
5 一時的凝集 同じタイミングで発生する関係ない機能を集めたモジュール
6 論理的凝集 お互いに関係ない機能の一つを実行するモジュール
7 偶発的凝集 関係ない機能が集められたモジュール

1が最も凝集度が高く、良い設計と言える。
数字が大きくなるほど凝集度が低くなり、低凝集となる。

良し悪しをはっきり区切ると
良い凝集 は 1~3

1 - 機能的凝集
2 - 逐次的凝集
3 - 通信的凝集

悪い凝集 は 4~7

4 - 手順的凝集
5 - 一時的凝集
6 - 論理的凝集
7 - 偶発的凝集

それぞれについて詳しく説明していきます。

##1. 機能的凝集

単一の目的しか持たない機能を実行するモジュールです。

image.png

例)肥満度を判定する。

~を...するという形で表すことができます。

##2. 逐次的凝集

同一データを順番的に扱うモジュールです。

image.png

例)体脂肪率を計算し、値が正常であるかチェックする。

「値が正常である」ことは「体脂肪率を計算」しないと分からないので、必然的な順序が存在します。
かつ単一のデータを扱っていると逐次的凝集になります。

単一のデータとは一つのデータという意味ではなく、一つのまとまりのあるデータのことを指します。

一般的に体脂肪率は、体重と体脂肪量の2つのデータで計算されます。
これら二つは体脂肪率を計算するうえではまとまりのあるデータと言えます。

##3. 通信的凝集

同一データを扱う部分を集めたモジュールです。

ここまでが良い凝集です。

image.png

例)体脂肪率変化を判定し、肥満度を判定する。

扱っている関心ごとは一つだが、それぞれの機能に必然的な順番はないです。

つまり、この場合「体脂肪率の変化の判定」と「肥満度の判定」の順番を逆にしても成り立ちます。

##4. 手順的凝集

処理の流れをそのまま詰め込んだようなモジュールです。

ここからは悪い凝集になります。

image.png

例)体脂肪率を計算し、画面に表示する。

逐次的凝集のように機能に順番があるが、「体脂肪率の計算」と「画面に表示する」で使用するデータが異なるので手順的凝集度になります。

問題点

仕様変更で機能が「体脂肪率の計算」して「画面に表示」して「LEDを光らせる」というように
仕様変更で機能が増えるごとに関数が大きくなり理解がし辛くなります

##5. 一時的凝集

同じタイミングで発生する関係ない機能を集めたモジュールです。

image.png

例1)画面を初期化して、ユーザー情報を初期化して、測定器を初期化する

例2)エラーLEDを点滅させて、入力待ち状態に戻る

例のように目的が違うものをタイミングが同じというだけでまとめてしまうのは低凝集となります。

問題点

違うデータや目的のものを一斉に扱うので、影響範囲が広く保守がし辛くなります。

##6. 論理的凝集

お互いに関係ない機能の一つを実行するモジュール

image.png

例)ユーザー情報を初期化する、またはユーザーを書き換える。

分岐させることが悪いことではありません。

分岐先の処理がお互いに関係ないことが問題です。

問題点

外部からの指示によって処理結果が変わるので可読性が悪いです。
また、複数のデータを扱う可能性が非常に高いです。
仕様変更で機能が追加されることも考えられます。
とにかく保守性が悪いです。

##7. 偶発的凝集

複数のデータが扱われていたり、関係ない機能が集められたモジュールです。

問題点

問題点しかないです。やめましょう。

#まとめ

最初にも書きましたが、凝集度の高いモジュールは、堅牢性、信頼性、再利用性、読みやすさが向上します。

問題点をいくつか書きましたが、以下のことをすることで高凝集になり解決できます。

「単一データを扱うようにモジュール化 (関数分割) する」

関数分割をすると関数呼び出しをするため処理速度が遅くなると言う人もいるかもしれないです。
しかし、今の時代PCの処理はナノ秒という速度なので、凝集度などで保守性を上げることのほうが大切と言えるでしょう。

コードを書く際やレビューをする際などは

  1. 機能的凝集
  2. 逐次的凝集
  3. 通信的凝集

を意識して書いていくことを強くオススメします。

##最後に

今回モジュールに着目して書きましたが、ファイルの分割やクラスにも当てはめることができます。

保守性の高いコードを書くことは会社にとっても自分にとっても良いことです。

自分もできていませんが、他の人が読んでも分かりやすいコードを目指しましょう!

27
16
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
27
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?