Method Chaining

메소드가 자신(this)을 리턴하여 메소드에 메소드를 연결하며 호출할 수 있게하는 기법의 정확한 이름은 Method Chaining이다(http://martinfowler.com/dslwip/MethodChaining.html). 이전 포스트에서 DML-style operations라고 표현해도 되나 의문을 가졌었는데 잘못된 것이다. Java 7에서는 이 기법이 아주 이디엄이 돼버렸는데 Chained Invocation으로 불린다.

 

소트웍스 앤솔러지를 보면 이와 비슷한 방법으로 마틴 파울러가 ruby 위에서 DSL을 구축해 나가는 과정의 글이 나온다. method chaining을 사용하여 문제영역을 표현하는 방법을 보이는데 언어위에서 DSL을 구축하는 방법으로 쓰이는 것이다(물론 ruby라는 동적 언어의 장점을 사용하여 DSL을 구축하는 방법이 추가되어 있다). 병특 시절 실용주의 프로그래머를 보면서 DSL에 매력을 느꼈었다. 그런데 좋긴 좋은데 언어 위에 다른 언어를 만들어 낸다는 내용을 읽으며 뭔소린가 하던 기억이 난다. 그리고 대신 Lex & yacc 펼쳤다는 ㅎ.

 

묵혀둔 질문 몇 개가 한 번에 해결됐다.

주석 패턴

iPhone 개발을 위해 Xcode를 사용하던 무렵에는 이런 주석들을 많이 달았다.

 

// TODO:

// FIXME:

// ???:

// !!!:

 

개발툴인 Xcode에서 이렇게 달린 주석들은 따로 관리를 해주기 때문이다. 이클립스에서도 // TODO: 를 지원해주던 것으로 기억한다.

메소드 추상화, 대칭성

같이 호출되는 메소드들의 대칭성을 유지하기 위해 메소드의 추상화가 요구된다. 메소드에 설명을 주기위해 다른 메소드를 그대로 한 번 더 호출 해줄뿐인 메소드를 만들 필요도 있다. 여기에 성능상의 비용은 크지 않다.

선택 메시지

조건문을 지우고 다형적 메시지를 호출하게 하는 방법. 다형성 설명에서 자주 등장하는 방법이다. 켄트 벡은 "선택 메시지를 사용하게 되면, 코드 독자가 연산의 세부 구현을 이해하기 위해 여러 개의 클래스를 살펴봐야 할 수도 있다"고 했고 "과도한 선택 메시지 사용은 좋지 않다." 라고도 했다.

 

선택 메시지를 무시하자는 목적으로 갈무리를 해두는 것은 아니다. 선택 메시지가 갖는 단점을 기억하기 위해서 적어둔다. "과도한"의 정의가 중요하다. 켄트 벡은 "당장 연산의 변형이 필요하지 않은 경우라면 미래 확장을 위해 굳이" 그럴필요 없다고 말한다.

 

추가. 단점을 기억하기 위해 쓰다보니 무조건 안좋은 것처럼 보인다. 전혀 아니다. ㅎ