March 7, 2007

...Learn TDD with Codemanship

OO Metrics - Measuring Package Cohesion

Much of the decision-making in software design is about where to put things. In that sense, software design is largely organisational. For example, what packages should put our classes in? There might be all sorts of reasons for putting a class into a specific package, not least of which might be the common sense question of where people might expect to find it.

Package cohesion should be another strong influence on deciding where to put our classes. The design goal for package cohesion is to place our classes into packages that contain other classes on which they heavily depend.

A neat way of illustrating the principle is to imagine your designing the seating plan for a wedding reception. Anyone who's organised a seating plan - especially for extended families, with all the baggage and history that entails - will know just how thorny a problem it can be.

Ideally, you want your tables to be cohesive; that is, they should accommodate people who get along. The most cohesive table would be one where everybody sitting at it likes everybody else.

But maybe Uncle Bob likes Cousin Kent, but Cousin Kent doesn't like Uncle Bob. (Any similarity to people living or dead is entirely coincidental, of course). So getting a totally cohesive table will be a tough nut to crack.

Imagine we have 3 tables, and each table seats up to 3 people. How would we design our seating plan so that each table is as cohesive as possible? Well, let's start by taking an educated guess:



How cohesive is each table? Well, if total cohesion (100%) means that everybody on a table likes everybody else on that table, then we could start by figuring out how many "likes" that would be. For example, on a table with 3 people, there are 6 potential "likes" on that table.

On Table 1:

Grandpa Gilb COULD like Grandma Gilb
Grandma Gilb COULD like Grandpa Gilb
Grandpa Gilb COULD like Cousin Kent
Cousin Kent COULD like Grandpa Gilb
Grandma Gilb COULD like Cousin Kent
Cousin Kent COULD like Grandma Gilb

So there are our 6 possible "likes", and they would all have to be true for Table 1 to be 100% cohesive. So how cohesive is the seating plan for Table 1 really? Let's count the actual "likes":

Grandpa Gilb DOES like Grandma Gilb
Grandma Gilb DOES like Grandpa Gilb
Grandma Gilb DOES like Cousin Kent

Out of 6 possible "likes", we got 3, so we could say that our seating plan for Table 1 is 50% cohesive.

Repeating the calculation for Table 2 and Table 3, we can see that the average cohesion for the three tables is only 33%. (Table 2 has 50% cohesion, and Table 3 has zero cohesion, since nobody on that table likes anyone else on that table.)

Could we re-arrange our seating plan to improve the average cohesion? (Answers on a postcard, please.)



Now we can apply similar techniques to measuring package cohesion. Instead of people, we wish to seat classes, and instead of seating them at tables, we seat them in packages. And instead of saying "likes" we say "depends on".

The eagle-eyed among you who have read the metrics workshop material on the site will notice that this method of calculating package cohesion differs slightly from the method used in the workshops. I think both are reasonable indicators, but I'm leaning towards this combinatorial technique, largely because I think it better describes what cohesion actually means.
Posted 13 years, 9 months ago on March 7, 2007