Of course, the reason we're developing applications in the first place is to solve some problem or automate some process. Having a set of abstract objects in software that represent physical objects can simplify this whole process.
As we'll see in Chapter 3, we can identify and design our objects in such a way that they provide a model of our business domain. With our initial identification of these business objects, we can then begin to model the business process we want to automate - or the problem we need to solve.
We can draw a picture showing how these objects relate or interact with each other in the real world. Using that picture, we can make our software objects work with each other in the same way. Essentially, we're defining relationships between our various business objects, showing how each object calls methods of other objects in order to simulate the real-world process.
This is a very intuitive approach to software development, since our applications become software models of the real world.
We've already started to do this with our description of an employee creating a work order and so forth. If we break that statement down into pieces, we can see a number of similar interactions between these objects:
I'll demonstrate the whole process of creating and modeling objects in Chapter 3, when we get into some more specific examples.