Spójność jest miarą jakościową, co oznacza, że kod źródłowy, który ma zostać zmierzony, jest badany przy użyciu rubryki w celu określenia klasyfikacji. Typy spójności, od najgorszego do najlepszego, są następujące:
Spójność przypadkowa (najgorsza) Spójność przypadkowa jest wtedy, gdy części modułu są pogrupowane arbitralnie; jedynym związkiem między częściami jest to, że zostały zgrupowane razem (np. klasa „Utilities”). Przykład:
/*Groups: The function definitionsParts: The terms on each function*/Module A{ /* Implementation of r(x) = 5x + 3 There is no particular reason to group functions in this way, so the module is said to have Coincidental Cohesion. */ r(x) = a(x) + b(x) a(x) = 2x + 1 b(x) = 3x + 2}
Spójność logiczna Spójność logiczna jest wtedy, gdy części modułu są zgrupowane, ponieważ są logicznie skategoryzowane do robienia tej samej rzeczy, mimo że są różne z natury (np. zgrupowanie wszystkich procedur obsługi wejścia myszy i klawiatury). Spójność czasowa Spójność czasowa jest wtedy, gdy części modułu są pogrupowane według tego, kiedy są przetwarzane – części są przetwarzane w określonym czasie wykonywania programu (np. funkcja, która jest wywoływana po złapaniu wyjątku, która zamyka otwarte pliki, tworzy dziennik błędów i powiadamia użytkownika). Spójność proceduralna Spójność proceduralna ma miejsce wtedy, gdy części modułu są pogrupowane, ponieważ zawsze wykonują się w określonej sekwencji (np. funkcja, która sprawdza uprawnienia do pliku, a następnie otwiera plik). Spójność komunikacyjna/informatyczna Spójność komunikacyjna ma miejsce wtedy, gdy części modułu są zgrupowane, ponieważ operują na tych samych danych (np. moduł, który operuje na tym samym rekordzie informacji). Spójność sekwencyjna Spójność sekwencyjna ma miejsce wtedy, gdy części modułu są zgrupowane, ponieważ wyjście z jednej części jest wejściem do innej części, jak w przypadku linii montażowej (np. funkcja, która odczytuje dane z pliku i przetwarza je). Spójność funkcjonalna (najlepsza) Spójność funkcjonalna jest wtedy, gdy części modułu są pogrupowane, ponieważ wszystkie one przyczyniają się do realizacji jednego, dobrze zdefiniowanego zadania modułu (np. analiza leksykalna łańcucha XML). Przykład:
/*Groups: The function definitionsParts: The terms on each function*/Module A { /* Implementation of arithmetic operations This module is said to have functional cohesion because there is an intention to group simple arithmetic operations on it. */ a(x, y) = x + y b(x, y) = x * y}Module B { /* Module B: Implements r(x) = 5x + 3 This module can be said to have atomic cohesion. The whole system (with Modules A and B as parts) can also be said to have functional cohesion, because its parts both have specific separate purposes. */ r(x) = .a(.b(5, x), 3)}
Spójność idealna (atomowa) Przykład.
/*Groups: The function definitionsParts: The terms on each function*/Module A { /* Implementation of r(x) = 2x + 1 + 3x + 2 It's said to have perfect cohesion because it cannot be reduced any more than that. */ r(x) = 5x + 3}
Ale spójność jest skalą typu rankingowego, rangi nie wskazują na stały postęp poprawy spójności. Badania przeprowadzone przez różnych ludzi, w tym Larry’ego Constantine’a, Edwarda Yourdona i Steve’a McConnella wskazują, że pierwsze dwa typy spójności są gorsze, spójność komunikacyjna i sekwencyjna są bardzo dobre, a spójność funkcjonalna jest lepsza.
Pomimo, że spójność funkcjonalna jest uważana za najbardziej pożądany typ spójności dla modułu oprogramowania, może nie być osiągalna. Istnieją przypadki, w których spójność komunikacyjna jest najwyższym poziomem spójności, jaki może być osiągnięty w danych okolicznościach.