저번 글의 끝에 아래와 같은 고민이 있었는데..
문제는
- 메인 감시 클래스에 모든 스레드 정보가 담겨있는 맵이 존재하는데, 이 맵은 스태틱이며 메인 감시 클래스에서만 접근이 가능해, 각각의 하위 클래스에 정보로 전달이 불가능했다.
- 어느 책인지 기억이 나진 않지만,
클래스가 멤버 변수가 없다면클래스가 아니다라는 글귀가 기억이 나는데, 이 글귀에 따르자면 각각의 하위 클래스는 클래스가 아니다… - 이렇게 스태틱으로 관리되는 맵이 있으면, 하위 클래스가 이를 전달받기 위해서는 어떻게 해야 할까? 상속? 인터페이스?… 이 부분을 고민해야 겠다.
일단
문제는 제껴두고 갓 클래스들을 보기쉽게 또 알기 쉽게 분해하고 책임을 나누고 작고 서술적인 메소드로 수정하며 로직에 불필요한 부분을 줄여나가고 있다.
지금 모든 클래스의 2/3을 끝낸거 같은데, 리팩토링 하다보니 느끼는 점이 있는데, 이때까지 나는 모든 것을 전부 객체 지향적 시선과 생각으로 보지 않고, 절차 지향적인 생각과 코딩으로 일관 했다.
조금 귀찮으면, static을 쓰고 여기 저기서 static 변수, 메소드, 클래스를 불러오며 덕지 덕지 모든것을 그렇게 수행했다. 이건 무슨… 구조만 클래스로 바뀐것 뿐이지, C 스타일 이다. 내 생각도 그렇고 지금 보고 있는 코드도 그렇다. static으로 도배하고, 이클래스와 저 클래스 사이에서 뛰어 노는 전역 변수들을 보고 있자니 머리가 아파온다.
이제 좀 공부한 보람이 있는것 같다. 클래스 기준으로 바라보는게 아니라, 객체와 객체간의 메세지를 전달하고, 캡슐화해 필요한 정보만 제공하며, 자기 할일이 끝나면 사라져 버리는 객체들 그리고 객체간 추상화 수준…
지금 내가 보고 있는 코드는 오합지졸의 합창을 보는것 같으며, 날아다니는… 아니 하늘 위에 우주가 있는지 모르고 땅만 보며 걸어 다니는 사람 같다…
천천히… 비즈니스 로직에는 영향이 없게 천천히 static을 걷어내고 객체 세상을 다시 건설해볼 생각이다.
추가
- 업무 프로그램 성격상 전역 변수로 선언되어 관리 되어야 할 데이터가 있다면, 프로그램이 시작될때 입력되어 프로그램이 끝날때까지 같이 가는 설정 정보들 일것이다.
- 이 데이터는 DTO 객체로 맵 형태로 관리되는데, 기존엔 여기 설정정보에 접근할때 어떠한 제약도 없었다. 중구난방 어디서든 접근이 가능했고, 프로그램 내부에서도 접근 메소드가 상당부분 흩어져 있었다.
ThreadPropertyAccess 이름으로 클래스를 만들고 내부에서 private으로 DTO 맵을 선언한뒤 접그네어자는 전부 public으로 메소드를 뽑았다. ThreadPropertyAccess 클래스는 특정 클래스에머 static으로 선언되어있고 프로그램 시작과 끝을 함께 한다. 이 클래스 접근 제어자도 선언된 클래스에 메소드로 설정되어, 이 통로로만 접근 가능하게 모든 접근 포인트를 줄여버리고, 제어 메소드는 Access 내부로 집중화 시켰다.