k1w1dev
ef42e169b9
* Remove unused member which was also causing a false positive sonar issue. Fixes sonar issue https://sonarcloud.io/project/issues?open=AY3gHwu5DIZTZkppqVEG&id=iluwatar_java-design-patterns * Fixes sonar issue https://sonarcloud.io/project/issues?open=AXK0OzDA-CiGJS70dLki&id=iluwatar_java-design-patterns related to "Refactor the code of the lambda to not have multiple invocations throwing the same checked exception." Also, updated the code to use Instant and Duration to deal with time instead of int. Added the awaitility library to perform assertions in test which is more reliable than using Thread.sleep directly to wait for events to happen. * checkstyle fix * Add sneaky throws to fix sonar lint issue. This is fine as the newFile method is not being tested but instead the new SimpleFileWriter(...) is. * The first booking needs to happen outside the assertions. Fixed other warnings * Use records to pass around related objects instead of using a large number of individual params, which sonar did not like. * Checkstyle fixes * checkstyle fixes * Remove complexity to keep sonar happy. * Split into different methods to reduce complexity. Could be broken down even further but currently Sonar is happy. * Move files to correct package * Add valid assertions to tests * rename constants to avoid confusion * Sonar warning related to cognitive complexity can be suppressed as the methods are quite generic and not functional enough to be separated out. * Use constants to keep Sonar happy * Use correct constant naming conventions * Use correct constant naming conventions * Use lombok to define noargsconstructor * Use a single method to do the logging * Remove unused constructor and redundant method * Use a reusable method for logging
title, category, language, tag
| title | category | language | tag | |
|---|---|---|---|---|
| Transaction Script | Behavioral | en |
|
Intent
Transaction Script organizes business logic by procedures where each procedure handles a single request from the presentation.
Explanation
Real world example
You need to create a hotel room booking system. Since the requirements are quite simple we intend to use the Transaction Script pattern here.
In plain words
Transaction Script organizes business logic into transactions that the system needs to carry out.
Programmatic example
The Hotel class takes care of booking and cancelling room reservations.
@Slf4j
public class Hotel {
private final HotelDaoImpl hotelDao;
public Hotel(HotelDaoImpl hotelDao) {
this.hotelDao = hotelDao;
}
public void bookRoom(int roomNumber) throws Exception {
Optional<Room> room = hotelDao.getById(roomNumber);
if (room.isEmpty()) {
throw new Exception("Room number: " + roomNumber + " does not exist");
} else {
if (room.get().isBooked()) {
throw new Exception("Room already booked!");
} else {
Room updateRoomBooking = room.get();
updateRoomBooking.setBooked(true);
hotelDao.update(updateRoomBooking);
}
}
}
public void cancelRoomBooking(int roomNumber) throws Exception {
Optional<Room> room = hotelDao.getById(roomNumber);
if (room.isEmpty()) {
throw new Exception("Room number: " + roomNumber + " does not exist");
} else {
if (room.get().isBooked()) {
Room updateRoomBooking = room.get();
updateRoomBooking.setBooked(false);
int refundAmount = updateRoomBooking.getPrice();
hotelDao.update(updateRoomBooking);
LOGGER.info("Booking cancelled for room number: " + roomNumber);
LOGGER.info(refundAmount + " is refunded");
} else {
throw new Exception("No booking for the room exists");
}
}
}
}
The Hotel class has two methods, one for booking and cancelling a room respectively. Each one of
them handles a single transaction in the system, making Hotel implement the Transaction Script
pattern.
The bookRoom method consolidates all the needed steps like checking if the room is already booked
or not, if not booked then books the room and updates the database by using the DAO.
The cancelRoom method consolidates steps like checking if the room is booked or not,
if booked then calculates the refund amount and updates the database using the DAO.
Class diagram
Applicability
Use the Transaction Script pattern when the application has only a small amount of logic and that logic won't be extended in the future.
Consequences
- As the business logic gets more complicated, it gets progressively harder to keep the transaction script in a well-designed state.
- Code duplication between transaction scripts can occur.
- Normally not easy to refactor transactions script to other domain logic patterns.
Related patterns
- Domain Model
- Table Module
- Service Layer