Assignment 3: Design Patterns

Working on the Assignment

More Design Patterns

⚠️  Use the resources available to you: ask questions on the forum 🔒, go to office hours, and discuss the assignment with your colleagues.

In lecture we explored a few design patterns as a way to learn how to reason about them with a critical mind: when to use them, when to avoid them, when a pattern is employed in a way that is slightly different from what you find in the textbooks, and so forth.

But there are many more design patterns than those we explored. For this assignment you need to show that you can learn on your own and think critically about other design patterns you may not have seen before.

Fluent Interface & Decorator

Play a bit of Find the Design Pattern by yourself: see Fluent Interface & Decorator on the lecture notes.

Adapter

25 points

Suppose that we want TODOOSE to sync with other providers of TODO applications, for example, Apple Reminders and Google Tasks. Suppose that these providers have libraries to interact with their applications, but these libraries don’t provide exactly the same interface, and neither interface matches TODOOSE’s:

interface TODOOSE {
    public List<Item> getItems();

    public void delete(Item item);

    // ...
}

interface AppleRemindersLibrary {
    public List<Item> getAllItems();

    public void deleteAnItem(Item item);

    // ...
}

interface GoogleTasksLibrary {
    public List<Item> listItems();

    public void deleteTheItem(Item item);

    // ...
}

We could introduce a bunch of if/then/elses in the code base to handle the different interfaces, but that would get hard to understand and maintain. It’s a better idea to use the Adapter pattern.

1. Draw a class diagram showing how to use the Adapter pattern to amend the differences between the interfaces so that TODOOSE doesn’t need if/then/elses to handle different providers.

2. Suppose that both TODOOSE and Google Tasks provide a feature that Apple Reminders doesn’t, for example, subtasks. How would you handle that?

Facade

25 points

The Javalin class provides a lot of functionality, from start()ing the server, to adding handlers for exception()s and so forth. But the Javalin class doesn’t implement all those things directly, it delegates the implementation of most of its functionality to other classes like JavalinServer, JavalinServlet, and so forth. In other words, Javalin is a facade for these other classes.

1. Dive into the implementation of the Javalin class (hint: use IntelliJ to navigate by right-clicking a use of the Javalin class and using the menu option Go To > Implementation(s)). See how an instance of JavalinServer is used in the implementation of start(int port) and how an instance of JavalinServlet is used in the implementation of exception(@NotNull Class<T> exceptionClass, @NotNull ExceptionHandler<? super T> exceptionHandler).

2. Draw a class diagram showing the relationship between Javalin and JavalinServer/JavalinServlet and how it constitutes a facade.

Technology

50 points

⚠️  In this part of the assignment you’re going to work on the TODOOSE code base. Don’t Fork that repository on GitHub! Otherwise there’s a high probability that you’ll end up pushing your answers for the whole world to see, which violates the Academic Integrity policy. Work on the version of the code base you cloned by following the steps from Assignment 0.

In lecture we talked about how the client side (that is, the JavaScript side) of TODOOSE doesn’t follow the MVC pattern, but it could. Carry out this change in the TODOOSE code base.

Implement a class called ItemModel, and a class called ItemsController. The views are the React components, and you can keep them where they are on the code base (except for the parts of them that you extracted into the model and the controller).

Test the application in the browser to ensure you didn’t break anything in the process.

Submission

⚠️  Your assignment is submitted only when you submit the form below.

If you run into problems, send an email to assignment-submission@jhu-oose.com. Include the information about the submission: your GitHub Identifier and the Commit Identifier. Don’t include any information about the feedback—it’s anonymous.