One way to organize our thoughts about a possible world is to divide it up into discrete objects, where each object will have a behavior by itself, and it will interact with other objects in some lawful way. If it is useful to decompose a problem in this way then we can construct a computational world, analogous to the"real"world, with a computational object for each real object Each of our computational objects has some independent local state, and some rules(or code), that determine its behavior. One computational object may influence another by sending it messages and invoking methods in the other. The program associated with object describes how the object reacts to messages and how its state changes as a consequence. You may have heard of this idea in the guise of" Object-Oriented Programming systems"(OOPS!). Languages such as C++ and Java are organized around OOP. While OoP has received a lot of attention in recent years, it is only one of several powerful programming styles. What we will try to understand here is the essence of the idea, rather than the incidental details of their expression in particular languages An Object system Consider the problem of simulating the activity of a few interacting agents wandering around different places in a simple world. Real people are very complicated; we do not know enough to simulate their behavior in any detail. But for some purposes(for example, to make an adventure game) we may simplify and abstract this behavior. In particular, we can use objects to capture common state parameters and behaviors of things, and can then use the message-passing paradigm to control interaction between objects in a simulation Let's start with the fundamental stuff first. We can think of our object oriented paradigm as consisting of classes and instances. A class can be thought of as the"template" for how we want a particular kind of object to behave. The way we define the class of an object with a basic"make handler"procedure, this procedure is used with a"create instance procedure which builds for us a particular instance. As you will see, when we examine the code, each class is defined by a procedure that when invoked will create some internal state(including instances of other class objects)and a message passing procedure (created by a"make handler")that returns methods in response to messages Our object instances are thus procedures which accept messages. An object will give you a method if you send it a message, you can then invoke that method (possibly with some arguments )to cause some action, state update or other computation to occur The main pieces we will use in our code to capture these ideas are detailed as follows Instance of an object- each individual object has its own identity. The instanceOne way to organize our thoughts about a possible world is to divide it up into discrete objects, where each object will have a behavior by itself, and it will interact with other objects in some lawful way. If it is useful to decompose a problem in this way then we can construct a computational world, analogous to the "real" world, with a computational object for each real object. Each of our computational objects has some independent local state, and some rules (or code), that determine its behavior. One computational object may influence another by sending it messages and invoking methods in the other. The program associated with an object describes how the object reacts to messages and how its state changes as a consequence. You may have heard of this idea in the guise of "Object-Oriented Programming systems"(OOPs!). Languages such as C++ and Java are organized around OOP. While OOP has received a lot of attention in recent years, it is only one of several powerful programming styles. What we will try to understand here is the essence of the idea, rather than the incidental details of their expression in particular languages. An Object System Consider the problem of simulating the activity of a few interacting agents wandering around different places in a simple world. Real people are very complicated; we do not know enough to simulate their behavior in any detail. But for some purposes (for example, to make an adventure game) we may simplify and abstract this behavior. In particular, we can use objects to capture common state parameters and behaviors of things, and can then use the message-passing paradigm to control interaction between objects in a simulation. Let's start with the fundamental stuff first. We can think of our object oriented paradigm as consisting of classes and instances. A class can be thought of as the "template" for how we want a particular kind of object to behave. The way we define the class of an object is with a basic "make handler" procedure; this procedure is used with a "create instance" procedure which builds for us a particular instance. As you will see, when we examine the code, each class is defined by a procedure that when invoked will create some internal state (including instances of other class objects) and a message passing procedure (created by a “make handler”) that returns methods in response to messages. Our object instances are thus procedures which accept messages. An object will give you a method if you send it a message; you can then invoke that method (possibly with some arguments) to cause some action, state update, or other computation to occur. The main pieces we will use in our code to capture these ideas are detailed as follows: Instance of an object – each individual object has its own identity. The instance knows its type, and has a message handler associated with it. One can “ask” an object to do something, which will cause the object to use the message handler to