오늘 작성한 코드를 복기해 보았습니다.

데이터를 가져오지 말고

실제 도메인에서 안테나의 방위각 Limit 값(시계방향 또는 반시계 방향)이 음수로 정의되어 있다. 그런데 안테나 구동 경로를 생성하는 내부 알고리즘(변경할 수 없는 외부 라이브러리)에서는 방위각을 양수로 생성해 준다. 그래서 특정 조건이 되면 양수로 표현된 방위각을 음수로 변환해 주는 일을 해야 했다. 관련 로직에서 참조하기 위해서 Limit 값을 상수로 정의하려는데 도메인 영역에서 사용되는 음수로 정의할지 기술 영역에서 사용되는 양수로 정의할지 고민이 된다. 일단 기술 영역에서 생성된 양수 값과 비교를 해야해서 양수로 정의했다. 그런데 잠시 후 다른 코드를 작성하는데 동일한 의미를 가지는 Limit 값을 이번에는 도메인 영역의 음수 값을 그대로 사용할 일이 생긴다. 앞서 이미 양수로 정의했으니 사용하는 측에서 필요에 따라 부호를 변경해서 사용하도록 하면 되겠다.

private final static int CLOCK_WISE_LIMIT = 15;
... 
int domainLimit = -CLOCK_WISE_LIMIT;
int solutionLimit = CLOCK_WISE_LIMIT;

작업을 요청하라

순간 ‘데이터를 가져오지 말고, 작업을 요청하라!’는 객체지향의 기본 원리가 생각났다. 그래서 사용자가 데이터를 가져가서 가공하지 않고 필요한 값을 요청하도록 Limit 값을 사용자의 필요에 맞게 추상화한 클래스를 따로 정의했다.

public class TrackingLimit {
		private final static int CLOCK_WISE_LIMIT = -15;

		public static int getDomainClockWiseLimit() {
				return CLOCK_WISE_LIMIT;
		} 

		public static int getSolutionClockWiseLimit() {
				return Math.abs(CLOCK_WISE_LIMIT);
		} 
}

컨텍스트를 활용한 네이밍

훨씬 좋다. 그런데 메서드 이름이 너무 길어서 의미가 한 눈에 잘 보이지 않는다. 이럴 때 자주 사용하는 방법은 컨텍스트로 이미 부여하기이다. 예를 들면 메서드 이름이 너무 길면 클래스 이름과 메서드 이름과 파라미터 이름으로 단계적으로 의미를 부여해 보는 거다. 이번에는 메서드 이름과 파라미터로 의미가 분리되어 보이도록 아래와 같이 최종적으로 수정하였다.

public class TrackingLimit {
		private final static int CLOCK_WISE_LIMIT = -15;

		public static int getClockWiseLimit(Type type) {
            return switch (type) {
                case DOMAIN-> CLOCK_WISE_LIMIT;
                case SOLUTION -> Math.abs(CLOCK_WISE_LIMIT );
            };
		} 

		public enum Type {
				DOMAIN, SOLUTION
		}
}

개선의 영향

이렇게 코드를 변경하면서 일단 사용하는 입장에서 혼란이 크게 줄었다. 그냥 상수를 참조해서 사용자가 직접 가공하던 첫 버전에서는 상수가 음수인지 양수인지 구현 코드를 확인해서 내가 사용하려는 의미는 도메인인지 기술 영역인지 체크해서 변환을 해주어야 했다. 코드 곳곳에서 일관성 없이 실수하기 딱 좋은 함정 같은 코드였던 것 같다. 그리고 두 번째 코드 변경은 사실 미미한 영향이고 사람에 따라 어떤 것이 더 낫냐는 의견이 갈릴 수 있는 부분 같다. 어쨋든 내가 의도한 건 작업을 요청하는 메서드 호출 코드를 작성할 때 생각의 흐름을 둘로 나누고, 자연스러운 흐름을 따를 수 있게 하는 거였다. 그래서 시계방향 Limit 값을 얻고 싶다는 생각으로 메서드 이름을 작성하고 그리고 도메인 영역인지 기술영역의 값을 원하는지 파라미터로 요청하는 스타일의 메서드가 구현되었다. 여기까지 오늘 작성한 코드를 복기해 보았다. 유익한 시간 😊