Objects and Classes

• An object can be a physical entity, such as a chair. You can describe them, take actions on them, change some of their attributes and sometimes convert them. An object may also be intangible (incomprehensible), such as a job or university course.
• Even though a job is not something you can touch, it is something you can describe, discuss, assign, and complete. Anything that you can describe can be represented as an object, and that representation can be created, manipulated, and destroyed to represent how you use the real object that it models.
• An object is the representation of a specific entity in the real world, such as a specific person or a specific order. A class is the rules that define the object. Since the individual representation for objects need to have the same information, we create a single set of rules that apply to all objects. The set of rules is called a class. A class is a definition, a template, that describes how to build an accurate representation of a specific type of object. Each object is instantiated (created, made real) by using the class definition as a template. Yet each object, each instance of the class, can be described using unique values for each of the rules that the class defines.

Abstractions of Objects

• To use objects, we first need to distinguish between a real object and the representation of an object. In software projects we are nearly always working with representations of objects. The system needs to manage the representation to reflect how you are managing the real objects. For example, an order-processing system needs to manage customers, orders, and products. The software does not directly manipulate customers, orders, or products. Instead the software creates representations called abstractions, a general term referring to the use of objects and classes. The software then manages the abstractions to coincide with changes occurring to the real world objects. Figure below shows that when a real customer places an order for a product, the software creates an order object (abstraction) that associates the customer (abstraction) with the product (abstraction).
• The quality and value of the abstraction are defined by how well it represents the real-world objects in terms of the information we need to maintain about them and the things we need to do with them.
• Figure above actually poses a problem because all of the images in it are abstractions, that is, the pictures of the people and the products are abstractions, representations of real people and products. If the image is good enough to convey the needed information for the example, then it is a successful abstraction. So an abstraction represents something in the real world. An abstraction describes that "something" using only the information that supports how we plan to use it.
• The reason we create abstractions is get work done. We need to create, manipulate, and dispose of information to reflect how we create, manipulate, and dispose of real things. So to create an appropriate abstraction, we must understand the real-world problem that the abstraction represents.

Defining an Object

• First, an object has to describe the features of an entity that will allow users of the object to distinguish it from other objects. It needs to have an identity. But even if an object does not own a unique identification number, it still has a unique identity. Even if two objects share the same features, each object has a unique identity.
• Second, an object must be able to describe itself. Descriptive information is often called object structure, the information used to create object.
• Third, each object must be able to describe its current condition, called its state. Object state is sometimes represented by the values of each of its features. Other times, the state is represented by the presence or absence of key relationships with other objects. Sometimes a single status code represents an object's state. But more often than not, that status code represents a unique combination of feature and relationship values that together define the current condition of the object.
• In some cases, an object may even contain information about the system. It means some objects are created simply to hold and protect information generated by the system. The object does not create or even really own the information. It is simply a steward to information, a repository. For example, log files record events that occur during the execution of an application. The log file does not create the information. The information does not describe either the log file or its state. The log file simply provides a place to store the information until someone asks for it. Not every feature of an object defines its state. So in order for an object to be useful, it must know:

1. Its unique identity.
2. How to describe itself.
3. Its current condition, or state.

• We create objects to represent real world entities because we need to do something. For years software systems were designed with the information about an object separate from the behavior that uses the object. For each use of the object in a different context there was typically a different program. Unfortunately, this approach led to some serious and costly problems. Namely, because many programs could use the same object, it was common for them to require some of the same behaviors. So the same behavior was coded into a number of programs with no guarantee that each program wrote the behavior in the same way. Maintaining the object meant maintaining all the code spread across all the programs that use the object. The separation of the behavior from the information about the object resulted in redundant descriptions of behavior, lack of integrity among the many definitions, and high cost to maintain the redundant codes.
• Object-orientation proposed that the behavior should be defined once, regardless of who uses the behavior, and that the behavior should be stored with the object. Using this approach to organizing the code, anyone who wants to know how to use the object correctly simply looks at the behaviors defined in the object itself. The added benefit to this approach is simpler code in the programs that use the object. Instead of writing the behaviors in the programs, the programs simply invoke behaviors already defined in the object. So in order for an object to be useful, the object must know: What it can do and what can be done to it.

Encapsulation