6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology 6.001 Notes: Section 14.1 Slide 14.1.1 Elements of ooP Last time we introduced the idea of object oriented systems Today, we want to build on those basics, looking at how we can expand object-oriented systems to deal with hierarchies of objects, to leverage the commonality of methods between different kinds of objects. We are going to see how the same ideas of abstraction allow us to control complexity in object oriented systems, much as they did in procedural systems. We are also going to show a version of a Scheme based object- oriented system. Note that this is not an optimal implementation of an object-oriented system compared to say Java or C++, but the goal is to show how one could create and manipulate an object-oriented system using the tools we have already developed. Our intent is to separate these issues; highlighting the concepts of object-oriented systems, while grounding those concepts in a specific instantiate Elements of ooP lide14.1.2 To start, let me remind you of what we have already seen. we hart data structure are trying to large system around a collection of objects. An object can be thought of as a"smart"data structure; Set of methods for manipulating state variables a set of state variables that describe the object; and an associated set of methods for manipulating those state variables. We expect Specifies the common behavior of entities our systems to have many different versions of the same kind of Instance object. For instance, think of bank system in which we might A particular object or entity of a given class have many different accounts. Each account would have a set of data values: current balance, overdraft protection, pending deposits. Thus there is the notion of an account as an abstract structure, and there is notion of different, specific versions of this abstract structure. Thus, we make a distinction. a class will define the common behavior of a kind of object in our ystem, the collection of things that are going to behave in the manner defined by those commonalities. Instances capture the specific details of an individual version of that class Our goal is to see how to structure computation within this new paradigm, in which the central units are"smart data structures. Thus, when we design a system we will tend to focus on the classes, as those are the basic building blocks of our system. The"programming of these systems will tend to focus on the interactions and behaviors of the classes: how should changes in one instance of an object affect other aspects of that object or other objects in the system? When we want to actually run our system, say to simulate a behavior, we will use the classes to create the instances that are particular versions of things, and then see how those specific instances interact6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. 6.001 Notes: Section 14.1 Slide 14.1.1 Last time we introduced the idea of object oriented systems. Today, we want to build on those basics, looking at how we can expand object-oriented systems to deal with hierarchies of objects, to leverage the commonality of methods between different kinds of objects. We are going to see how the same ideas of abstraction allow us to control complexity in object￾oriented systems, much as they did in procedural systems. We are also going to show a version of a Scheme based object￾oriented system. Note that this is not an optimal implementation of an object-oriented system compared to say Java or C++, but the goal is to show how one could create and manipulate an object-oriented system using the tools we have already developed. Our intent is to separate these issues; highlighting the concepts of object-oriented systems, while grounding those concepts in a specific instantiation in Scheme. Slide 14.1.2 To start, let me remind you of what we have already seen. We are trying to organize a large system around a collection of objects. An object can be thought of as a “smart” data structure; a set of state variables that describe the object; and an associated set of methods for manipulating those state variables. We expect our systems to have many different versions of the same kind of object. For instance, think of bank system in which we might have many different accounts. Each account would have a set of data values: current balance, overdraft protection, pending deposits. Thus there is the notion of an account as an abstract structure, and there is notion of different, specific versions of this abstract structure. Thus, we make a distinction. A class will define the common behavior of a kind of object in our system, the collection of things that are going to behave in the manner defined by those commonalities. Instances capture the specific details of an individual version of that class. Our goal is to see how to structure computation within this new paradigm, in which the central units are “smart” data structures. Thus, when we design a system we will tend to focus on the classes, as those are the basic building blocks of our system. The “programming” of these systems will tend to focus on the interactions and behaviors of the classes: how should changes in one instance of an object affect other aspects of that object or other objects in the system? When we want to actually run our system, say to simulate a behavior, we will use the classes to create the instances that are particular versions of things, and then see how those specific instances interact