https://github.com/ChabinHwang/24-25-study-java-lotto/tree/chabin37
GitHub - ChabinHwang/24-25-study-java-lotto: 우테코 프리코스 Lotto를 진행하며 객체지향에 대해 공부합니다
우테코 프리코스 Lotto를 진행하며 객체지향에 대해 공부합니다. Contribute to ChabinHwang/24-25-study-java-lotto development by creating an account on GitHub.
github.com
'책/객체지향의 사실과 오해' 카테고리의 글 목록
전공 이외의 것들은 여기 작성하고 있습니다→ https://blog.naver.com/7chabin
chabin37.tistory.com
객체지향의 사실과 오해 라는 책을 읽고, 객체지향적인 코딩에 대해 처음 배운 것 같다는 느낌이 들었다. 이후 든 생각이 "예전에 제데로 못했던 로또 과제를 활용해 객체지향을 연습해보자" 였다.
학교에서 "소프트웨어공학적 요소들을 활용하면 코드가 빠르게 나온다" 라는 이야기를 듣고, 이번 기회에 이 말이 사실인지도 직접 검증해보고자 하였다.
OOAD(Object Oriented Analysis and Design)를 활용해보기로 했다.
1. 요구사항 도출&지정
나는 이 과정을 "메세지 정의" 과정을 통해 진행했다.
로또를 발급하고, 당첨 번호를 입력한 뒤 수익률을 계산하는 전반적인 흐름을 메세지를 통해 어떻게 나타낼 지 고민하였다.
2. Communication Diagram
책에서도 설명했던, UML2.0에서부터 사용된 다이어그램인 이 다이어그램을 활용하였다.


처음 그린 다이어그램이다.
그러나 이후 구현하면서 다음과 같은 문제와 해결방안을 생각했다.
- Prize 객체를 항상 손수 만들어야 함
- 다른 상금을 적용하고 싶으면, Prize객체를 새로 만들거나, 기존 객체를 수정해야 함
- 유저에게 입력받는 프로그램인데, 입력해주는 부분이 존재하지 않음(혹은 잘못된 관계로 이어져 있음)
- Seller에서 User객체를 OrderSequence에 파라메터로 넣으면 안됨. 따라서 User를 가지고 있을 필요가 없고, 메서드들도 void 대신 결과를 반환하도록 해야 함
- Float 대신 Double을 사용
- 변수명과 메서드명에 camelCase, 클래스와 인터페이스명에 PascalCase사용
이를 반영한 최종본이다.


물론, 최종본을 그리고 구현에 들어갔으면 좋겠으나...생각보다 마음대로 안되었다. 구현하면서 느낀 문제들에 대한 수정내용을 다이어그램에 적용해서 최종 다이어그램과 구현을 같이 했으므로 완벽하게 OOAD를 했다고는 할 수 없다. 그러나 한가지 확실하게 느낀것은, 무작정 코딩을 할 때 보다, 이러한 다이어그램들이 더 더 많아질수록 구현 난이도는 낮아지고 속도 또한 빨라짐을 느꼈다. 개발에 있어서, 코딩보다 이러한 구조 설계가 더욱 많은 시간이 소모되고 더 많은 부분을 차지한다고도 볼 수 있을 것 같다.
'Backend' 카테고리의 다른 글
| 헥사고날 아키텍처 (0) | 2026.02.18 |
|---|---|
| [개선] 🔒GDGOC admin 페이지 암호화 적용 건 (1) | 2025.08.31 |