이상(추상화 계층 분리) vs. 현실(기능) 체스 게임에서는 폰은 특별한 이동규칙을 가진다. 첫 이동에 2칸을 이동할 수 있고, 공격을 하는 경우는 대각선으로도 이동이 가능하다. 하지만 다른 기물들은 이렇게 특별한 이동규칙을 가지지 않는다. (나이트, 퀸, 비숍 등) 나는 모든 기물들을 하나로 추상화 해 다루고 싶었으나 폰을 추상화하는 과정에서 어려움을 겪었다. 아무리 생각해도 폰과 다른 기물들을 하나로 추상화 할 수 있는 수단을 찾지 못했었다. 따라서 폰의 이동규칙만 특별하게 상위 개념인 Board 객체에서 다뤘다. 이 부분에 대해서는 당연히 지적이 들어올 것이라 생각했고, 나도 개선해야 할 점이라 생각했다. 그리고 이것이 가지는 단점이 무엇인지 생각도 해보았는데, 아래와 같은 결론을 도출할 수 있었다..
방어 로직 세팅하기 체스 미션은 4단계까지 존재했다. 1단계에서는 체스 보드 생성, 2단계에서는 체스 말 이동 구현, 3단계에서는 점수 기능 구현 등, 각각의 단계마다 요구하는 게 달랐다. 나는 2단계까지 구현을 마친 시점에서 적팀 말을 잡는 기능은 현재 단계의 요구사항에서 벗어난다 생각해서 구현하지 않았다. 하지만 리뷰어분이 '구현되지 않았다면 적절한 방어 로직이 세팅되었는지'를 여쭤봐 주셨다. 생각해보니 내가 만든 어플리케이션은 불완전했다. 말을 잡는 기능을 구현하지도 않았는데, 이동 위치에 적팀 말이 있는 경우 덮어씌우는게 가능했다. 실제 서비스는 이렇지 않을 것이다. 분명 시간적 제약 등으로 중요한 기능만 먼저 딜리버리해야 하는 시점이 존재할 것이고, 딜리버리되지 않은 기능들은 사용자에게 오동작으..
mermaid 나는 설계를 할 때 시각화를 하는 것을 좋아한다. 그래서 이전까지는 draw.io 를 통해 다음과 같은 방식으로 다이어그램을 그린 후 구현을 시작했다. 하지만 시스템의 구조는 항상 동일한 것은 아니다. 변할 수 있다. 그렇기에 매번 다이어그램을 갱신하는 것은 귀찮았고(?) 문서가 코드를 따라가지 못하는 상황이 왔었다. 리뷰어분은 Mermaid 사용이 어떠냐고 제안해주셨고 다음과 같이 개선할 수 있었다. 정적인 문서를 조금이라도 더 동적으로 바꾸고, 간편하게 다이어그램을 그릴 수 있다는 점에서 좋다고 생각한다! 무상태 컨트롤러 나는 보통 컨트롤러에서 가장 추상적인 도메인 객체를 상태로 갖고 있게 코드를 짠다. 즉, 다음과 같은 식이다. public class BlackJackControlle..
예외처리 메커니즘 예외 메커니즘은 예외 상황의 문맥을 전달하기 위해 사용합니다. 커스텀 예외란, 개발자가 직접 정의한 예외입니다. 예외는 예외 상황에서만 사용해야 합니다. 예외처리를 클라이언트에게 강제하고 싶은 경우, Checked Exception을 사용합니다. 디미터 법칙 디미터 법칙이란 의존성을 관리하기 위한 한 가지 법칙입니다. 디미터 법칙은 TDA(Tell, Don’t Ask)원칙을 준수하게 만듭니다. 디미터 법칙은 대상이 자료구조라면 위반될 가능성이 없습니다. 추상 클래스, 인터페이스 추상 클래스 상속(구현 상속)은 개념 면에서 밀접한 연관이 있는 객체들에게 사용합니다. 인터페이스 상속은 개념적으로 관련이 없더라도 공통 행위를 정의하고 싶다면 사용합니다. 인터페이스는 다중 상속이 가능합니다. ..
레벨1의 마지막 미션인 체스 미션이 종료되었습니다. 레벨1이 이대로 끝난다니 섭섭하기도 하네요.. 마음같아서는 한 달 정도 더 하고 싶은 생각입니다. 아무튼 체스 미션 과정에서 제가 느낀 점들을 잊기 전에 적어보려 합니다. 기술 회고는 내용이 많아질 것 같아서 따로 작성해야겠습니다 😀 새로운 페어와의 만남 새로운 페어인 제이미를 만났습니다. 제이미는 보통 페어의 개발 스타일에 맞춰주면서, 그 속에서 흡수해 나가는 것 같았습니다. 이 부분은 배워야 할 점이라고 생각했습니다. 저는 제 생각에 대한 은근한 고집..? 이 있어서 페어에게 많이 맞춰주는 것이 아직까지는 어려운 것 같습니다. 따라서 제이미를 통해 상대를 존중하는 방법, 상대의 사고과정을 지켜보는 방식을 배우게 된 것 같습니다. 그리고 개발 과정에 ..
들어가면서 얼마 전, 이펙티브 자바 스터디를 하면서 불변 객체에 대한 토론을 하게 되었습니다. 그리고 준팍, 아벨 등을 비롯한 크루분들도 불변 객체에 관한 고민을 많이 하고 있는 것 같았습니다. 그 과정에서 '불변 객체의 본질은 무엇인가?'에 대한 아이디어를 얻어 글을 작성해보려고 합니다. 불변객체를 구글에 검색해보면, 비용을 제외한 단점이 없는 것 같아 보입니다. 하지만 불변객체의 장/단점만으로는 적용 시점을 결정할 수 없는 것 같습니다. 불변 객체에 대해 검색하다보면, 아래와 같은 고민들이 당연히 피어날 수 밖에 없습니다. 무엇을 불변객체로 결정해야 할까? 언제가 비용을 지불하면서도 불변객체를 사용할 때일까? 하지만 불변객체 사용 시점은 단편적으로 결정할 수 있는 부분이 아니라고 생각합니다. 예를 들..
getter 사용은 과연 금기인가 우아한테크코스에 합류하고 객체지향과 클린코드라는 개념을 차차 알아가는 중이다. 좋은 코드를 만들기 위해서는 getter / setter 사용을 자제하라고 한다. 따라서 나는 코드를 짜면서 getter / setter 사용을 모든 상황에서 제거하려고 노력했다. 하지만 얼마 전 체스 미션을 진행하면서 이에 관한 내 생각이 흔들린 것 같다. View를 위해서가 아니더라도 getter를 사용해도 되는 상황이 있다는 것을 깨달았기 때문이다. 과연 getter 사용은 금기일까? 나는 아니라고 생각하게 되었고, 그 이유를 아래에서 풀어보고자 한다. 주관적인 내용이 많이 담겨있습니다. "getter를 사용하지 마라" 왜 위와 같은 말이 나왔을까? 시스템은 객체들이 메세지를 보냄으로써 ..
사실 회고는 따끈따끈하게 적어야 의미가 있는 것이라 생각하지만, 요 며칠 스터디와 체스 미션으로 인해 바빠 블랙잭 게임 미션에 대한 회고를 작성하지 못했다 😅 (회고를 제때제때 적는 것도 의식적으로 연습해야겠다..) 기술적인 부분에 대한 회고는 나중에 따로 다루기로 하고, 감정 회고를 먼저 작성해보려고 한다. 마코와의 페어 프로그래밍 블랙잭 게임을 통해 세 번째 페어인 마코를 만났다. 상당히 사고도 깊은 크루이고, 주관도 뚜렷하기에 페어 프로그래밍을 하는 내내 즐거웠던 것 같다. 나는 내 말에 정면으로 반박하는 페어가 참 좋은 것 같다. 기본적으로 내가 토론을 좋아하는 성격이기 때문이다. 마코는 의견 차이가 생기더라도 나를 설득하려고 애쓰는 모습이 좋았다. 반면 나는 페어 프로그래밍을 하기에 부족한 점이..
상태와 행위를 한 곳에서 관리하라 객체지향을 접한 뒤로, 나는 상태와 행위를 한 곳에서 관리 하라는 이야기를 많이 들었다. 상태와 행위가 한 곳에 없으면 어떻게 되길래 안된다고 하는걸까? 직접 실험해보자. 주관적인 내용이 많이 포함되어 있습니다. 오늘도 역시 자동차 경주 게임이 예시다. public class Car { private int position; public Car(final int position) { this.position = position; } public void setPosition(final int position) { this.position = position; } public int getPosition() { return position; } } 위와 같은 자동차 객체가..
표준 예외 & 커스텀 예외란 표준 예외, 커스텀 예외란 무엇일까? 표준 예외는 쉽게 말해, JDK가 제공하는 예외 클래스들을 의미한다. 커스텀 예외는 개발자가 직접 표준 예외를 커스텀 해(상속 받아) 만든 예외를 의미한다. 그렇지만 둘은 완전히 다른 개념이 아니다. 두 종류의 예외 모두 '예외 상황의 문맥을 제공'한다는 같은 목적을 갖고, '어떻게 예외 상황의 문맥을 제공할 수 있는지'의 방법만 다르다. 그렇다면 언제 무엇을 사용할지에 대한 생각을 안해볼 수 없을 것 같다. 주관적인 내용이 많이 포함되어 있는 글임을 미리 밝힙니다. 커스텀 예외 사용 시 어떤 이득을 취할 수 있는가 커스텀 예외를 사용하는 경우, 다음과 같은 이득이 존재할 수 있다. 도메인 집약적인 표현이 가능하다 예외는 도메인의 정보일까..
