The world around us is made up of both physical objects and concepts. To effectively model or simulate the real world and human processes in our code, it would be good if our software could be made up of representations of these real-world objects. As we have seen in the previous section, object-oriented programs attempt to do just that.
Business objects are designed to represent real 'objects' and concepts in our business. Here are some examples of these real 'objects':
All of these are objects in the physical world, and the whole idea behind using software business objects is to create representations of these same objects inside our applications. Then our application can make these objects interact with each other just as they would in the physical world. For instance, an employee might create a work order to build a manufactured part from one or more purchased parts that are then sold to the customer.
Following this logic, we can create a work order business object that contains all the code it needs to manage itself - so we never need to replicate code to create work orders, we just use the object.
Similarly, a customer object contains and manages its own data. A well-designed customer object can contain all the data and routines needed to represent a customer throughout an entire business and this can be used across all the applications for that business. We may use our customer object when taking an order. We might later use it when sending out a bulk mailing and analyzing sales patterns - without affecting any of the code that uses the object to take an order. Of course, over time, the customer object may evolve: it may gain new properties or new methods to support more functionality; the point is that the previous properties and methods can and should remain the same, so that existing applications need not be changed.