Comp 212 Project #2: Koch Curves

In this project we will write a program to generate a type of fractal curves called "Koch curves". This is a classic recursion exercise used in many CS courses around the world. We're going to make an OO version that is different from (better than, naturally!) any other implementation -- one that shows off the power and flexibility of proper abstraction using OO modeling and design patterns.

The first thing you should do is to read the general discussion of Koch curves.

The next thing you should do is to run the demo of the final product. Your final code should replicate all the functionality of the demo except the counting of the line segments.. (Did you try all the distinct combinations of button clicks and drop-list selections?).  There is a security loophole that allows one to download the Koch applet demo code.  You are not allowed to reverse engineer the applet code to do the Koch project.

Your final code should have minimally these features and capabilities:

  1. A mutable Koch curve object that is capable of "growing", which is to replace all line segments with collections of line segments. The Koch curve should appear to change shape when it grows.
  2. The specifics of replacing a line segment with a collection of line segments should be a variant process. That is, the pattern of line segments used to replace a single line segment should be encapsulated separately from the Koch curve object. Thus the pattern used to "grow" should be changeable between growth iterations.
  3. The number of Koch curves held by a non-base case Koch curve object must be limited only by memory constraints. Empty/unused placeholders are not allowed!
  4. An MVC design pattern must be utilized.
    1. No class in the view package can reference an object of any type defined in the model package.
    2. No class in the model package can reference an object of any type defined in the view package.
    3. Model-view communications should be designed for minimalism.
  5. Anonymous inner classes should be used whenever only a single instance of a type is required.
  6. The maximum number of line segments in the curve should be determined solely by the memory capabilities of the computer upon which the program is running. Empty/unused placeholders are not allowed!
  7. The counting of line segments is optional (it's easy to add--why not do it?).
  8. A snowflake factory must be able to use any type of Koch curve to generate its figure.
  9. No if statements or conditional statements of any sort are allowed! This implies that no for-loops or while-loops are allowed either.
  10. If you choose to use LRStruct and its IAlgo, you may not modify their code in any way.

See the Hints Page for supplied code, math and other help.


Milestone #1 (35% of the grade): see schedule page for due date

Submit the following.

  1. UML class diagrams and stub code for the Koch curve, the abstract factory that manufactures the Koch curve objects, and all other supporting classes (for example, LRStruct and its IAlgo, if you choose to use them). The code should compile.
  2. Each method in each of the classes must be fully documented in javadoc. For example, the Koch curve class must have a high level description how it grows and draws itself. Each method of the Koch curve must describe clearly its parameters and what it does. If you choose to use LRStruct and IAlgo, you do not have to document them. However, you do have to document their use.
  3. The usual README file.

Your design should be an OO design with appropriate OO design patterns. Explicitly spell out the design patterns you are using in your documentation. You will be graded on the quality of your OO design.


Milestone #2 (65% of the grade): see schedule page for due date

Submit the following.

  1. A complete program that possesses all the features and capabilities listed above.
  2. The UML class diagrams should be organized into three groups.
  3. The usual README file

You will be graded on OO design and functionality.