Imagine you are designing a system for a bank to send monthly statements to customers. Some customers prefer to receive physical letters in the post, whereas others prefer to receive emails.

• Create a StatementSender interface with a method #sendStatement that accepts a String parameter statementContent
• What should the return type of this method be?
• What is the visibility of interface methods? Why?
• Make sure to write Javadoc on both the class and method
• Why is this Javadoc important? Think about who we are aiming this javadoc at (i.e. who will read it / benefit from it)?
• Create implementations of LetterStatementSender and EmailStatementSender
• The implementations of #sendStatement should simply print to the console a success method to say that the statement has been sent via the given delivery method (in reality these methods would likely call out to some additional processing or third party email/postal service, but we don’t need to do that here)
• Now create a class StatementDeliveryService with a method #deliverStatement(String statementContent, StatementSender statementSender)
• This method should send the content using the sender
• Now create a main method that creates a new StatementDeliveryService and sends a statement via both letter and email

Reflections

Think about the following questions, make notes and be prepared to talk through your thoughts in the workshop.

• Look at the example you just created. Why was it useful to use an interface? How would it look if we had only used classes - can you think of any problems that might cause?
• How will the use of interfaces make the code more maintainable in future? What if we decide we also want the option to send statements via text message?
• How does using an interface enforce the contract that it sets out? Again think about writing a new text message implementation.
• Similarly, what if we decide in future that physical letters are no longer supported; which code do we need to update?
• Think about how you would test StatementDeliveryService. In practice you wouldn’t want to send an actual email or a letter every time you ran the test, so how could the StatementSender interface help here? (NB our expectation here is for a testing-implementation as they won’t have covered mocking yet

• Create a Statement interface and add a new #sendStatement method to StatementSender that accepts the new interface
• What is it called when you have two versions of the same method?
• What methods might Statement have? Think about the type of information you’d expect to see on a bank statement.
• Create two implementations of Statement:
  • AllTransactionsMonthlyStatement - As the name suggests, includes all transactions, both ingoing and outgoing for the current month
  • OutgoingTransactionsMonthlyStatement - Only includes the outgoing transactions for the current month
• How should the implementation behaviour differ?
• Create a new class StatementService that:
  • Has methods to create and send both types of statements
  • Uses StatementDeliveryService to send the statements
• Note we’ll need a new method on StatementDeliveryService that accepts a Statement
• Refactor your main method to use StatementService
• You’re now starting to build up a hierarchy of classes and interfaces. Have a look back through the reflection questions about and apply them to your refactored system - are the answers the same? Are interfaces even more important now? Imagine we increased the complexity even further by adding more services and functionality - do interfaces become more or less important?

You are given three arrays containing data relating to students and their grades: firstNames, lastNames and grades. Each student is represented by the same index in each array, so firstNames[i] has the surname lastNames[i] and grade grades[i]. Create a class (with an appropriate name) that takes the three arrays as constructor parameters and has the following methods to collect the data into more sensible structures (note you will need to choose the appropriate return type!):

• getFirstNames(String[] firstNames, String[] lastNames, int[] grades)
• getDistinctFirstNames(String[] firstNames, String[] lastNames, int[] grades)
• getDistinctFirstNamesInAlphabeticalOrder(String[] firstNames, String[] lastNames, int[] grades) → Hint: no for loops needed; consider an appropriate collection implementation
• getLastNameToGrade(String[] firstNames, String[] lastNames, int[] grades) (Note you can assume there are no duplicate last names)

Create a main method that calls each method above and prints the output to the console. The data to use should be:

• firstNames = {Anuket, Eryn, Filip, Raquel, Eryn}
• lastNames = {Hassan, Doe, Pappas, Clarke, Jones}
• grades = {22, 45, 35, 22, 41}

Reflection

Suppose there are a set of twins in the class, so there are some duplicate lastNames. Can we still build a map of students to their grades?

• Create a Student class with fields firstName and lastName
• Implement the following method: Map<Student, Integer> getStudentToGrade
• What methods do you need to define on Student for this map to work safely?
• Update the data set to include the twins and print the result of getStudentToGrade to the console

• Now let’s ditch the arrays completely and work only with collections: in your main method, call each of the methods you’ve already created and assign the results to new variables. This will be our starting data.
• Suppose a new student joins the class. Modify each of the collections you’ve created to include the new student and their grade
• Now suppose a student leaves the class. Modify each of the collections to remove that student.
• Now suppose that one of the students was found to have cheated in their exam and their grade needs to be modified. Update the collections to set the grade of one of the students to 0.

Reflections

Think about the following questions, make notes and be prepared to talk through your thoughts in the workshop.

• Would it have been possible to use Arrays to model the same data?
• Would it have been easier, harder or the same? Why?
• What was your thought process when deciding which data structure was most appropriate for modelling particular data? What things did you consider?
• Suppose the initial data set was input incorrectly and the same student’s name and grade was input twice. How would your Map<Student, Grade> handle this? Why?
• What is the difference between variables: a) List firstNames, b) List<String> firstNames, c) ArrayList<String> firstNames ? Which is preferable? Bonus: how about List<?> firstNames ?

• Given the same data as above, without using for loops, find:
  • The highest and lowest grades
  • The first and last names of the student with the highest grade
  • Any firstNames that belong to more than one student

Create a service that safely reads text files

• Create a FileReaderService class with a method #readFile(String filename) that:
  • Attempts to read a file using BufferedReader
  • Returns the file contents as a String
  • Properly handles FileNotFoundException and IOException
  • Uses try/finally to ensure the file is closed
  • Safely handles the possibility of fileName being null
  • Create a custom checked exception called InvalidFileFormatException
  • Throw this if the file is empty
• From a main method, call the service with some dummy text files, including an empty file

• Refactor your above method to use try-with-resources instead of try/finally

Reflections

Think about the following questions, make notes and be prepared to talk through your thoughts in the workshop.

• Why are FileNotFoundException and IOException checked rather than unchecked exceptions? What advantages does this give developers and systems that use them?
• In this example we had control over which strings we passed to the method, so in theory we could make sure they wouldn’t ever be null. When writing production code do we have this same level of control?
• When is it beneficial to include null checks, and when isn’t it?
• How does try-with-resources relate to a try/finally block? Think about flexibility / clean code etc
• If an exception is thrown, does a finally block get executed before or after the catch block? How could you prove this?
• What about if the catch block throws an unchecked exception? Does the finally block still execute?

Should try/catch blocks be used as part of ‘standard’ processing? e.g. say I have a payment processing system that accepts cash or card, and I first attempt to process a card payment, before throwing an error and processing cash if no card details are found:

void processPayment(Payment payment) {
    try {
        cardProcessor.process(payment);
    } catch(NoCardDetailsFoundException e) {
        cashProcessor.process(payment);
    }
}

• Will this work correctly? If we know some payments will definitely be made by cash, is there a better way to handle this? Why?
• What are some potential problems with throwing errors like this? Think about: when we want to find out about errors / unnecessary processing etc
• Update the above pseudocode to remove the try/catch block and handle the card/cash options more gracefully. Feel free to invent some methods on Payment to help you!