Each lab will consist of a small problem and details of  how to proceed. You need to submit you weekly homework to the TA for grading.  See the syllabus for information on grading.  Turning in homework assignments is required.  Homework will be graded on an 8-point basis.  Submit your assignments in a folder called HW1 (or similar) to the subversion repository according to the directions on the syllabus page. Place all of your HW1 work into one folder. You will only be graded on your material within a reasonably labeled folder. Also, please include a README text file that contains the programming language you used. If you want to give the TAs/graders instructions on how to compile, run, or even understand your code, you can place that within the README as well. We will read the README thoroughly, so take advantage of it. Also, don't forget to comment your code!

You will also need to submit the 3 lab deliverables  which comprise part of your grade. For the deliverables, you will typically need to extend or build around the corresponding lab assignment(s).  A working lab assignment ensures an easier deliverable.

Homework 1 Due: 5:00 pm, April 23, 2013

Problem 1 (Singleton Pattern): Consider a rudimentary college registration system. A student will need to approach the registrar when he/she needs to register for a course. Since seating is limited in courses and the registrar is in charge of checking if seats on a course are still available, only one registrar should be allowed to exist in the system (to avoid write errors and make our life simpler).

What you need to implement:
You need to create a class called 'Registrar' in such a way that only one instance of the class can be created. If a second instance of the class is asked to be instantiated, your program should print an error message like " Sorry, I already exist" and return the existing instance. Test your code by trying to instantiate the Registrar class more than once.
 

Problem 2 (Template Method Pattern):  A new bank in your neighborhood offers two kinds of accounts: Savings accounts and Checking accounts.  The savings account offers an annual interest rate of y (> 0 defined by you) where as there is no interest offered in the checking account.

What you need to implement:
Create an abstract class called  'Account'.  This class will have a template method called get_account_summary( ). This method in turn calls 3 other methods:  calc_interest( ), update_balance( ) and print_summary( ). (note that calc_interest( ) does nothing in the base class and is overridden by subclasses).

Create two more classes SavingsAccount and CheckingAccount, that are derived from Account. Both the derived classes implement their own calc_interest( ) method (which returns any interest that might have accrued) . The methods update_balance( ) and print_summary( ) are generic and are thus to be implemented in the base class 'Account'. Implement any other variables, methods that you feel are needed for these classes to function e.g. you may need a private variable called 'balance'.

Test your implementation by creating the two kinds of accounts with an initial balance and asking both of them for account summaries. (to simplify the problem you can assume that interest is compounded on the first of January every year). You can also assume that the user inputs the current date, or you can use the system date. Consider the following:

• There is NOT one correct way of doing things underneath the hood, so don't assume there is one programmatic solution that you must have. Heck, you can pick from many programming languages, so we're definitely not looking for a specific implementation! But, what IS required (in addition to the implementation of the functions described above) is that:
  • the balance should always be correct immediately after update_balance is called, considering that interest is compounded annually on January 1.
  • calc_interest should be able to AT LEAST compute the interest that has accrued since the last time update_balance was called...this is NECESSARY to keep the balance properly updated. A more "generic" functionality is recommended (perhaps by passing in arguments like "the balance upon which to calculate interest" and "the number of years for which to calculate that compounded interest" to calc_interest).
• You can craft the above functions as you please. This means that you can choose:
  • the number of arguments,
  • the types of those arguments,
  • and possible default values for those arguments
  as you wish. (Of course, you can also have whatever data members you please within your classes.) But, make sure that your choices reflfect good object-oriented style and are user-friendly! Testing your implementation as requested above should help you determine if your style and user-friendliness are good.
• Do not forget to include the code you used to test your implemenation. This will be indispensible for us: it will show us how to you intended the classes you wrote to be used. It's also required!
• Document any design decisions you make by commenting your code. Explain why you made the decisions you did. This isn't 100% necessary, but it's highly recommended. Make it apparent that the decisions you made were good ones.