6.001 Structure and Interpretation of Computer Programs. Copyright o 2004 by Massachusetts Institute of Technology Slide 14.1.6 Space War Class Diagram with Inheritance Conceptually we should be able to do this. Without worrying IMOBILE-THING about implementation details, let's first pull out that common pattern in our class diagram. Here is an abstraction of that common pattern, a new class called a mobile-thing. It has two state variables, position and velocity, and it has some common methods for dealing with those variables. These variables and methods will hold for any mobile object. We will, of course, clude a type tag for this new kind of class, as well. And th thus defi Slide 14.1.7 Space War class Diagram with Inheritance Given that new class, we can now create specializations. We can MOBILE-THING create a subclass. a torpedo is a particular kind of mobile thing It has all the properties of mobile things, but it also has characteristics that are particular to torpedoes. Similarly, a ship is a kind of mobile thing; it's a specialization that has, in addition to the properties of mobile things, other characteristics that matter only to ships Space War Class Diagram with Inheritance Slide 14.1.8 SHiP class is a specialization or As we start designing our system, we can begin to put together sub-class of the MOBILE -THING class hierarchies of class diagrams. We have base classes like mobile SHIP inherits the state an things. We also have some specializations or subclasses so that VELOCE havior of MOBILE-THING for example a ship is a mobile thing and should therefore inherit t he 5HTP and o PE o casses the state and behavior of a mobile thing, as well as having its own properties. In the other direction, we say that the mobile thing class is a super-class of the ship and torpedo classes Now we can start building a broader set of designs in which we have hierarchies of information captured in different I specializations of different classes of objects Slide 14. 1.9 Space War Class Diagram with Inheritance And as we fill out our class diagram we will have different IMOBILE-THING relationships between the classes. Torpedoes, for example, can sub-class sa special have a class as a link: targets are always going to be elements of SHIP inherits the state and the ship class behavior of MOBILE-THING Note that one of the advantages of creating super-classes is that we can nicely isolate the code for the methods of the super classes so that if we want to change one of those methods, we TORPEDO only need to worry about the implementation of the super-class, proxim ATTACK not about all of the specializations. If for example we decide to CLOCK-TICK change how things move, we don't have to search for all the move methods in the different subclasses, we need only change the method in the super-class This gives us a nice6.001 Structure and Interpretation of Computer Programs. Copyright © 2004 by Massachusetts Institute of Technology. Slide 14.1.6 Conceptually we should be able to do this. Without worrying about implementation details, let's first pull out that common pattern in our class diagram. Here is an abstraction of that common pattern, a new class called a mobile-thing. It has two state variables, position and velocity, and it has some common methods for dealing with those variables. These variables and methods will hold for any mobile object. We will, of course, include a type tag for this new kind of class, as well. And this thus defines a new class. Slide 14.1.7 Given that new class, we can now create specializations. We can create a subclass. A torpedo is a particular kind of mobile thing. It has all the properties of mobile things, but it also has characteristics that are particular to torpedoes. Similarly, a ship is a kind of mobile thing; it's a specialization that has, in addition to the properties of mobile things, other characteristics that matter only to ships. Slide 14.1.8 As we start designing our system, we can begin to put together hierarchies of class diagrams. We have base classes like mobile things. We also have some specializations or subclasses so that for example a ship is a mobile thing and should therefore inherit the state and behavior of a mobile thing, as well as having its own properties. In the other direction, we say that the mobile thing class is a super-class of the ship and torpedo classes. Now we can start building a broader set of designs, in which we have hierarchies of information captured in different specializations of different classes of objects. Slide 14.1.9 And as we fill out our class diagram, we will have different relationships between the classes. Torpedoes, for example, can have a class as a link: targets are always going to be elements of the ship class. Note that one of the advantages of creating super-classes is that we can nicely isolate the code for the methods of the super￾classes so that if we want to change one of those methods, we only need to worry about the implementation of the super-class, not about all of the specializations. If for example we decide to change how things move, we don't have to search for all the move methods in the different subclasses, we need only change the method in the super-class. This gives us a nice