<< 목차 >>
* 프로젝트 깃허브 레포지토리 주소
* 프로젝트 스크린 다이어그램
* 최종 클래스 다이어그램
* 기능 소개
* 문제와 해결
* 느낀 점
프로젝트 깃허브 레포지토리 주소
GitHub - JisooPyo/HI5_Project
Contribute to JisooPyo/HI5_Project development by creating an account on GitHub.
github.com
프로젝트 스크린 다이어그램
최종 클래스 다이어그램
기능 소개
BookProgram
예약프로그램. 거의 모든 클래스를 참조한다.
onProgram() -> 예약프로그램을 켠다 -> 번호 선택에 따라 다른 화면으로 전환
1. guestScreen():Guest -> bookingScreen(Guest) : 생성한 Guest 객체로 Booking 객체를 만들어 예약을 완료하는 화면
2. checkBookingManager() : 호텔 매니저가 호텔 전체 예약 현황을 확인할 수 있다.
3.checkBookingGuest() : 호텔을 예약한 고객이 자신의 예약 현황을 확인하고 취소할 수 있다.
Room
Room객체를 만든다.
Hotel
Room 객체를 Queue로 보관한다.
Booking
Booking 객체를 만들고, 예약과 관련된 메서드들이 있다.
makeBooking(Guest) : Booking -> Guest를 매개변수로 받아 Booking 객체를 만드는 메서드
showBookingToManager() : 호텔 전체 예약현황을 볼 수 있으며, 비밀번호가 필요하다.
showBooking Toguest() : 고객이 자신의 예약현황을 볼 수 있으며, 예약취소가 가능하다.
Guest
고객 객체를 만든다.
inputGuest() : Scanner로 변수들을 입력받아 Guest 객체를 만든다.
문제와 해결
1. 예약을 어떻게 진행할 것인가
Guest와 Room은 어떤 필드를 가져야 하는지 힌트가 있었기 때문에 클래스로 구현을 했으나, 예약에 대한 별다른 말은 없었기 때문에 예약을 어떻게 해야 할지 감이 잘 안 잡혔다. 계속 생각해보다가 예약 객체를 만들어 객체의 필드에 Guest와 Room을 넣고 예약 객체를 따로 저장해두면 나중에 꺼내서 쓰기도 편하고 좋을 거 같다고 판단해 Booking 클래스를 만들게 되었다. 그 전까지는 객체의 필드에 또 객체를 쓴다는 생각을 못해서 한참 머리를 굴렸던 거 같다.
2. Room 객체를 어떤 자료구조를 이용해서 저장할지 고민
List에 저장하면 삭제할 때 어려울 것 같다. remove(0)으로 지우면 되지만 비효율적인 것 같다! Queue가 괜찮을 것 같다. poll()로 제거도 쉽고 FIFO의 특징이 호텔 예약과도 잘 맞다고 생각해 Queue에 저장하기로 하였다.
3. Queue에서 poll()을 했는데 size()가 줄지를 않는다.
Room 객체를 이렇게 만들고,
public class Room {
String size;
int price;
public Room( String size, int price ) {
this.size = size;
this.price = price;
}
}
Hotel 객체에서 Room을 저장하고,
public class Hotel {
public Queue<Room> singleQueue(){
Room room1 = new Room( "single",100 );
Room room2 = new Room( "single",100 );
Queue<Room> singleQueue = new LinkedList<>();
singleQueue.add( room1 );
singleQueue.add( room2 );
return singleQueue;
}
}
Main 클래스에서 singleQueue()를 poll 해주면 사이즈가 1이 되어야 하는데 2가 되었다.
public class Main {
public static void main( String[] args ) {
Hotel hotel = new Hotel();
hotel.singleQueue().poll();
System.out.println( hotel.singleQueue().size() ); // 왜 2..?
}
}
hotel.singleQueue()를 다른 큐에 복사해서 진행하니까 해결되었다..!
4. 어떤 메서드를 써야 할까? 필요한 메서드를 구현해보자!
고객이 예약을 취소할 때, 취소한 방의 사이즈와 가격을 얻어와서 그 필드로 다시 Room 객체를 생성하고 채워넣는 식으로 하려고 했다. ( ex. "single"이면 singleQueue라는 자료구조에 Room 객체를 추가 )
"single"이라는 roomSize를 알고 있을 때, 1이라는 Key값을 도출하여 mapRoom의 Value인 Queue에 Room 객체를 추가하는 방법에 대해 고민했다. 어떤 메서드를 써야 할까?
mapRoom의 원소들은
Key : 1, Value : singleQueue[size가 single인 room1, room2, ...]
Key : 2, Value : doubleQueue[size가 double인 room1, room2, ...]
Key : 3, Value : twinQueue[size가 twin인 room1, room2, ...]
Key : 4, Value : suiteQueue[size가 suite인 room1, room2, ...]
이다. 생각을 이래저래 해보다가 "single"이라는 String 값이 들어오면 1, "double"이 들어오면 2를 리턴하는 메서드 getRoomNumber()를 따로 구현하여 해결하였다.
if else 조건문으로 메서드를 구성하였는데, 지금 생각해보면 Map<String roomSize, Integer roomNumber> 자료구조를 만들어서 Key값이 들어오면 Value값을 리턴하게끔 해도 괜찮았을 것 같다. (이렇게 수정 완!)
private Integer getRoomNumber( String size ) {
// size를 입력받아 size에 맞는 mapRoom의 key값을 알려주는 메서드.
Map< String, Integer > RoomNumber = new HashMap<>();
RoomNumber.put( "single", 1 );
RoomNumber.put( "double", 2 );
RoomNumber.put( "twin", 3 );
RoomNumber.put( "suite", 4 );
return RoomNumber.get( size );
}
느낀 점
이전에 진행했던 프로젝트(메모장 프로젝트)는 클래스의 이름, 클래스에 들어갈 변수, 대략적인 메서드를 먼저 생각해서 하게 되었는데 이번 호텔 프로젝트는 출력되는 화면을 먼저 생각해 보기로 했다. 화면을 정리해보니 필요한 클래스를 빨리 정할 수 있었고 데이터가 어디에서 어디로 가야 하는지 어떤 메서드가 필요한지도 짧은 시간에 정해진 것 같다. 내가 하는 프로젝트가 '구현'에 관한 프로젝트라면 어떻게 구현하고 싶은지를 먼저 정하는게 중요하구나 라고 생각했다.
튜터님의 피드백을 듣고 나서 생각한건데 한 손님이 하루에 한 객실만 예약할 수 있도록 구현할 수 있었으면 더 좋았을 것 같다..! 날짜별로 DB를 만들어본다던가 했으면 좋았을 것 같다. 애초에 DB를 이용하지 말라는 말은 없었는데 DB를 이용해서 코드를 짰다면 훨씬 가독성도 높고 실무에 더 가까운 코드가 아니었을까? 다음 주 부터는 스프링을 배우는데 아마 스프링을 이용한 프로젝트를 진행하게 되면 DB를 활용하여 구현하게 될까? 두근두근하다..!
이전프로젝트에서의 경험을 바탕으로 변수나 메서드명, 전체구조를 다 잡고 작업을 들어가게 되었다. 그러한 상태로 역할을 나눠 보니 그렇게 어렵지 않아서 경험에 대한 중요성을 느끼게 되었다.
다만, 처음에 깃으로 레포를 파서 브랜치를 따고 마스터에 머지하는 방향으로 진행을 하게 되었는데 커밋명 같은 규칙을 정하지 않아서 커밋 히스토리를 보면 너무 들쭉날쭉한 것이 좀 정신없어 보였다. 다음 협업 때는 커밋명의 규칙도 어느 정도 정하는게 좋겠다고 생각했다.
팀원이 깃에 어떤 오류가 났는데 내가 정확히 그 상황을 아는게 아니기도 하고 나도 원래 하는 방식으로만 해서 그 문제를 결국 해결해주지 못하고 처음부터 다시 레포지토리를 클론해와서 브랜치를 다시 만들어서 작업하셨다. 내가 조금 더 깃에 대해서 숙련도가 높았더라면 도와드릴 수 있었을 텐데 아쉬웠다.
이번에는 전체적인 구조를 거의 내가 짜게 되어서 팀원들이 구조를 짤 때 참여를 거의 하지 못했다. 사실 같이 해야 하는데 경험을 빼앗은 거 같아 미안한 마음이 크다. 생각보다 구현하고 시간도 하루 이틀 남았는데 조금 더 여유를 가지고 약간 코드가 모자라더라도 조금 더 같이 했다면 더 좋았을 것같다.
'SPARTA Project' 카테고리의 다른 글
[ Spring ] Trillion 조 - Exercise Blog Project KPT (0) | 2023.07.07 |
---|---|
[ Spring ] Trillion 조 - Exercise Blog Project 시작! (0) | 2023.06.30 |
[Java] HI5조 - 메모장 프로젝트 (6/2 - 6/5) (0) | 2023.06.05 |
[Java] 개인 프로젝트 - 키오스크 구현 정리(5/26 ~ 6/2) (0) | 2023.06.02 |
< 초록색이 젤다 맞죠? > - KPT 회고 (0) | 2023.05.19 |