host - client 시스템 설계시 행한 오늘의 삽질

최근 host - client 시스템 하나를 설계하고 개발하고 있다.
host는 당연히 하나고, client는 여러대의 device들이다.
이들은 어떤놈은 wifi로 연결되고, 어떤놈은 tcp/ip (socket)로 연결되고 어떤놈은 serial, 어떤놈은 bluetooth로 연결된다.

연결방식도 복잡하지만, 통신 방법은 더 복잡하다.
단일 규약이 아니다. 어떤건 A규약을 사용하고 어떤건 B규약을 사용한다.
예를 들어 A규약을 쓰는 놈이 메세지를 읽는 방법이 (0x72 0x30) 이라면 B규약을 쓰는 놈은 메세지를 읽을때 (0x23 0x45 0x3a)를 사용한다.

host 시스템에 client device를 연결한다.
그리고 어떤 connectivity(tcp/ip, socket 등)를 쓰는지, 그리고 모델 명이 무엇인지 선택 후 Connect 버튼을 누른다.

이때 무슨 동작이 이루어 져야 하는가?

일단 당연히 프로그램 내에서 사용할 Device 클래스의 Instance를 생성해야한다.
그리고 Connectivity의 instance를 생성해야한다.
이 두개의 관리는 어떻게 이루어 지는가?

아래와 같이 했다.

Connect 버튼을 누를 경우 [ClientSession]을 생성한다.
한 host에 client가 하나밖에 붙을 수 없이 때문에, ClientSession은 싱글톤으로 만들었고,
ClientSession.GetInstance().ConnectDevice(model, connectivity) 를 수행했다.

이제 각 규약 별로.. 예를 들면
DeviceSamsung, DeviceApple, DeviceLG 이런식으로 IDevice를 상속받은 클래스를 두었다.
IDevice에는 Read, Write가 있고 이를 상속받은 놈들에겐 세부 내용이 있고..

그리고 생성자에서 Connectivity를 받아서 멤버 변수로 connectivity를 둔 다음에
구현부에서 이를 활용 할 수 있게 했다.

예를 들어
DeviceSamsung의 Write(int val) 메소드는
connectivity.Write(0x72,0x30,val) 이런식으로 쓸 수 있게 했다.

여기까진 모두 맘에 들었다.

맘에 안든 부분은..

현재 연결된 Device가 DeviceSamsung 을 써야하는지, DeviceApple을 써야하는지...
이를 구분해야 했던 것.

처음에는 ClientSession 내에 Create용 메소드를 두어서
if(model == "GalaxyS9") 일 경우 DeviceSamsung.. 이런식으로 접근했었다.

이럴 경우 모델이 많아 지면 if문이 덕지덕지 많아진다. 이런거 싫다....

그래서 두번째로 시도한 방법이
DeviceSamsung 안에 메타데이터를 만들어서
<SupportDevice("GalaxyS9")>
이런식으로 추가시켜놨다.

그리고 이 메타데이터를 분석하는 메소드를 static으로 접근 가능하도록(인스턴스 생성 전이므로..) 만들어놨는데
이렇게 했더니, 각 클래스 별로 이 분석하는 메소드가 중복으로 왕창 들어갔다.

뿐만 아니라 해당 디바이스 중에서도.. 예를 들면 이것의 속성이 '태블릿'인지, '스마트폰'인지 추가로 정의해줘야 하는 부분까지 필요하게 되었다.

으아악!! 어찌 해결해야 하는 것인가.

최종적으로 선택한 방법은, Dictionary를 제공하는 방법 이었다.

ClientSession 에서 DeviceDictionary를 참고해서 객체를 생성하는 것이다.

class DeviceDictionary에는 DeviceInfo 라는놈을 두어서
ModelName, ProductType,,,, 등등을 가질 수 있도록 하였고, 이 Dictionary를 뒤져서 일치하는 Device의 객체를 생성하도록.. 했더니
모든것이 해결되었다. 

여기까지 오기위해 쓸모없는 리플렉션의 남발.. 중복코드 사용.. 높아지는 의존성 등등 고민이 많았는데.. 단방에 해결해부렸다. 우왕 굳!

한줄 결론
앞으로는 중복 switch 문 사용을 줄이기 위해 무언가 해야한다면, 각 case별 상세 내용이 담긴 Dictionary를 제공해서
이를 통해 분기 결정을 하도록 해보자. 추가로 Dictionary에서는 default 속성들도 몇개 정의해 주면 더욱 좋음!

추가 Tip
앞으로 유지보수 중 switch문이 계속해서 늘어날 것 같은 상황에.. switch문 절대 쓰지 말아라!!!!!!!!!!!!
특히 model이 추가되는 경우 switch 쓰면 핵노답이다.. A method에서 사용한 switch문도 수정하고 B method에서 사용한 switch도 수정하고........
이 엄청 간단하고 반드시 해야하는 내용을 울 회사에는 모르는 사람이 왜이리도 많은가 흑흑... (SOLID 원칙을 공부해라 닝겐들아!!)