A factor is an aspect of a program that can be thought about relatively independently of the rest of the program
Relation between Factors and Patterns
When you ReFactor
a program you are explicitly or implicitly FactorFinding
. The improvement in design comes about because the modified design now explicitly recognizes an independent aspect that was buried unrecognized within a monolithic block. You're also now better able to vary that aspect. Some factors may correspond directly to DesignPatterns
or to OptimizationPattern
s, but they don't have to.
When a DesignPattern
is really earning its keep we have:
- A program designed in terms of
- independent factors which are implemented
When we're refactoring or optimizing we may have to make do with:
- A program that we can view as
- independent factors which are
- captured by macros and comments in the code
It isn't that useful to have wiki pages for Factors that correspond to the underlying objects of individual DesignPatterns
. Evidence: We very rarely have Wiki Pages for Objects
It could be argued and look someone just has
that it is useful to have Wiki pages for the Factors that relate to RefactoringPatterns
and to OptimizationPattern
s. In these cases the underlying Factors may make it easier to clarify the patterns and their applicability.
I will argue that it is useful to have Wiki pages for the Factors that don't yet show up as DesignPatterns
s. The Factors are a hint to us that there is a useful pattern to be described, and a hint to language designers to boot.
Trouble with the Definition
If you've read RichardDawkins
trying to define what a 'gene' is in TheSelfishGene
, you'll know something of what the problem is in defining what a 'Factor' in a program is. Something is more or less a Factor to the extent that it is more or less independent of the rest of the program, but 'relatively independent' is hard to define with more precision.