6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 14.1.3 Recall from last time the example we used to demonstrate object- Space War Class Diagram oriented systems. That example was a system for simulating a simple"star wars"scenario. In that system, we had class ch as those shown here. We had a class for ships TORPEDO class for planets, a class for torpedoes, and some other classes that we have not shown here. recall that for each class. we had two sets of things internal state variables which characterized CLOCK-TICK the state of each instance of the class and a set of methods the things that the class able of doing. Those me were characterized by the instance accepting a message of the same name, then performing some interaction between different 4 objects within the system or changing the status of the internal state variables of an instance Space War Class Diagram Slide 14.1. 4 In order to make a point, I have changed slightly my definition of a torpedo. Last time a torpedo just used a position and a elocity, and it moved until it hit some thing, at which point it ANET exploded. A smarter torpedo might explicitly seek some target. and use a state variable like a proximity fuse, so that when the CLOck-Ic torpedo got close enough to its target it would explode One reason for introducing this is to notice that state variables within our instances could actually point to other instances. So the state variable for a target would point to another class, a ship n this case Slide 14.1.5 Space War class Diagram However, the real point we want to draw attention to in this diagram is the commonality, particularly the commonality fly, they both therefore have state information about positian between ships and torpedoes. Note that both of these objects can ORPEDO velocity, they both have methods that deal with position anand elocity; thus they have a lot of things in common, as well as CK-TICK having a few distinctive properties We know that a common theme in this course is capturing common patterns and abstracting them. so the issue here is Ships and torpedoes have some behavior that is the same whether we can do the same thing in an object-oriented system is there are way to capture this commonality? Can we take advantage of the fact that torpedoes and ships share a lot in common, and use that to build more modular systems?6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 14.1.3 Recall from last time the example we used to demonstrate object￾oriented systems. That example was a system for simulating a simple "star wars" scenario. In that system, we had class diagrams such as those shown here. We had a class for ships, a class for planets, a class for torpedoes, and some other classes that we have not shown here. Recall that for each class, we had two sets of things: internal state variables, which characterized the state of each instance of the class, and a set of methods, the things that the class was capable of doing. Those methods often were characterized by the instance accepting a message of the same name, then performing some interaction between different objects within the system or changing the status of the internal state variables of an instance. Slide 14.1.4 In order to make a point, I have changed slightly my definition of a torpedo. Last time a torpedo just used a position and a velocity, and it moved until it hit some thing, at which point it exploded. A smarter torpedo might explicitly seek some target, and use a state variable like a proximity fuse, so that when the torpedo got close enough to its target it would explode. One reason for introducing this is to notice that state variables within our instances could actually point to other instances. So the state variable for a target would point to another class, a ship in this case. Slide 14.1.5 However, the real point we want to draw attention to in this diagram is the commonality, particularly the commonality between ships and torpedoes. Note that both of these objects can fly, they both therefore have state information about position and velocity, they both have methods that deal with position and velocity; thus they have a lot of things in common, as well as having a few distinctive properties. We know that a common theme in this course is capturing common patterns and abstracting them. So the issue here is whether we can do the same thing in an object-oriented system. Can we take advantage of the fact that torpedoes and ships share a lot in common, and use that to build more modular systems?