생각하고 나누고 공감하기...

어떤 값이 있을 수도, 없을 수도 있는 상황에 쓸 수 있는 간단한 형태의 컨테이너 클래스가 스칼라에 있습니다. Option이란 클래스인데요. 이 클래스는 추상 클래스라서 인스턴스를 만들 수 없고 코드에서는 이 클래스의 하위 클래스인 Some이나 None을 사용합니다. Some은 값이 있음을 나타내고 그 안에 해당 값을 가지고 있습니다. 반면에 None은 값이 없음을 의미하며 아무런 값도 가지지 않습니다.

Option 클래스는 Map, List 같은 집합형으로 자료를 관리하려는데 특정 값이 있을 수도 있고 없을 수도 있다면 null을 넣는 대신 사용할 수 있습니다. 보통처럼 null을 넣게 되면 값을 집합형에서 꺼내면서 null인지 확인해야 하는데 이 사실을 문서화 해 놓더라도 자주 잊어버려 NullPointerException이 생기곤 합니다. 잊지 않고 기억한다 하더라도 매번 꺼낼 때마다 null인지 확인해야 하는 번거로움도 있습니다.

Map<String, Integer> repository = new HashMap<String, Integer>();
repository.put("key1", 1);
repository.put("key2", null);

if(repository.get("key2") == 1) { ... } // 예외 발생

이때 Option을 사용하면 값이 없을 때 기본값으로 대신 처리하도록 하거나 강제로 값이 없는지 판단하도록 할 수 있습니다.

Map<String, Option<Integer>> repository = new HashMap<String, Option<Integer>>();
repository.put("key1", Option.some(1));
repository.put("key2", Option.none());

if(repository.get("key1").getOrElse(0) > 0) { ... } // 기본값 사용

if(repository.get("key2").isDefined()) { // 값 유무 여부를 판단
   int value = repository.get("key2").get();
}

Option 유용하게 사용할만한 또 다른 곳은 반환 값입니다. 어떤 질의 메서드를 호출하고 결과로 값을 받는데 값이 없을 때는 null이 오거나 예외가 발생합니다. 값이 없지만 굳이 확인해야 할 필요가 없을 때는 메서드가 Null 객체를 반환하기도 합니다.

값이 없다는 사실을 null을 반환함으로써 표현하는 경우, 집합형을 쓸 때처럼 받는 쪽에서 null인지 확인하는 절차를 잊을 수도 있고 매번 null을 확인하는 불편을 감수해야 합니다. 이 때 메서드의 반환값이 없을 수도 있음을 명시적으로 나타내면서 간단히 처리하도록 하는데 Option이 좋습니다.

깃헙 기스트에 테스트 코드와 함께 올려 놨습니다.

https://gist.github.com/1263813

어제 어쩌다가 프레임워크 관련 문서를 하나 읽었다. 더글라스 C. 슈미트의 Object-Oriented Application Frameworks와 랄프 존슨의 Evolving Frameworks를 잘 요약해 놓은 문서였는데 이 문서 중에 이런 식이 적혀 있었다.

프레임워크 = 디자인 패턴 + 라이브러리

이 식을 보는 순간 뭔가 억지스럽다는 느낌이 들었다. 별다른 설명없이 이 식만 적혀 있었기에 글에서 (그리고 위의 두 문서에서도) 단서를 찾을 수는 없었다. 식을 보고 든 생각은 대략 이런 것들이었다.

• 디자인 패턴과 라이브러리를 합한 게 프레임워크라고?
• 디자인 패턴이 GoF의 디자인 패턴이나 그에 준하는 설계 패턴들을 말하는 건가?
• 디자인 패턴이 프레임워크를 만들 때 중요한 역할을 하지만 프레임워크의 두 구성 요소 중 하나라고 할 수 있나?
• 혹시 디자인 패턴을 아키택처 패턴까지 포함한 넒은 의미로 사용했나?
• 그렇다고 해도 특정 애플리케이션 영역의 지식과 추상화가 프레임워크 제작에서 디자인 패턴보다 더 중요하지 않나?
• 라이브러리가 그걸 말하는 걸까?
• 라이브러리란 표현도 좀 어색한데? 어떤 의미로 사용한 거지? 보통은 상위 로직의 추상화가 아닌 하부 로직 모음을 라이브러리라고 하지 않나? 프레임워크에 유용한 클래스 라이브러리가 포함되기는 하지만 필수요소라고 볼 수는 없을 듯 한데... 뭐 이거야 얼마든지 다양하게 쓸 수 있는 여지가 많으니 일단 패스...
  

무엇보다 그냥 무시하지 못할 것이, 글 자체가 다른 유명한 논문을 요약한 글이기에 작성자가 자의로 이런 식을 쓰지는 않았으리라는 생각이 들었기 때문이다.
대략 이런 단상들이 복잡하게 섞여 떠오르다가 미투데이에 글을 썼다.

프레임워크 = 디자인 패턴 + 라이브러리 이란 공식의 근거는 뭘까? 논리적 비약이 있다고 보는데 혹시 권위 있는 논문이나 책에 근거를 두고 있다면 보고 싶구나

그랬더니 이일민씨가 댓글로 몇가지 단서가 될만한 얘기를 해 줬고 이 식의 원전일 수도 있는 문서를 하나 소개해줬다. ACM에 제출한 논문이라 돈을 주고 사야하나 했는데 간단한 구글 검색으로 구할 수 있었다. (-O-);
이일민씨는 계속 토론을 하고 싶어했지만 내가 배경지식이 없어 오해를 하고 있는 상황일 수도 있으니 일단 문서를 읽고 토론을 계속하거나 내 생각을 정리하기로 했다. (그래서 이 글을 쓴다).
이일민씨가 소개해준 문서는 GoF 중 한 사람인 랄프 존슨의 문서였고 문서 제목이 문제의 식과 비슷했다.

프레임워크 = 컴포넌트 + 패턴 (Frameworks = (Components+Patterns))

회사 업무 때문에 문서 읽을 시간이 없어서 퇴근길에 아이폰에 담아 두었는데 읽기 전까지 제목만 보고는 대략 이런 생각이 들었다.

• 문제의 식과는 달리 디자인 패턴이 아니라 그냥 패턴이라고 했군.
• 혹시 이 패턴은 애플리케이션의 문제 영역에 대한 해법을 패턴화한다는 뜻 아닐까? 아니면 그런 의미까지 포함한 더 넓은?
• 컴포넌트라... 재사용 가능한 클래스를 컴포넌트라고 한 건가?
• 프레임워크를 사용해 컴포넌트를 만든다고 말한다면 모를까 프레임워크의 두 구성요소 중 하나가 컴포넌트라니... 어떤 의미로 컴포넌트란 단어를 쓴 걸까?
• 프레임워크, 패턴, 컴포넌트가 복수다. (정확히는 모르겠지만 뭔가 느낌이 달라!)
  

참고로 내가 컴포넌트라는 말을 쓸 때의 의미는 대략 이렇다.

• 클래스를 하나 이상 사용해 구현한 기능 단위
  
• 소스 코드가 아닌 바이너리 상태로 배포/재사용된다.
• 경계 객체가 외부와의 인터페이스 역할을 한다.
• 여러 속성을 외부에서 설정해서 작동 방식을 조정할 수 있지만 일반 클래스 라이브러리보다는 응집도가 높아서 기능을 확장하기엔 한계가 있다.

아무튼 시간은 흘러 퇴근 시간이 됐고 문서를 읽었다. 피곤한 가운데 (10시 퇴근) 흔들리는 버스 안에서 읽었기에 정독하지는 못했기에 바로 이해했는지 모르겠지만 문서의 내용은 대략 이랬다.

• 프레임워크는 객체지향 재사용 기술이다.
• 프레임워크는 다른 전통적인 재사용 기술과 비슷한 부분도 있지만 차이점도 있다.
• 프레임워크는 장점도 있지만 단점도 있다.
• 프레임워크가 컴포넌트라고 말하는 사람이 있는데 비슷한 부분이 있음에도 프레임워크는 컴포넌트보다 더 (확장해서 애플리케이션의 특별한 상황에 맞추기에) 유연하고 (배우고 사용하기) 복잡고 어렵다.
• 프레임워크가 설계 재사용이라고 볼 수도 있지만, 다른 설계 재사용 기술이 별도의 설계 표현 방법을 사용하는 한편 프레임워크는 코드로 설계를 표현했다는 점에서 다르다. 프레임워크는 언어에 종속적이다.
• 프레임워크는 애플리케이션 생성기나 도메인 전용 아키텍처와도 유사하지만 다르다.
• 프레임워크는 패턴을 표현하기도 하고 패턴을 활용하기도 한다. 하지만 코드로 표현했다는 면에서 더 구체적이고 일부 구현을 했다는 점에서 유연성이 떨어진다.

 글에서 다른 재사용 기술과 프레임워크의 차이를 비교하면서 프레임워크의 성격을 정의한 문장은 이렇다.

Frameworks are firmly in the middle of reuse techniques. They are more abstract and flexible than components, but more concrete and easier to reuse than a pure design (but less flexible and less likely to be applicable). Although they can be thought of as a more concrete form of a pattern, frameworks are more like techniques that reuse both design and code, such as application generators and templates. Patterns are illustrated by programs, but a framework is a program.

 프레임워크는 분명히 재사용 기술들 중심에 있다. 프레임워크는 컴포넌트보다 추상적이고 유연하지만 순수한 설계보다는 구체적이고 재사용하기 쉽다(반면에 유연성이나 적용 가능성이 떨어진다). 프레임워크를 패턴을 구체화한 형태로 볼 수 있다. 그럼에도, 프레임워크는 애플리케이션 생성기과 템플릿처럼 설계와 코드 모두를 재사용하는 기술에 더 가깝다. 패턴을 설명할 때 프로그램을 사용하는 반면에 프레임워크는 프로그램 자체다.

 그럼 문서를 읽고 나서의 내 생각은 뭘까?
 일단 프레임워크 = 패턴 + 컴포넌트라는 식에 대한 생각은 이렇다.

• 이 식을 수식으로 보면 안 된다. 프레임워트가 단순히 하나 이상의 패턴과 컴포넌트의 "조합"이란 의미는 아니다.
• 그럼 이렇게 보면 어떨까? Pattern < Framework < Component. 어느 정도 문서의 내용과 비슷하지만 이것도 아니다. 프레임워크가 추상화 관점에서 패턴과 컴포넌트 중간 정도에 있는 건 맞지만 패턴이 컴포넌트로 구체화 되는 중간에 생기는 것은 아니다.
• 이 식을 변증법적으로 읽으면 어떨까? 즉 "+" 기호를 "종합"으로 읽으면? 비록 패턴과 컴포넌트가 정과 반의 관계는 아니지만 둘을 "종합"한 결과로 전혀 다른 성격의 합이 나왔다는 식으로 읽으면 어느 정도 글의 내용과도 일치하고 내 직관과도 어긋나지 않는다.

원래의 식인 프레임워크 = 디자인 패턴 + 라이브러리에 대한 내 생각은 이렇다.

• 일단 글에서 자세한 설명을 하지 않았기에 추측 이상은 어렵다.
• 랄프 존슨의 글이 원전이라면 패턴을 디자인 패턴으로 바꾼 건 오류에 가깝다. 흔히 디자인 패턴은 GoF의 디자인 패턴을 말할 때 사용하는데 이 디자인 패턴은 패턴이라는 도구를 객체 설계 영역에 적용한 결과며 랄프 존슨의 글에서는 디자인 패턴에 제한해서 패턴을 말하지는 않는다. 물론 디자인 패턴은 프레임워크 제작에 아주 중요한 역할을 한다.
• 컴포넌트를 라이브러리로 바꾼 부분도 오해의 소지가 크다. 흔히 라이브러리는 작은 하위 기능 요소의 묶음을 의미하며 컴포넌트 같이 덩어리가 큰 코드를 묶었다고 라이브러리라고 부르지는 않는다. (적어도 내 단어 사전에 의하면... 하지만 Evolving Framework에서는 컴포넌트 라이브러리란 말을 쓴다).

하지만 마음을 곱게 써야 성장한다고 하니 이 글 덕에 좋은 글을 읽을 수 있어서 고맙다고 해야겠고 오해의 소지가 있어 보임에도 아주 틀렸다고도 할 수 없으니 뭐... 그렇다. (응?)
다시 확인한 교훈 한가지는 가능하면 원전 또는 고전을 읽어야 한다. 사실 랄프 존슨의 논문은 여러 글에서 인용된 글이라서 어느 정도 부분적으로는 접했던 내용이다. 하지만 원문을 읽으니 확실히 이해의 깊이와 폭이 다르다.
나 같은 삼거리 개발자가 스프링 덕에 별 복에도 없는 좋은 지식을 익히게 된다는 생각이 든다. 좋은 API는 좋은 코드를 유도할 뿐 아니라 좋은 지식을 쌓게 하고 좋은 사람들을 만나게 한다. (갑자기 왠 뚱딴지 같은 결말?)

------

추가

여러 말을 했지만 내 논점은 딱 두 가지다.

1. 문제의 식에서 디자인 패턴이 뭘 말하는 걸까? 내 생각에 디자인 패턴이란 단어는 고유명사에 가깝다고 생각한다. 그러니 식에서 사용한 디자인 패턴이 GoF의 디자인 패턴을 말할 때 사용하는 디자인 패턴과 의미가 다르다면 표현을 바꾸거나 따로 설명을 해야 한다고 본다. 그리고 만약 정말 GoF의 디자인 패턴과 같은 의미로 사용했다면 디자인 패턴의 의미를 너무 강조한 것 아니냐는 생각이 든다. 프래임워크 제작에 디자인 패턴이 중요하지 않다는 말이 아니다. 비 본질적이라는 의미다. 내 말은 좋은 객체지향 코드 중에 디자인 패턴이랑 관계 없는 코드가 어디 있냐는 말이다.
   
2. 문제의 식이 자의적으로 만들어낸 식인지, 아니면 어떤 권위있는 원전에 근거를 두고 있는지 아직 모르겠다. 적어도 랄프 존슨의 글은 아니라고 본다.
   

이 글은 LangDev의 토론을 뒤늦게 읽고는 너무 늦게 토론에 참여하기 뭐해 극적거리기 시작해서 미완성인 채로 남겨 두었다가, KSUG의 토론을 보고 마무리 지어야겠다는 생각이 들었고, 오늘에야 시간을 나서(내서?) 결론 내려 한다.

자바 개발자라면 누구나 알겠지만 자바는 클래스를 하나만 상속해서 확장할 수 있다.

class GundamMk2 extends Gundam {
...
}

클래스를 둘 이상 상속 받을려고 하면 컴파일이 안 된다.

class SpaceGundamV extends Gundam, Valkyrie {
...
}

자바를 첫 프로그래밍 언어로 배웠거나 자바로 객체지향 프로그래밍에 입문한 개발자라면 별다른 의문 없이 이런 제약을 받아들였겠지만 C++나 다른 다중 상속을 지원하는 언어를 먼저 익힌 사람이라면 궁금해하거나 이상하게 여길지 모르겠다.

위 그룹스의 글에서도 그렇고 다른 다중 상속 관련 토론을 보면 늘 다중 상속에는 "다이아몬드 문제"가 있다는 얘기가 나온다. 더 나아가 "다이아몬드 문제" 때문에 자바가 다중 상속을 지원하지 않는다고 주장하는 사람도 상당히 많다.

그럼 다이아몬드 문제가 뭘까? 한번 알아보자...니 귀찮다. -_-); 그래서 위키백과 링크 하나 달랑 던져 놓고 넘어가겠다.

http://en.wikipedia.org/wiki/Diamond_problem

위키백과의 글을 보면(이라고 쓰고 감상하면 이라고 읽는다. 영어따위!) 알겠지만, 설명이, 짧다(잉?).  별문제 아닌 것 같다. 더구나 밑에 다중 상속을 지원하는 여러 언어에서 이 문제를 어떻게 다루는지 설명하고 있(는 것 같)다. 결국, 다중 상속에는 다이아몬드 문제가 일어날 수 있지만 이 문제는 여러가지 방법으로 해결할 수 있는 사소한 문제일 뿐이(라고 추측할 수 있)다. 그러니 이 문제 때문에 자바가 다중 상속을 지원하지 않는다는 주장은 그리 설득력이 없어 보인다.

KSUG 메일링에서 몇몇 분은 상속 자체가 쉽게 문제로 발전할 수 있는 여지가 있으니 다중 상속은 더욱 취약하고, 그래서 애초에 다중 상속을 금지한 것 아니냐고 말한다.

혹시 상속보다 구성을 사용하자는 말을 들어봤는지 모르겠다. 객체지향 프로그래밍의 상징처럼 여겨지는 상속을 가능하면 쓰지 말고 객체 구성을 활용하자는 격언이다. 상속은 코드를 재사용하는 멋진 아이디어지만, (템플릿 메서드 패턴처럼) 상속해서 쓰도록 미리 고려된 객체가 아니라면 무척이나 불안전하고 위험한 부작용이 생길 수 있다. 캡슐화가 깨져 조상 객체와 피상속 객체 사이에 강한 결합이 생길 가능성이 있는 것이다. 그래서 이런 예상 밖의 부작용을 막으려고 구상 클래스의 public 메서드를 final로 만들어 오버라이드하지 못하게 막기도 한다. 아니면 최소한 상속했을 때 문제가 생기지 않도록 내부 정보를 문서화하라고도 한다.

상속이 생각보다 그리 유용하지 않고 위험하기까지 하니 다중 상속은 얼마나 안 좋겠냐는 생각은, 막연하지만, 어느 정도 타당성이 있어 보이고, 다중 상속을 제거했다는 자바 설계자의 선택이 현명해 보이기도 하다.

그런데 애석하게도 다중 상속은 아주 유용하다. 단일 상속만 허락한다면 객체가 너무 경직된다. 아무리 객체의 단일 책임의 원칙을 강조한다고 해도 객체에 복합적인 특성을 부여해야 할 일이 많다. 객체 모델링을 할 때를 예로 들면, 말은 동물로 분류되면서 동시에 탈 것으로 분류될 수 있다. 스마트 폰은 정보기기면서 전화기다.

또, 나는 컴포넌트의 경계(boundary) 객체를 내부적으로 문맥(context) 객체로 쓰는 습관이 있는데, 이때도 다중 상속은 유용하다. 한 객체가 컴포넌트 외부와의 인터페이스 역할을 하면서 내부적으로는 문맥을 제공하니 한 객체가 바라보는 관점에 따라 두 가지 역할을 하는 샘이다. GUI의 콤보 박스는 입력창과 목록의 특성을 모두 가지고 있다고 할 수 있다.

아무리 객체가 현실을 그대로 모델링할 수 없다고 말하지만 어느 정도 다면성을 부여할 수 없다면 설계가 복잡해진다. 특히 정적 타이핑 언어에서는......

그래서 자바는 다중 상속을 지.원.한.다. 두둥!!!!

눈치 빠른 사람은 무슨 소린지 알아챘겠지만, 확실히 자바는 다중 상속을 지원하는 언어다. 다중 상속을 지원할 뿐 아니라 이런저런 문제를 일으키지 않도록 특별히 고려하기까지 하면서 말이다. 사실 자바를 비롯해 다중 상속을 지원하는 언어들은 다이아몬드 문제 같은 다중 상속의 문제를 회피하기 위해 나름의 장치를 마련해 놨다. 자바도 마찬가지로 자신만의 독특한 방식으로 다중 상속을 구현했다. 자바의 방식은 다이아몬드 문제뿐 아니라 다중 상속의 복잡성도 해결할 수 있다.

자바는 부모 객체가 특별한 조건에 부합될 때에만 다중 상속을 할 수 있도록 언어 차원에서 규제를 걸어 놨다. 더 정확히 말하자면, 자바에서 다중 상속을 하려면 부모 객체가 추상 객체여야 한다. 구상 객체는 다중 상속을 받지 못한다. 그것도 그냥 추상 객체면 되는 게 아니라 순수한 추상 객체여야 한다. 순수 추상 객체라는 말은 어떤 로직도 가지고 있지 말아야 한다는 의미로, 자바에서는 이런 추상 객체를 부르는 용어가 따로 있다. 바로 인터페이스다.

class ZetaGundam extends Gundam implements Fighter, Transformable  {
}

이쯤에서 내 말에 동의하는 사람도 있겠지만 버럭할 사람도 있으리라. 당신 말이 맞다. 자바는 다중 상속을 지원하지 않는다. 사실 상속도 지원하지 않는다. 무슨 말이냐고? 다음 코드가 자바에서 컴파일될까?

class RichChild inherits RichFather {
}

자바는 부자 아빠의 재산을 그 자녀가 물려받도록 허락할 생각이 없는 모양이다.

말장난을 한 김에 조금 더 해보겠다. 자바는 '상속'을 허락하지 않는 대신 '확장'할 수 있도록 하기로 했다. 우리는 습관처럼 extends라는 구문을 '상속'이라는 의미로 아무 생각 없이 쓰지만, 분명히 상속이 아니라 확장이다.

그게 그거라고?

아니다.

상속은 내가 물려받는 재산에 초점이 있다. 하지만 확장은 내가 해야 할 일의 성격에 초점이 있다.

졸리니 그냥 내가 말하려는 바를 말하겠다.

모 출판사의 편집자도 읽었다는 명저 Effective C++ (3판)의 32번과 38번 항목은 이렇다.

항목 32: public 상속 모형은 반드시 "is-a(...는 ...의 일종이다)"를 따르도록 만들자
항목 38: "has-a(...는 ...를 가짐)" 혹은 "is-implemented-in-terms-of(...는 ...를 써서 구현됨)"를 모형화할 때는 객체 합성을 사용하자

재산을 물려받는 '상속'이란 비유는 has-a가 될 가능성이 많다. '확장'이란 비유는 명백히 is-a를 뜻한다.

is-a는 부모 객체 A를 자식 객체 B가 상속했을 때 "B는 A다"라고 할 수 있음을 뜻하는 말이다. 팩토리 객체에 Pool 기능을 추가해 성능을 높이는 경우를 예로 들 수 있겠다. has-a로 변질되는 때는 마치 인간의 몸에 외계 생물의 DNA가 들어와 유전자를 변형시켜 인간이 아닌 뭔가로 바꿔버리는 경우다. 예전에 본 한 레가시 코드가 기억나는데, DB 질의 결과로 반환되는 객체가 RecordSet 형태였다. 소스를 열어보니 HashMap을 확장, 아니, 상속해서 만들었지만 어느 곳에서도 이 객체를 Map으로 다루는 곳은 없었다.

상속의 이런 측면을 메서드 수준에서 보면 객체지향 원리 중 하나인 리스코프 치환 원칙을 따른다고 할 수 있고 조금 거시적인 관점에서 보면 변경에 대해 닫혀있고 확장에 대해서는 열린, 개방-폐쇄 원칙 준수한다고 할 수 있다. 상속 받은, 아니, 확장한 자식 객체가 여전히 외부에서 봤을 때 부모 객체와 같게 보인다면 결국 좋은 객체지향 원칙을 준수하게 되는 것이다.

내 결론은 이렇다. 우리가 '상속'이란 말을 is-a로 사용한다면, 자바는 분명히 다중 상속을 지원하는 언어다. 반대로, has-a로 변질될 위험성이 있는 의미로 사용한다면, 자바는 다중 상속을 지원하지 않는 언어다. C++에서는 이 부분을 개발자가 실천해야할 규범으로 열어 놓았다면 자바는 언어차원에서 조금 더 강제할 뿐이다. 자바의 다중 상속 지원 방식이 최선인지는 모르겠다. 하지만 분명히 좋은 방법 중 하나라고 생각한다.

최근에 스칼라라는 언어를 공부하면서 트레잇(trait)을 알게 됐는데 이 또한 특수한 형태의 추상 객체로서 나름이 방식으로 다중 상속을 지원한다. 스칼라 진영 측에서는 인터페이스의 장점을 살리면서 단점을 보완한, 개선된 방식이라고 말하지만 나는 아직 확신이 안 선다. 뭐 똑똑한 사람들이 더 낫다고 하니 그런가보다 싶을 뿐이다. 사실 언어가 제공하는 장치를 너무 비판하는 것도 별로 지혜롭다고 할 수 없다. Effective C++에 반복해서 나오는 말처럼 "심사숙고"해서 잘 쓰면 된다.