LISTORY

코드 리팩토링 [ 강박적 기본 타입 사용 / switch 문 ] 본문

IT/리팩토링

코드 리팩토링 [ 강박적 기본 타입 사용 / switch 문 ]

LiStoryTeller 2018. 4. 1. 17:48

강박적 기본 타입 사용


말 그대로 데이터를 사용할 때 강박적으로 기본 타입 데이터를 사용하지 말고, 객체를 사용할 줄 알아야 한다.


이를 적용하기 위한 여러 기법이 있다.


“데이터 값을 객체로 전환”

데이터 항목에 데이터나 기능을 더 추가해야할 경우, 데이터 항목을 객체로 만들자


이는 앞에 포스팅에서 언급한 데이터 뭉치를 객체로 전환하는 것과 비슷한 내용이다.


“분류 기호를 클래스로 전환”

기능에 영향을 미치는 숫자형 분류 부호가 든 클래스가 있을 땐 그 숫자를 새로운 클래스로 바꾸자


프로그램을 짜다보면, 열거형 변수들을 사용할 경우가 많다. 


이때 개발자는 알아보기 쉽게 변수명을 정의하지만, 실제 돌아가는 것은 숫자에 불과하다. 


그렇기 때문에 나중에 코드에 수정이 필요할 때, 헷갈릴 가능성이 많다.


이를 방지하기 위해 아예 분류 부호들을 하나의 클래스로 정의할 수 있다. 


새로 만든 클래스에서 분류 부호를 정리하고, 적절한 분류 부호만 전달하는 식으로 한다면 헷갈리는 부분을 많이 줄일 수 있다.


하지만 이 분류 부호를 switch-case문이나 if-else문에서 쓴다면 해당 방법을 사용해선 안된다.





switch 문


객체 지향 코드를 짜다보면 switch-case 문을 사용할 경우가 많다.


하지만 하나의 프로젝트 내에 같은 switch-case문이 존재하는 경우가 많기 때문에 코드의 중복이 생길 경우도 많다.


이러한 것을 방지하기 위해 switch-case문이 많이 사용되는 코드에서는 이를 분리, 재정의 하는 편이 좋다.


다형성 개념을 적용하여 재정의하면 얻을 수 있는 장점이 여러 개 있다.


일단, 새 타입을 추가했을 때, 코드에 있는 모든 조건문을 찾아가서 고치지 않아도 된다.


이렇게 하면 시스템 내부의 의존성이 줄어들고 수정도 쉬워진다.



예를 들어 동물에 관련된 프로그램을 짜고있다고 생각해보자.


이 동물이 기린이냐, 코끼리냐, 강아지냐에 따라 다른 코드를 적용해야 하고, 이런 부분이 상당 수 된다고 가정해보자.


이 부분을 분리하여 메서드로 정리하고, 메서드를 재정의해야 할 클래스에 옮겨 넣을 수 있다.


여기서 동물이 어떤 동물이냐, 기린이냐 코끼리냐 강아지냐 이렇게 구분하는 부호를 분류 부호라고 한다.


switch-case문에는 이렇게 항상 분류 부호가 존재하는데, 이 분류 부호를 하위클래스로 전환할 것인가, 또는 상태/전략 패턴으로 전환할 것인가를 판단하여 적용해야 한다.


“분류 부호를 하위클래스로 전환”

클래스 기능에 영향을 주는 변경 불가 분류 부호가 있을 경우엔 분류 부호를 하위 클래스로 만들자


이는 말 그대로 분류 부호가 있을 때, 이에 해당하는 하위 클래스를 생성하는 것이다.


간단히 말하자면, 동물의 하위 클래스 강아지, 코끼리, 기린을 생성하는 것이다.


이 방법의 장점은 변형된 기능을 추가해야 할 때, 하위 클래스만 하나 더 추가해주면 된다는 점이다.


“분류 부호를 상태/전략 패턴으로 전환”

분류 부호가 클래스의 기능에 영향을 주지만, 하위 클래스로 전환할 수 없을 때 분류 부호를 상태 객체로 만들자


이 기법은 위와 동일하지만, 하위 클래스로 전환할 수 없을 경우에 사용한다.


일단 분류 부호는 캡슐화하여 새로운 클래스를 작성한다. 이 것을 상태 객체라고 한다.


이 상태객체에 분류 코드를 반환하는 abstract 메서드 호출을 작성하고, 상태 객체의 하위 클래스를 생성하여 메서드를 재정하게 한다.






Comments