서비스에 인터페이스를 사용해야 하나?

한국 스프링 사용자 모임(KSUG)의 페이스북 그룹에서 스프링으로 웹 애플리케이션을 개발하면서 서비스에 인터페이스를 사용해야 하느냐는 토론이 있었습니다.

원래 그 글의 댓글로 작성한 글인데 무슨 일인지 댓글이 등록되지 않아서 이렇게 블로그에 올립니다.


모든 프로그래밍 원칙과 장치는 ‘적절히 써야 한다’는 대전제 아래에서 논의돼야 한다는 점을 먼저 밝히고 제 생각을 말하고 싶습니다. 프로그래밍 원칙을 위반한다고 지구가 무너지거나 감옥에 갇히지는 않죠. 누가 죽지도 않고요. 그렇다고 해도 어떤 원칙을 위반했을 때에는 원칙의 중요도 만큼 원칙을 무시한 결정이 적절했음을 설득하거나 그로 인해 생기는 문제를 해결할 책임을 위반하기로 결정한 사람(또는 조직)이 수용하고 감당하면 됩니다.

KSUG에서 논의된 내용을 요약하면

  • 인터페이스 없어도 AOP 잘 됨
  • 인터페이스 하나에 서비스 하나 뿐임
  • 인터페이스 때문에 가독성이 떨어짐
  • 테스트를 하면 인터페이스 구현체를  하나 더 만들게 됨
  • 테스트도 요즘 목 프레임워크 기술이 좋아서 인터페이스가 꼭 필요하지 않음
  • 프로젝트 규모와 중요도에 따라 다를 듯
  • 인터페이스를 나중에 추출하는 방법도 있음

저도 인터페이스가 비용인 건 인정합니다. 모든 코드는 비용이죠. 다만, 그 비용을 들인 만큼 얻는 가치가 있다면 투자하면 되고 없다면 투자해서는 안 될 것입니다. 프로그래밍에서 간접화와 추상화와 관련된 코드를 비용으로 따진다면 간접비(overheads)에 해당할 것입니다. 따라서 과도한 간접화나 추상화는 피하도록 노력해야 합니다. 그렇지만 단순히 간접화나 추상화와 관련된 투자가 비용이라서 쓰면 안 된다는 식의 논리는 빈약입니다. 투자회수율(RoI)을 생각해야지 총비용만 무조건 줄이겠다는 생각은 현명하지 않습니다.

같은 맥락에서 @김지헌님이 링크 거신 동영상 강좌(?)에서 문제 삼은 “모든 클래스에는 인터페이스를 만든다”는 과격하고 경직된 정책은 저도 반대입니다. 그러나 저 화자께서 한 쪽의 극단적인 상황을 예로 들면서 그 반발로 또 다른 극단으로 치우치시는 것 같아서 저 강좌의 주장을 그대로 인정하지 못하겠습니다. 저 강좌를 얼마 전에 보고 따로 글을 쓰고 싶었는데 시간이 될지는 모르겠습니다.

OOP의 핵심, 메시징

살짝 한 발 물러서서 객체 지향 프로그래밍(OOP)이 뭔지 생각해 보는 게 좋을 것 같습니다. 최초의 OOP 언어라고 불리우는 두 언어가 있(었)습니다. 하나는 67년도에 나온 시뮬라 67이고 또 하나는 80년도에 나온 스몰토크-80입니다. 우리나라의 많은 사람들이 (아마도 마이크로소프트 덕에) C++를 통해서 OOP를 접했는데, C++는 시뮬라 67에서 OOP의 특성을 물려 받은 언어입니다. 우리가 OOP를 생각하면 흔히 떠오르는 객체, 클래스, 상속 같은 언어적 장치는 모두 시뮬라 67에서 소개되었습니다. 시뮬라 67에서는 프로그램을 작은 여러 독립 프로그램(객체)으로 나누고 이 작은 독립 프로그램들이 병렬적으로 서로 협력하며 동작하도록 하는 프로그래밍 모델을 도입했습니다.

Read On…

왜 자바는 포획된 지역 변수(Captured Local Variable)가 불변(final)이어야 하는 가?

요즘 자바 8의 람다식 때문인지 지역 클래스(Local Class), 무명 클래스(Anonymous Class), 람다식(Lambda Expression)에서 포획된 지역 변수가 final로 명시되거나 “사실상 final(자바 8에서 명시적으로 final 키워드가 붙지는 않았지만 대대입문으로 값을 바꾸지 않아 사실상 값이 바뀌지 않는 변수를 가리키는 용어)”이어야 하는 이유를 두고 온라인이나 오프라인에서 토론하는 일이 많아졌습니다. 저희 팀에서도 지난 주에 이를 가지고 의견을 주고 받았습니다.

이 때 말한 내용을 조금 자세히 정리해 보겠습니다.

내부 클래스 예제

먼저 간단한 예제 코드를 보겠습니다. 좀 쓸모있는 예제를 작성하려 했지만 역시나 그리 유용한 코드는 아닙니다. 예제로 만든 AsyncPrinter 클래스는 비동기로 문자열을 출력합니다.

package com.fupfin.capvar;

import java.io.PrintStream;
import java.util.concurrent.*;

public class  AsyncPrinter {
    private ExecutorService executor;
    private PrintStream out;
    private String prefix;
    private String suffix;

    public AsyncPrinter(ExecutorService executor, PrintStream out, String prefix, String suffix) {
        this.executor = executor;
        this.out = out;
        this.prefix = prefix;
        this.suffix = suffix;
    }

    public void printnln(final String str, final int maxlen) {
        final int len = str.length() > maxlen && maxlen >= 0 ? maxlen : str.length();
        executor.submit(new Runnable() {
            @Override public void run() {
                out.println(prefix + str.substring(0, len) + suffix);
            }
        });
    }
}

Read On…

스프링 언프레임워크(Spring Unframework)

작년에 처음 들었는데, 무척 흥미롭고, 얼마나 퍼질지, 경향으로 자리 잡을 수 있을지 지켜보는 용어가 하나 있습니다. 언프레임워크(Unframework)라는 용어에요.

이 용어는 작년에 cujoJS를 통해서 처음 접했습니다. 그리고 금년엔 구글에서 “unframework”이라고 입력하면 Flourish가 가장 먼저 검색되네요.

잠깐 검색해 봤을 때, 아직 아주 저명한 분들이 권위 있는 의미를 실어서 사용했다거나, 공통된 의미로 사용한다거나 하지는 않은 것 같지만 대략 다음과 같은 의미로 사용되는 것 같습니다.

  • 작은 애플리케이션이라서 소위 프레임워크라는 이름을 달고 나오는 거대한 기술까지 필요 없을 때 대용으로 쓸 수 있는 작은 프레임워크
  • 몇몇 프레임워크가 다루는 큰 주제가 아닌 작은 영역의 문제를 해결하는 툴킷 모음으로 프레임워크를 보조함
  • 클래스 라이브러리라고 부르기엔 아쉽고 프레임워크라고 부르기엔 잡스러운(?) 무엇

Read On…

Java 8 개선 사항 관련 글 모음

완벽한 설계에 이르렀다 함은,
더할 것이 없을 때가 아닌,
뺄 것이 없을 때를 말한다.
– 앙투안 드 생텍쥐페리

모 든 기술은 세 단계를 거친다. 처음엔 조잡하게 단순하고 매우 불만족한 기계, 두번째는 매우 복잡한 조율을 거쳐 원형의 결점을 극복하고 그로인해 어느정도 만족스러운 성능을 내도록 설계된 터무니없이 복잡한 기계 뭉치, 세번째는 거기에서 나온 궁극의 타당한 설계.
– 로버트 A 하인라인

이 단순성과 적절성을 강조하는 두 명언은 1996년 5월 제임스 고슬링과 헨리 맥길턴이 작성한 백서, 자바 언어 환경(The Java Language Environment)에서 자바 언어의 특징을 강조하면서 인용되었습니다. 자바는 처음부터 뺄 것이 많아 불완전하고 복잡한 2단계 기계인 C++애서 친근함은 유지하면서 불필요한 복잡성은 제거하는 것을 목표로 개발되었습니다. 그리고 단순(완벽)을 추구했던 만큼 여러 버전을 거치면서 대부분 SDK가 바뀌고 JVM이 개선되었을 뿐 언어 자체에는 별다른 변화가 없었습니다. 이런 자바가 지금까지 언어 측면에서 두 번 큰 변화를 겪었는데 첫 변화가 자바 5였고 그다음이 이번에 출시된 자바 8입니다. (자바 7에서도 언어가 여러 가지로 개선되었지만 큰 주목을 받지는 못했습니다.)

Read On…

역대급 50가지 프로그래밍 명언

TechSource에  올라온 “Top 50 Programming Quotes of All Time“이란 글을 번역했습니다.

  1. “오늘날 프로그래밍은 바보도 문제없이 쓸 수 있는 프로그램을 더 거대하고 더 낫게 구축하려 애쓰는  소프트웨어 기술자와 더 거대하고 더 나은 바보를 만들려는 우주의 경쟁이다. 지금까지는 우주가 이기고 있다.”
    “Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning.”

릭 쿡(Rick Cook)

 49. “리스프는 언어가 아닌, 건축 자재이다.”
“Lisp isn’t a language, it’s a building material.”
앨런 케이(Alan Kay)
  1. “물 위를 걷는 것과 명세서로 소프트웨어를 개발하는 것은 쉽다. 둘 다  동결되었다면…… ”
    “Walking on water and developing software from a specification are easy if both are frozen.”

에드워드 V 베라드(Edward V Berard)

Read On…