Interface 상수가 Anti-pattern인 이유

■ Anti-pattern

우선 이에 대해 알아보기 전에 Anti-pattern에 대해 알아보도록 하겠습니다. 객체지향 프로그래밍에서는 싱글톤,옵저버 등 여러가지 디자인 패턴이 있습니다. 이러한 디자인 패턴은 객체지향 프로그래밍에 중요한 요소입니다. 하지만 이러한 디자인 패턴중에서 필요하거나 사용해야 하는 패턴도 있는 반면, 사용을 지양해야 하는 패턴들이 있습니다. 그런 패턴들을 Anti-pattern이라고 합니다.

Anti-pattern은 실제 많이 사용되는 패턴일지라도 비효율적이거나 비생산적인 패턴을 의미합니다. 이러한 anti-pattern의 여러가지 예시를 알아보도록 하겠습니다.

1. God object

하나의 클래스에 너무 많은 필드와 함수를 넣어서 너무 많은 것을 알고 너무 많은 것을 할 줄 아는 객체를 말합니다. 전지 전능한 객체라고 비꼬는 의미에서 God object라는 이름이 붙은것 같습니다. 

2. Spaghetti code

아마 가장 많이 들어보았을 용어중에 하나일 듯 합니다. 코드를 계획하지 않고 짜거나 여러가지 이유로 인해 이해하기 힘든 구조를 가진 프로그램을 말합니다. 코드가 스파게티같이 꼬였다고 해서 붙여진 경멸적인 용어입니다.

3. Hard code

이 역시도 가장 많이 들어보았을 용어중에 하나일것 같습니다. 프로그램 소스 코드에 직접 설정 값이나 입력 값이 삽입된 코드 입니다. 값들이 마치 hardware circuit처럼 고정되어 변경되지 않는다는 것에 유래된 용어입니다.

4. Software bloat

bloat는 부풀다는 뜻이며 프로그램의 새 버전이 나올 때마다 사용자에게 필요 없는 기능이 추가되거나 점점 더 많은 시스템 자원을 사용하는 경향을 이르는 용어입니다.

■ Interface 상수

그럼 본론으로 들어와서 인터페이스에서 상수를 사용하는 것이 왜 Anti-pattern인지에 대해서 알아보도록 하겠습니다. 다음 예시들은 (위키피디아)에 저술된 내용을 번역한 내용입니다.

1. 사용하지 않는 상수변수가 네임스페이스를 오염시킬 수 있습니다.

2. 만약 다음 릴리즈때 해당 상수가 필요 없어도 이전 버전과의 호환성을 유지하려면 해당 상수는 영원히 인터페이스에 남아 있어야 합니다.

3. 해당 상수가 어디에서 오는지를 쉽게 보여주는 IDE가 없다면 해당 상수를 찾기 위해 추적하는 시간은 오래걸릴 수 있습니다.

4. 인스턴스를 나타내는 인터페이스 변수는 유용하지 않습니다.

5. 외부에 API또는 라이브러리 형태로 제공할때 구현방식이 드러나게 됩니다.

■ 마무리

인터페이스를 많이 사용해 보긴 했지만 위에서 소개해 드린 내용중 공감이 가는 부분들이 그리 많지는 않은것 같습니다. 하지만 제가 인터페이스 내부에 상수가 존재하는 경우를 보지는 못했던것은 맞습니다. 아마 아직까지 인터페이스를 깊게 다뤄보지 않아서 공감하지 못하는게 아닐까 싶습니다. 제가 다룬 내용에 대해서 Effective Java에서 더욱 자세하게 다루고 있으니 한번쯤 보시는것도 좋을것 같습니다.