Some class participants thrived in implementing the project specifications. I believe each of you knows in your heart the effort you put into the project. I salute you for your effort more than any grade I might assign you or your team members. My hope is that the exam will align well with your effort. But, we all have good days and bad days and the learning curve to understanding object-oriented concepts is an unfair one, filled with frustrating plateaus. Your exam grade may not agree with your deserved grade if I could have studied with you and read your mind.
So, forget about the exam and just read the following extensive review of Project 1 for your own learning. Then you can go back and cram key points into your head. My hope is you will retain the important concepts for a long time. My responsibility is to communicate those concepts well. So, with that in mind, I try my best here:
You, the programmer or system analyst, have to decide which data, actions, and interface each class should contain. If you make suboptimal decisions on these three points, your code will be less successful when participating in a wider range of systems. You can make lots of suboptimal decisions when designing an application for a single purpose. But, in nature, suboptimal designs don't survive without a lot of arbitrary good luck. It might sound zen-like, but sometimes you have to think about a class by envisioning yourself as that class. Ask yourself:
Hopefully, as you looked at the different .java files you were given for Project 1, you looked at how the different classes communicated with each other (we reviewed this in class). Messaging is the key to collaborative software which is why the time is ripe for valuable software to emerge. The Web provides a communications medium the world has never known before. Try to envision the Web as an object-oriented messaging highway instead of a Web page delivery vehicle. In reality it is both of course. But, we (humanity) have only really exploited Web page delivery so far. Object to object messaging is both harder to understand and harder to implement but we finally have a communications medium capable of providing this important capability.
You have used the Web for object to object messaging! That is an important insight to gain from Project 1. You messaged from one object alive in one Web browser to another object alive in another browser. A very basic thing to do with Java (almost built-in), but a huge potential as we (humanity) figure out all that means. I don't profess to have a full vision of where we (humanity) are going with this basic ability, but I do feel like programmers should be excited about the possibilities.
Project 1 control is very hierarchical. Hierarchy is easier to implement than an equal partner matrix. So, it is a good place to start. The Project1 class is at the top of the hierarchy. Nothing happens in your application without Project1 making it happen. Since Web browsers require a top level class to start a Java applet doing something useful, we are already pushed toward this type of implementation.
Now, think of the Project1 class as a military general. Project1 wants direct control of three specialists: a communications expert (the Dispatcher class), a text processing expert (the ChatPanel class), and a diagramming expert (the Whiteboard2 class). Project1 requires that all subordinate officers communicate with each other through him/her. And so we see a Java design that enforces this messaging requirement. Once you understand how that is enforced by the Java keywords (spelled out in each .java file documentation I have produced for you), you can then investigate how the Dispatcher, ChatPanel, and Whiteboard2 commuicate with their subordinates.
The Dispatcher communicates with the rest of the vnet package, the ChatPanel communicates with the CTextArea, UserList and UserListObserver, and the Whiteboard2 communicates with the SimpleWhiteboard2 (in a unique way by using the Java keyword extends). The Chatter is unique in that it just stores information like a database record does within a database. The Chatter is more of an inanimate object if we have to fit it into the military hierarchy analogy. Think of the Chatter as a military document perhaps, with no real intelligence but there to facilitate storage in a Hashtable.
So, let's start at the top. Open up the annotated Project1 class code and read it through from top to bottom. Don't be overwhelmed by all I write in the Project1 class documentation. Many of the ideas are the same for all the class files. I won't be repeating the ideas over and over. So, the documentation will decrease as you move forward from one class' documentation to the next. After you finish the Project1 class documentation, use your Web browser's Back button to come back here and continue. My comments all begin with /* ##### and end with a ##### *\ so be sure to search on ##### to make sure you've read everything.
OK, now that you have seen the top class in action (and have learned about inheritance, interfaces, convenience methods, synchronization, message distribution, and Web browser integration), move on to the ChatPanel class.
OK, now that you've seen the top chat class in action (and have learned about constructors and event handlers), move on to the Dispatcher class...
OK, now that you've seen the interfacing vnet class in action (and have learned static attributes and package interfaces), move on to the Whiteboard2 class...
OK, now that you've learned about inner classes, adapters and listeners, move on to the ClientThread class...
Now that you understand how powerful and reusable the ClientThread class is, realize that the rest of the vnet package is there solely to set up and control what VField objects are and how they are bundled to work on VField-aware streams. The fact that there are really 15 more classes in the vnet package (that I didn't even bother giving to you) should alert you to the potential level of granularity a reusable, object-oriented code base can attain. There can be hundreds of classes in a project of which only 5-10 are doing any real work. The rest are providing structure and control to eliminate misunderstanding and error (making all data types extend VField gives the vnet designers control but also keeps vnet users from making mistakes -- the part I am most thankful for as I implemented it in three projects really quickly). You can go through the VIP, VField, VFieldInputStream, VFieldOutputStream, VMFString, and VSFString classes at your convenience after the exam. Just be SURE to remember how the VFieldInputStream gets started for use: InputStream is=socket.getInputStream(); (gets the input stream (a raw, bits based stream) from the socket) DataInputStream dis = new DataInputStream(is); (lets the input stream gain the intelligence of data types inherent to the Java langauge) VFieldInputStream vfis = new VFieldInputStream(dis); (lets us organize Java data types into the advanced datatypes that are most relevant to the processing we need to accomplish) The cool part is how the VFieldInputStream won't accept anything that isn't inherited from VField. Hence, the need to create all those classes that extend VField. Note that running a VFieldOutputStream is identical if you just replace the world Input with the word Output above.
OK, you are almost done reviewing for the exam. Finish up with both the SimpleWhiteboard2 and CTextArea classes and then use the Chatter, UserList and UserListObserver to confirm what you have learned already.
SimpleWhiteboard2 notes
CTextArea notes
Review the Chatter class (using any text editor like Notepad or Wordpad) looking specifically at safety issues. Shouldn't all three of the Chatter class attributes be private? The answer is a definitive Yes for protection purposes. But, you will find programmers being lazy about that when they don't perceive a high risk of system damage by the rest of system processing (I mean, the Chatter attributes aren't shared by different processes and so they are not very likely to be inadvertently damaged). But, they should be private none the less. Laziness should not be accepted during professional code writing (but it is fine for our class as long as you understand the principles).
Review the UserList and UserListObserver classes to realize how that Observer stuff works (using your Dispatcher and ClientThreadObserver as examples). See how clean the UserList adds and removes are and be sure to see what is being added and removed (what kind of objects?). See how the different parts of the Java packages provide a natural design to both classes.