Wait, You Want Me to Delete All My Code? 
During Woowahan Tech Course Level 2, Mission 3, I encountered a requirement to modify existing code that used JdbcTemplate to utilize Spring Data JPA instead. And in the mission briefing, Coach Brown said this:
Unfortunately, youโll need to delete your existing JdbcTemplate code!
Would You Only Be Happy if You Take It All?
How Can I Change My Code the Least?
I faced a similar dilemma back in Level 1. At that time, there was indeed an issue with my code, but I wanted to fix it with minimal changes. I remember talking to Coach Gugu back then, and Gugu said this:
The easiest solution is to just overhaul it.
I understood that it would be wise to address issues at their root, as leaving them unresolved might cause bigger problems down the line. I was stubborn, didnโt heed Gugu's advice, spent a day trying to work around it, and ended up overhauling it anyway. I wasted both time and failed to reach my goal. Now, halfway through Level 2, I stand at a similar crossroads.
Humans may repeat their mistakes, but without taking chances, thereโs no growth. This time, Iโm determined to achieve substantial gains with minimal changes.
Canโt I Just Add extends JpaRepository<Domain, Long>?
Initially, I thought I could simply add extends JpaRepository<Reservation, Long> and be done.
package roomescape.repository;
// import ์๋ต
public interface ReservationRepository {
Reservation save(Reservation reservation);
List<Reservation> findAll();
List<Reservation> findByMemberAndThemeBetweenDates(long memberId, long themeId, LocalDate start, LocalDate end);
List<Reservation> findByMemberId(long memberId);
boolean existsByThemeAndDateAndTime(Theme theme, LocalDate date, ReservationTime reservationTime);
boolean existsByTime(ReservationTime reservationTime);
boolean existsByTheme(Theme theme);
void delete(long id);
}
Java
๋ณต์ฌ
์๋ ReservationRepository ์์ฃผ ๊ต๋ฌํ๊ฒ JPA QueryMethod ๊ท์น์ ์ด๊ธ๋๋ค.
If I simply add extends JpaRepository<Reservation, Long> to the interface, it would look like this:
package roomescape.repository;
// import ์๋ต, ๋ฌธ์ ์๋ ๋ฉ์๋ ์๋ต
public interface ReservationRepository extends JpaRepository<Reservation, Long>{
List<Reservation> findByMemberAndThemeBetweenDates(long memberId, long themeId, LocalDate start, LocalDate end);
void delete(long id);
}
Java
๋ณต์ฌ
์๋ ReservationRepository ์์ฃผ ๊ต๋ฌํ๊ฒ JPA QueryMethod ๊ท์น์ ์ด๊ธ๋๋ค.
These two methods violate QueryMethod conventions ambiguously. However, this can be easily resolved by using IntelliJโs refactoring tool. But the real problem lies elsewhere.
My Fake is Acting Up!
A ton of methods need to be added to the Collection-based implementation of the existing Repository!
In the previous mission, I created a Collection-based Fake object to ensure the Service layer worked independently of SQL in the Repository. However, if the existing interface extends JpaRepository, I end up needing to implement numerous methods.
The meticulously crafted tests from the previous mission would break entirely. Some might argue itโs expected for tests to break, but should tests really fail when functionality remains unchanged, with only the implementation method differing?
Ultimately, Itโs a Compatibility Issue with the Interface!
The reason for this issue is that the interface I defined differs from the one defined by Spring Data JPA.
In that case, what if thereโs something to transform between the interfaces?
In Level 1, I learned that changing inheritance relationships to composition allows wrapping methods to alter method signatures. I thought I could use this to resolve the interface mismatch.
Would Something Like This Work?
Letโs overlook the awkward naming; this is how my pair and I actually designed itโฆ
The two classes on the left are new ones created for Spring Data JPA. On the right are the original interface and its implementation. We decided to register the existing interfaceโs implementation as a Repository and inject the newly created Repository via the constructor.
The Result
Design that enables JPA usage while maintaining the original interface
When implementing this code, I named the interface extending JpaRepository as Dao to avoid naming conflicts with the existing Repository. I thought this was fitting since it performs a similar role.
At the end of the JPA integration, the changes show that the only modifications in production code are adding JPA annotations to the domain and removing the Jdbc implementation.
For test code, I only made slight changes to the names and internal fields of the existing Jdbc implementation tests.
The tests continue to work as expected
As expected, the step-by-step changes in the refactoring process didnโt cause any issues.
Every Rose Has Its Thorn: Downsides
There are, of course, trade-offs in this structure.
@Repository
public class JpaReservationRepository implements ReservationRepository {
private final JpaReservationDao jpaReservationDao;
public JpaReservationRepository(JpaReservationDao jpaReservationDao) {
this.jpaReservationDao = jpaReservationDao;
}
@Override
public Reservation save(Reservation reservation) {
return jpaReservationDao.save(reservation);
}
@Override
public List<Reservation> findAll() {
return jpaReservationDao.findAll();
}
@Override
public List<Reservation> findByMemberAndThemeBetweenDates(long memberId, long themeId, LocalDate start,
LocalDate end) {
return jpaReservationDao.findByReservationMember_IdAndTheme_IdAndDateBetween(memberId, themeId, start, end);
}
@Override
public boolean existsByThemeAndDateAndTime(Theme theme, LocalDate date, ReservationTime reservationTime) {
return jpaReservationDao.existsByThemeAndDateAndTime(theme, date, reservationTime);
}
@Override
public boolean existsByTime(ReservationTime reservationTime) {
return jpaReservationDao.existsByTime(reservationTime);
}
@Override
public boolean existsByTheme(Theme theme) {
return jpaReservationDao.existsByTheme(theme);
}
@Override
public void delete(long id) {
jpaReservationDao.deleteById(id);
}
}
Java
๋ณต์ฌ
This approach required adding repetitive code. Nonetheless, I chose to maintain this structure for a simple reason.
Creating a Fake for JpaRepository with all its methods would be a far more complex and maintenance-heavy task.
