Continued making substantial changes to both model and view so that they would fit Julian's framework, including trying to use reflection to dynamically instantiate multiple 'similar' classes. I've noticed that Julian prefers using hard-coded arrays or collections (like maps) of classes so that for a new class, you would simply add it to the collection, and this has been an effective method so far. However, I'm hoping that while reflection is a little trickier to sort out at first and does require some 'hard-coding' in its own right, it'll mean less future investment unless major changes are made such that the reflection in place no longer works. While redoing parts of the view, it was definitely somewhat frustrating to realize that my code wasn't as extensible as I thought or hoped it was, but I think at the same time, this served as a good learning experience and helped me better understand what to do and what to not do in the future.
previous day | next day | return to calendar
Fixed the errors that I've been having with reflection and dynamically loading classes, then did some testing to be absolutely sure it works now (verdict: so far, so good...). Moved on to refactoring and implementing the set operations so that the classes would follow a better hierarchy, which involved considering a tradeoff between having static calls and an abstract superclass in the hierarchy, since static and abstract modifiers aren't simultaneously allowed, of course, and overriding a void method just doesn't feel like good practice. Personally, I thought being able to just do Union.evaluate(set1, set2) made more sense in context than instantiating a new Union object with the sets as constructor parameters then invoking the evaluate method, but decided that having the hierarchy would be easiest in terms of permitting reflection, aka hopefully facilitating extensibility for adding new operations. Thought about just having one SetOperations class with tons of static methods, one per operation, but I also wanted to be able to have properties like names and descriptions for each operation, and creating a huge static map in that one class also seemed like a worse idea. Anyway, that's up and running... we'll see how well it works out, but hopefully it'll either work well as is or only require minor changes next time around.
previous day | next day | return to calendar
Wednesday, July 4: INDEPENDENCE DAY
previous day | next day | return to calendar
Continued work on the GUI; the list of active sets now updates immediately when a new existing set is selected from the drop-down menu, using a basic pseudo-Observer implementation. I found a better way for the SetsManager to contain a reference to the entire View (which was mainly necessarily for updating the active sets list) and worked on various view components, from experimentation with layout to action listeners. While working on the custom set editor interface, I realized that the model I have in place might need to be revised, particularly with drawing a clearer distinction between finite and infinite sets and being able to distinguish that interactively, somehow...
previous day | next day | return to calendar
Began a significant overhaul or redesign of the sets hierarchy. My initial assumption was that once I had a basic prototype working for just sets of numbers, it should be fairly easy to adapt it to sets with a broader range of elements. However, even seemingly simple concepts like a set inside a set, like {1, {2}} require that a set be able to hold more than just numbers. It's probably better that I start tackling this rather than later, and hopefully have more reusable components for languages and sets of languages later on. Took closer looks at and resolved various GUI and Swing issues with the View components, and am working on modifying listeners and adding actions and events to better parallel the framework that Julian has put in place. Tracing a call hierarchy for one object can be surprisingly tricky, but I feel I'm definitely improving with more practice (which I'm getting plenty of!).