I was reading Kent Becks’ Smalltalk Patterns^{1} and he mentioned quite early on that it is important to **factor** the design correctly in terms of small, cohesive classes. It wasn’t until I read this that I had made the connection between “Refactor” and “Factor” and hence the mathematical definition of a factor.

Suddenly I thought I saw what he was talking about. **Code** can be broken down into **factors** which is when it becomes more flexible or **supple** (in the language of domain driven design).

In mathematical terms, a factor is a number which can be combined with another number to produce a given result. So the factors of `10`

are `{1, 2, 5 and 10}`

. Those of `12`

are `{1, 2, 3, 4, 6 and 12}`

.

Let’s say you represent a piece of code as say `12`

, perhaps it is one big class doing several things. Ok, you can have one big class, maybe its easy to find everything there because its all in one place. However, you could also break it into two classes. Perhaps one is equivalent to say `3`

and the other is `4`

. So `3 * 4`

still equals `12`

right?

What happens if you factor the `4`

into `{2, 2}`

. Now you have `{2, 2, 3, 4}`

You can now make quite a few different “products” of these factors, not **just** `12`

, e.g. `2 * 3 = 6`

. Further, you can make combinations of these intermediate products aswell, e.g. `2 * 2 * 4 = 16`

I thought this was an interesting way to look at factoring (or re-factoring), and possibly a useful analogy to explain it. I had not heard it being talked about in this way before.

^{1} Kindly lent to me by Pat

Pingback: Persona测试数据 « I am Hu Kai