In lab 1, we went over the general design of the word list and the body part list. We discussed the need for a state pattern so the objects can change behavior yet remain the same class. Then I let the students recreate the code from the UML diagrams.
Besides some questions that had to do with getting “back into Java programming”, there was an interesting question about encapsulation, whether the visible and invisible states should be implemented as anonymous inner classes. I recommended that EmptyWord and NEWord be nested classes of the concrete word factory, and that AWordState, the visible state and the invisible state be nested inside NEWord, but I hadn’t considered implementing the latter two as anonymous inner classes. When I did that on the projector, it turned out that the visible state was an anonymous inner class defined inside toggleState() of the anonymous inner class for the invisible state. That was interesting, but perhaps made things more complicated.
I didn’t talk much about the algorithms run on word list and body part, so I ended up being a bit worried that not everyone knew what to do. I decided to revisit the encapsulation issue and the algorithms.
As everyone was leaving, there was a question about static as it applies to nested/inner classes. It took a little bit of effort, but I think I was able to explain how static nested classes do not have a reference to the enclosing class’ this, while non-static inner classes do, although I could not come up with a really compelling reason why non-static inner classes cannot have static members, except that static would not convey any advantage, because it could not be called in a static context anyway, but that would not have prevented Sun from just ignoring the static modifier.
I also found out that I’ll have a TA this semester, and I’m already very grateful for that already.
