왕도란 없다

고찰인데 사진이 없다면 마치가 나와요

저번에 비동기처리 프로젝트를 하면서 내부클래스로 재미를 좀 봤다. 사실 재미라기보다는 코드줄 좀 줄였다 정도

 

 

이번에는 개발을 하다가 들어온 DTO에 맞춰서 인스턴스 변수를 생성하고 특정 메서드를 작동시켜야할 일이 있었다.

    class SetLocationForGetter {
        private long requestId;
        private long location;

        void getterLocation(getterLocationDTO getterLocationDTO) {
            this.requestId = getterLocationDTO.getRequsetId();
            this.location = getterLocationDTO.getLocation();
        }

        ResponseEntity<NormalResponseDTO> sendLocation(getterLocationDTO getterLocationDTO) {
            getterLocation(getterLocationDTO);

            //자신의 현재위치를 제시자에게 알리기
            NormalResponseDTO response = NormalResponseDTO.builder()
                    .code(200)
                    .message("성공")
                    .build();

            return ResponseEntity.ok(response);
        }
    }

    private static class SetLocationForSetter {
        private long requestId;
        private String certainLocation;

        void setterLocation(setterLocationDTO setterLocationDTO) {
            this.requestId = setterLocationDTO.getRequestId();
            this.certainLocation = setterLocationDTO.getCertainLocation();
        }

        ResponseEntity<NormalResponseDTO> sendLocation(setterLocationDTO setterLocationDTO) {
            setterLocation(setterLocationDTO);

            //정확한 약속장소를 수락자에게 알리기
            NormalResponseDTO response = NormalResponseDTO.builder()
                    .code(200)
                    .message("성공")
                    .build();

            return ResponseEntity.ok(response);
        }
    }

이렇게 두 클래스에서 인스턴스변수만 조금 다를 뿐이지 나머진 전부다 동일했다. 메서드에서 무엇을 수행할 것인지도 동일하고.. 그래서 저번에 했던 것처럼 내부클래스에 넣으면 좋지 않을까했다. 리팩토링도 좀 할 겸. 상속으로 묶기는 좀 그렇고 나중에 인터페이스로 묶기는 좋을 것 같다고 생각했다.

@Service
class SetLocationService {
    ResponseEntity<NormalResponseDTO> sendLocation(setterLocationDTO setterLocationDTO) {
        SetLocationForSetter.(setterLocationDTO);
    }

    private static class SetLocationForSetter {
        private long requestId;
        private String certainLocation;

        void setterLocation(setterLocationDTO setterLocationDTO) {
            this.requestId = setterLocationDTO.getRequestId();
            this.certainLocation = setterLocationDTO.getCertainLocation();
        }

        ResponseEntity<NormalResponseDTO> sendLocation(setterLocationDTO setterLocationDTO) {
            setterLocation(setterLocationDTO);

            //정확한 약속장소를 수락자에게 알리기
            NormalResponseDTO response = NormalResponseDTO.builder()
                    .code(200)
                    .message("성공")
                    .build();

            return ResponseEntity.ok(response);
        }
    }

    private static class SetLocationForGetter {
        private long requestId;
        private long location;

        void getterLocation(getterLocationDTO getterLocationDTO) {
            this.requestId = getterLocationDTO.getRequsetId();
            this.location = getterLocationDTO.getLocation();
        }

        ResponseEntity<NormalResponseDTO> sendLocation(getterLocationDTO getterLocationDTO) {
            getterLocation(getterLocationDTO);

            //자신의 현재위치를 제시자에게 알리기
            NormalResponseDTO response = NormalResponseDTO.builder()
                    .code(200)
                    .message("성공")
                    .build();

            return ResponseEntity.ok(response);
        }
    }
}

근데 그러면 문제가 생기는게,

나머지는 같다고 하더라도 가장 중요한 두 내부클래스가 공유하는 인스턴스가 달랐다. 그러면 인스턴스를 따로 선언해주어야하고, 그러면 내부클래스를 static으로 선언하지못하고, 그럼 외부클래스에서 내부클래스를 또 선언해야하는, 코드 가독성이 그냥 다른 클래스로 구분하는 것보다 떨어졌다.

 

지금 클래스들이 죄다 비슷한 역할을 수행 중이라 어떻게든 묶어보려고했던건데.. 잘 안됐다. 나중에 인터페이스를 쓰던가 해야하는데 개발하면서 바로바로 추상화를 적용하자니 아직은 좀 어렵다. 우선 만들고 리팩토링을 통해 추상화를 진행한 다음 경험이 쌓이면 만들면서 추상화를 진행해야할 것 같다.

 

암튼 왕도란 없다

한 문장에 꽂혀서 그걸 아무곳이나 적용시켜보지 말자

상속도 그렇고 내부클래스도 그렇고

 

추가로 소스코드에 클래스가 두 개 이상 선언되어도 될까 생각했다.

그러고보니 너무 틀에 갇혀서 개발하려고하는게 아닐까 싶다.

 

파이썬으로 백준을하다보면 '그냥 되라 코드는 나중에 수정할게'라는 생각으로 가볍게 임했는데

자바로 개발하다보니 뭔가 좀 아키텍쳐가 중요하고 원칙을 지켜야하고 클래스에 여러 작업을 주면 안되고 코드가 길어지면 바로 분리해야할 것 같고 약간 강박증처럼 개발하려고 했던 것 같다.

 

이번개발에서는 약간 원칙이나 깔끔한 코드는 우선 두고

GPT없이 그냥 돌아가는 것을 목표로하는 지저분하고 더러운 코드를 짜는 것을 목표로한다.