A terribly un-OOPish solution to an expanded Lab 12

The file codeA.pdf is a printout of a solution to a slightly expanded version of Lab12 ... a very un-Object Oriented solution. In class, as a reprise and review of the basic tenants of object oriented programming, we'll look over this printout identify what makes it so un-OOP.

A very OOPish solution to the expanded Lab12

Also in class, as a further reprise and review of good object oriented design, we'll discuss what a good object oriented solution would look like. The file codeB.pdf has a nice object oriented solution. It contains the kind of things we discussed.

So what does the good OOPish solution buy us?

As we've seen over and over again, a good OOPish design is much easier to expand and modify ... and to debug in the first place. To give you a smidgen of an idea of how that plays out in this case, to add more planets, and deeper nesting of orbits, we just need to add a few lines to the DrawArea constructor. To add a capsule orbiting the moon we'd just do:

    Planet caps = new Orbit(moon,
			    Color.BLUE,2,10,0,0.08,
			    Color.BLUE);

... and change the line that creates the planets array to:

planets = new Planet[]{sun,earth,moon,caps,ufo};

More interestingly, what if we wanted to add some "Planet" with decaying orbits? Well, our Orbit class needs a bit more functionality to do that nicely. We'd have to add

  public double getOrbitRadius() { return orbitRadius; }
  public void setOrbitRadius(double dr) { orbitRadius = dr; }

to Orbit.java. But with that in place, a decaying orbit class is simply an extension of the Orbit class in which we override the step() method to reduce the radius as well as change the angle.

Distributable Java programs: jar files

A runnable Java program is typically defined by a collection of .class files. You "run" the program by executing the JVM with the name of the class whose main() method is supposed to kick off the program, and as the JVM encounters references to classes it doesn't know about, it looks around for the .class files for those classes, loads them, and continues. It would be quite painful to distribute even relatively small Java programs if it had to be done in this form. The instructions would look like "Download and save the following 27 .class file ...". To get around this, Java has a file format called .jar files, that package many .class files into a single file. If you have a .jar file called Foo.jar, you can run the program it contains with the command:

java -jar Foo.jar

The one thing that's not clear, however, is what class has the main() method that should start things off. After all, many .class files could contain main() methods. The way this is handled is that a file called Manifest.txt is bundled together with all the .class files in the jar file. And Manifest.txt has a line that states which class has the main() method that should be called to kick off the program. Assuming we have the program L12 defined above, we would create a jar file by first creating the file Manifest.txt:

Manifest.txt

Main-Class: L12

... and then giving the following command:

jar cfm SolarSystem.jar Manifest.txt *.class

This creates the file SolarSystem.jar that we can send off to other people, who can run it (on any platform with a JVM) with the command:

java -jar SolarSystem.jar

Since the "compiled" code is byte-code compiled for the JVM, rather than true machine-code, it can be run anywhere ... provided the host platform supports the version of Java you compiled to.

For your viewing pleasure, I've included SolarSystemA.jar and SolarSystemC.jar for you to run. Note: beware of running .jar files when you're not absolutely sure that a) the person who wrote it is on the up and up, and b) that you're really gotten the file you think you have!