One of the topics for 3081 that I feel I'm capable of is designing a useful class hierarchy even though I only first needed one when I had an internship this past summer. The project I worked on was extensive, and required me to find, parse, and store information from XML files into a database on a backend application, then display that information on a website in a frontend application. To keep the project manageable, I had to create classes that were related to each other in a meaningful way and were used for a specific purpose. For example, on the web side of the project, I used objects from an API I was using (Wicket for those of you interested) to create abstract classes geared towards my application, then created subclasses of those. This not only allowed me to create additional methods and fields for objects that could be commonly inherited, but also enabled me to better tailor an object to a specific task without rewriting a bunch of code from similar objects. For example, I created an abstract ProjectWebPage class that extended the framework's WebPage class that all web pages for the application would subclass. The abstract class contained methods that would allow for greater and common functionality among web pages, such as getting access to a database. I feel that having used the core OOP tool of inheritance is one such way of showing my ability to create a useful class hierarchy.
One topic I look forward to is writing good tests. As it stands, I use very simple methods of testing code such as outputting the state of variables or the return of a function within a main method or the like. However, constantly adding and removing lines for outputting variables can be time consuming when working with many of them or when working across several different pieces of code, such as different classes. Furthermore, the way I go about writing tests can be very time consuming because I will often have to change a line of code to call a method with a different value and repeatedly do that for the range of appropriate values. I hope to learn from this topic how to write more thorough tests and possibly how to automate them.
Another topic of the course I will appreciate going over will be writing effective comments, getting into the habit of writing them DURING coding, and how to efficiently maintain them. Yes, the topic itself could very possibly be a bore, but the real-world advantages to them are significant. As it stands, I try my best to actively comment sections of code after writing them. This was not the case only several months ago. During my internship, I would avoid doing any proper documentation because, to be honest, they can feel like a waste of time, especially when you are used to small, basic projects that you and you alone work on. But after a couple months of very minimal documentation (having inserted comments mainly for my benefit of understanding why I had to use an API a certain way and what it accomplished), I looked at my 70+ Java classes and thought that whoever inherits this tool after I leave will be in world of pain without documentation. Then I had troubles trying decide what needed commenting and what didn't and how to best describe the algorithm used without creating a novel. More pain came about when requirements changed after I did the massive documentation, which affected algorithms and classes used and, in turn, their respective comments. It is because of this painful experience that the topic of effective comments appeals to me, and having the ability to clearly communicate an algorithm through a comment to someone when you can't directly is a very important skill for any computer scientist.