Object-Oriented Programming

OOP Class Notes for 9/12/13

Object Oriented Programming Design

• How do we get started?
  • Knowing what to design: translator from Java source code to C++ source code
  • Need/have: have an expert on the subject or domain of interest
• CRC cards and UML diagrams
  • Training wheels for OOP design
  • Our textbook covers this in a few pages. Note: Wikipedia also covers it but mostly in minor detail
• Mentality of what we need to get started
  • Simple start: Input and Output
  • In our case, we input Java source code "a program" and get C++ source code as an output
  • How do we know that the translator is working? Behavior of the resulting C++ code is the same as Java source code. As an added note, the input is assumed to be perfectly complete and correct (i.e. compiles with javac)
  • Testing strategies:
    • Write Java programs that are test inputs and use translator.
    • Compile and run C++ output; then compare (needs a debugger).
  • How to store the source code: data representation
  • Trees:
    • Abstract syntax tree: what is important for the actual translation are the syntactic constructs of the language not how they are represented in the source code.
    • Concrete syntax tree (aka parse tree): tree that represents the actual source code.
  • 1st phase: Read in "parse"
  • xtc will handle the parsing
  • Next phase: Analyze
  • In analyzing code: take note of dependencies, read them in, and translate the dependencies
  • Code should iterate between analyze and parse.
  • Next phase: translation scheme
  • Next phase: Pretty print C++ Code.
  • The purpose of pretty printing C++ code is so that we don't shoot ourselves in the foot when we look at the output
  • Important note: Mistakes can be made in translator or debugger. Thus the best way to check is to look at the C++ source code.
  • Time spent on pretty printing is well worth it.
  • Checking your code:
  • Problem: hand written and computer generated code: spacing might be different. If translation scheme changes, things might be tricky and different.
  • More in Depth on Trees
  • AST: statically typed tree
  • You can have all phases in one class but that only works with a statically typed tree
  • In one class: + everything together per data kind + easier to add a new data kind
  • Data kinds are fixed in this case but there will be more phases that will be changed from midterm to final
  • AST: figure out one way to map to the other is the general translation
  • Alternative: dynamically typed tree - Trade off: safety for flexibility
  • Class per phase: + everything together per phase + easier to add a new phase
  • Xtc supports both of these trees
  • What is being asked of you?
  • How do we implement these programming phases?
  • Generalizing and details will be left to you; mapping and other stuff will be covered in class
  • May have to find right balance between safety and flexibility
  • Additional requirements after midterm. Class per phase is PATH OF LEAST RESISTANCE.
• Notes on xtc
• xtc will not tell you if you have malfunctioning Java code (use javac to check whether your test inputs compile)
• xtc does not have pretty printing in C++
• xtc does not support multithreading
• xtc supports class per phase and class per data kind
• Next class will explain more about xtc.