Week 2 Summary

  • Review programming style: comments, indentation, line breaks, etc. (see Franke’s Bike Wattage program)
  • Introduction to Karel World
    • HBot Part I by Pairs
    • HBot Part II individually for turning in
  • Karel as a metaphor for a turning machine
    • Karel can only do 4 basic things, just like a computer’s processor - we will go through the experience of building up complicated processes and actions from a very small set of fundamental operations
  • Definitions you need to know:
    • Algorithm
    • variable
    • data type
    • declare a variable vs. initialize a variable vs. use a variable
    • The assignment operator (=) as opposed to a test for equality. Read a =7 as “a gets 7″
    • class
    • class instance
    • instance variable
    • object-oriented
    • the “new” operator for initializing Object variables
    • arithmetic operators (+, -, *, /, %) and the implications of how they operate on different fundamental data types (esp. integer division)
    • methods: object methods, static methods
  • Extending the robot classes to define our own robots.
    • See Ch. 3 of Bergin text
    • DefN: inheritence, sub-class, super-class, parent, child.
    • the difference between defining a new class and using a new class.
    • Why extend a class?  Several reasons any combination of which may apply to your situation.
      • You don’t have access to the source code.
        This is the case for use with Karel J. Robot.  We want to make new robot instructions but we don’t have the UrRobot source code.  We only have a compiled version.  We cannot modify UrRobot, but we can EXTEND it in order to make our new instructions.
      • Promote Code re-use.
        This is a biggie - it’s a major reason why Java is designed the way it is.  Often you have a chunk of code that does something very useful but complicated — think of JFrame.  Once you write the base of JFrame you don’t want to have to write it again.  So instead, you leave the base code of JFrame as generic as possible, and just extend it for any particular task that you need JFrame’s for.
      • Corollary: to force design constraints
        Large programs can get unwieldy and buggy FAST.  But if designers can design a bunch of base classes and require the programmers to extend those classes then it forces everyone to work within the same design concept.  Furthermore, if a bug is found in one of the base classes, a fix applied there will fix it everywhere - imagine if each programmer had their own copy of the base code rather than extending it…yipes.

Leave a Reply

You must be logged in to post a comment.