Demo: building a generic in-memory repository

Written Explanation

Step 1: the shape

A repository needs two types that vary. T is the type of the item stored (Contact, Event), and ID is the type of its key (Integer, String). Those are the two parameters. The storage is a Map<ID, T>, the structure you chose in the collections module for lookup by key.

import java.util.ArrayList;
import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;

public class InMemoryRepository<T, ID> {
    private final Map<ID, T> store = new LinkedHashMap<>();

LinkedHashMap is a Map that remembers insertion order, which makes the demo output predictable. A plain HashMap works equally well; its order is not guaranteed.

Step 2: the four operations

    public void save(ID id, T item) {
        store.put(id, item);
    }

    public T findById(ID id) {
        return store.get(id);
    }

    public List<T> findAll() {
        return new ArrayList<>(store.values());
    }

    public boolean delete(ID id) {
        return store.remove(id) != null;
    }
}

Notice what is missing: casts. store.get(id) already returns T, and findAll returns List<T>. The type parameters flow from the declaration at the top through every method.

Two design choices worth naming:

• findById returns null when the id is unknown. That is simple but easy to forget to check. Later in the course you will meet a safer return type for "maybe nothing"; for now, always test for null.
• findAll returns a copy (new ArrayList<>(store.values())). A caller who changes the returned list cannot damage the repository's internal map. This is the encapsulation idea from the object-oriented modules.

Step 3: two item types

public record Contact(String name, String email) { }
public record Event(String title, int attendees) { }

Now use the one repository class for both:

InMemoryRepository<Contact, Integer> contacts = new InMemoryRepository<>();
contacts.save(1, new Contact("Ada", "ada@example.com"));
contacts.save(2, new Contact("Grace", "grace@example.com"));

InMemoryRepository<Event, String> events = new InMemoryRepository<>();
events.save("demo-day", new Event("Demo Day", 40));

Contact c = contacts.findById(2);          // no cast
System.out.println(c.name());
System.out.println(contacts.findAll());
System.out.println(events.findById("demo-day"));
System.out.println(contacts.findById(99));
System.out.println(contacts.delete(1) + " " + contacts.delete(1));
System.out.println(contacts.findAll().size());

Output:

Grace
[Contact[name=Ada, email=ada@example.com], Contact[name=Grace, email=grace@example.com]]
Event[title=Demo Day, attendees=40]
null
true false
1

The second delete(1) returns false, because the contact was already removed. findById(99) returns null.

Step 4: the compiler guards both types

Now try to mix them up:

contacts.save(1, new Event("Demo Day", 40));
contacts.save("one", new Contact("Ada", "a@x.com"));

Bad.java:4: error: incompatible types: Event cannot be converted to Contact
        contacts.save(1, new Event("Demo Day", 40));
Bad.java:5: error: incompatible types: String cannot be converted to Integer
        contacts.save("one", new Contact("Ada", "a@x.com"));
2 errors

This is the acceptance test for the lab: one line that fails to compile when the wrong type is saved. Both the wrong item and the wrong id are caught at compile time. With a pre-generics repository holding Object, both lines would compile.

Step 5: the planned mistakes

Mistake A: new T(). Suppose you want a repository method that creates an empty item:

T create() { return new T(); }

error: unexpected type
  required: class
  found:    type parameter T

The type is not known when the code runs, so Java cannot build one. Fix it by having the caller pass the item in, which is exactly what save(ID id, T item) does.

Mistake B: the raw type. Leave the type arguments off:

InMemoryRepository raw = new InMemoryRepository();
raw.save(1, "anything");
Contact c = (Contact) raw.findById(1);

It compiles. The compiler prints only a note about unchecked operations; with the option -Xlint:unchecked, it prints warnings such as unchecked call to save(ID,T) as a member of the raw type InMemoryRepository. Running it gives:

Exception in thread "main" java.lang.ClassCastException: class java.lang.String cannot be cast to class Contact ...
    at Raw.main(Raw.java:5)

You are back in lesson 1: a String stored where a Contact was expected, found only at runtime. Fix: always write the type arguments, InMemoryRepository<Contact, Integer>.

Step 6: a bound to remove the repeated id

Passing the id separately lets a caller save a Contact under the wrong id. A common refinement is for the item to know its own id, through a small interface, and for the repository to require it with a bound:

public interface HasId<ID> {
    ID getId();
}

public class Repo<T extends HasId<ID>, ID> {
    private final Map<ID, T> store = new LinkedHashMap<>();

    public void save(T item) { store.put(item.getId(), item); }
    // findById, findAll, delete as before
}

Now save takes one argument. The bound T extends HasId<ID> is what makes item.getId() legal, the same mechanism as compareTo in lesson 4. A Book implements HasId<String> works as Repo<Book, String>. Using String as T is rejected: type argument String is not within bounds of type-variable T.