23 - WHERE DO OBJECTS COME FROM?

Summary

The previous column got me started examining why people create classes. About this time, I had collected enough patterns to begin thinking about the patterns book. Of course, at first I was going to cover all of programming/analysis/design/project management/etc. in a single book. This exploration was the beginning of trying to write the analysis/design portion of the book.

One of the things I like about writing a column is that it forces you to think hard about a topic at regular intervals. I'm the kind of person who dives deep into a topic until I'm bored, and then drifts until something else catches my eye. I get to study lots of cool stuff that way, but I don't really penetrate to insight. Writing a column returns me to roughly the same place every month and pushes me to find something new. The result is much more valuable thinking.

Previously, I talked about how objects could be created from the states of objects that acted like finite-state machines (the “Objects from States” pattern). I'll continue on the theme of where objects come from for this and several issues.

I won't be saying much about the conventional source of objects, the user's world. There are lots of books that will tell you how to find those objects. Instead, I'll focus on finding new objects in running programs.