Building from ''See http://www.kinetica.com/ootips/finding-objects.html'', which asks, "How do you find the objects for an object oriented design?"
-----
Finding objects is easy - so easy that I never try to tell people how to find them.  You find them all over the place, in the air, by your feet, in the problem statement, in your speaking, etc.  The problem is - which do you keep?

For a problem in which you will end up with, say, 27 classes, you might easily think up 60 prospects.  If you have DesignPatterns at your fingertips, you can double that with wrappers and strategies and decorators and what-not.  You have to decide against 30-90 prospects to keep the 27 you need.

There is no way I know of to deduce the existence and name of a class.  You just speak it (or, if you use CRC cards, start moving it around).  It is raw invention, whether you say you are doing semantic modeling, class modeling, role modeling, or CRC cards.

There are, however, decent ways to decide which to keep.  ResponsibilityAlignment is my favorite.  Some others, named in a C/C++ Users Journal article [1], are: 

			1.Data Connectedness
			2.Abstraction
			3.ResponsibilityAlignment
			4.Data Variations
			5.Evolution
			6.Communications Patterns
I expect there are others, but these are in common use and work well.  --AlistairCockburn

There's the TRIES criteria. A good TRIES object then would represent at least one of:

	* a Tangible thing in the problem domain
	* a Relationship between things
	* an Interface to something
	* an Event
	* a Specification for something
----

[1] http://www.cuj.com/archive/1606/feature.html
''(BrokenLink... A search for "Evolution" turns up http://www.cuj.com/articles/1998/9806/9806d/9806d.htm - is that it, Alistair ?)''
----
CategoryDiscovery