Further Project Suggestions - COM1204 and COM1370 - Summer 2003

Professor Futrelle, CCIS, Northeastern University

Version of July 15th

Note that this is a new and additional document, beyond the first one posted on July 9th. The comments are gleaned from the grading comments for Project #1 for COM1204, but are applicable to both courses. Be sure to re-read the first set of suggestions so you'll be keeping them all in mind.

• Spend a good deal of time up front designing your tests. Write the tests first, even before you have your other components full implemented. You'll find that this helps give you a clear idea of what your goals are and how to proceed.


• When you do run tests, even the simplest, they'll give some output. Include the output in your reports.


• In the COM1204 systems, some people feel that their project can be significant if it has many, many "things" in it. For example, building an aquarium model and including 45 different types of fish, each with their own distinct Java variable name. First, you should develop your system with a very small set of items, for example, six types of fish. Second, you should handle any large collection or any collection that can potentially get large, with some type of Collection class, such as a Vector or ArrayList or Hashtable. Each object stored in the collection can have its distinguishing information such as a String field describing its species or other name, "Boesemani Rainbow Fish", "Neon Blue Dwarf Rainbow Fish", "Piranha" or my favorite, "Mount Everest Skydiving Fish". Having distinct variable names for each item makes it essentially impossible to iterate over the various items. Any time you start with large collections it can make it hard to restructure your code, because you may have to rip out a lot and re-enter it in a very different form. You might hesitate to redesign your system in such a case, even though you really should.


• Design and Test first, then Design Patterns: If you focus on trying to force your design to use Patterns up front, you may find yourself frustrated. First try to think about what your system will do and what a test of it would be and produce. Then design a system that would meet the tests. Then think about the implementation. Only after that should you think about Patterns. You might find that once your design is thought through that there are some aspects of it that could use or even benefit from Patterns. That's when to use them.


• When you have output from your program you can cut or paste it into a file. In unix you can also just redirect it to a file. So given the code

  class HelloWorldApp {
      public static void main(String[] args) {
          System.out.println("Hello World!"); //Display the string.
      }
  

  You can execute the line: java HelloWorldApp > helloOut.text
  and it will write "Hello World!" to the file.


• Many of the projects are just series of method calls. Not much attention is paid to object-based structuring, the use of interfaces, enhancing objects through Decorations, building higher level operations via Facades, or many of the other useful Design Patterns. That is, your design and code is a bit too pedestrian. Not everyone has this problem, of course.


• Instead of using print statements, consider toString().


• Please try to go beyond the Design Patterns that I have created examples for. You don't have to understand them thoroughly, just enough to design things in the same spirit.


• It's all right to make big plans, but you should have a series of much smaller explicit plans as to how to proceed at each stage. Just setting a huge goal and then working toward it is not the best strategy. Specific intermediate goals can help.


• Remember to create a single file with all your sources in it. Else your project is "atomized" into a set of things, each of which has to be accessed separately (by Prof. Futrelle).


• A version number such as "0.2" should not be written ".2" -- the latter might be mistaken for "2".


• Scenarios, or Use Cases as they are called in design, are useful as are designing tests. All classes have methods, so things happen, even if they're rather abstract things that have nothing to do with the passage of time. For example, if you have a system that builds a description of a complex structure such as a finished house, there's no time element, but there can be complexity in the building and querying of the description, the relationships among them, etc. E.g., a house can have paint or a roof, Decorator Pattern. Getting an inventory might involve the Facade Pattern and Iterator; the static structure of the house might need Composite.


• Other important Patterns that should be useful in the types of projects you are working on include: Adapter, Chain of Responsibility, Command, Template and certainly, State. State is particularly useful as an alternative to having lots of fields that have various names and values, but are otherwise uncoordinated. For example, when something starts up, you can hand it a Starting State. If you want to pass a description, you can pass it as a State.


• Separate changes of state and the like from printing. When something is done, change the state of the system. Printing can then be done later and describe what's been done. Or you can save the state at various times or stages and print out various stages whenever you like. Printing just makes things visible, it's not an end in itself.


• Randomness can make things interesting. See Math.random() which returns a double value with a positive sign, greater than or equal to 0.0 and less than 1.0 . Returned values are chosen pseudorandomly with (approximately) uniform distribution from that range. You can multiply it by a constant and then convert to an integer it you need, e.g., 0 through 3 or some such. Remember, the chances of the result being 0.0 or 1.0 are essentially nil, so think about how you'll convert to an int.