자바캔(Java Can Do IT)

1월 28일 예정되어 있는 DDD 쌩기초 세미나 발표 자료입니다.
세미나 관련 정보는 http://cafe.daum.net/javacan/9Voo/88 에서 확인할 수 있습니다.
 

많은 입문서에서 캡슐화(encapsulation)를 단순히 private을 사용해서 필드를 외부에 감추는 것 정도로 소개하고 넘어가는 경우가 많아, 많은 입문자들에게 오해를 심어주는 것 같다. 그래서 집필 중인 자바 프로그래밍 입문서에서 캡슐화와 관련된 부분을 블로그를 통해 공개하고자 한다. 아래 내용부터는 (아직 집필중인) 책의 캡슐화 부분을 발체한 내용이다.

* 본 문서는 책의 일부 내용을 발췌한 것으로서 온오프라인 상의 무단 배포를 금합니다.

캡슐화(encapsulation)

지금까지 자바에서 클래스를 만드는 방법을 살펴봤다. 필드를 이용해서 객체의 상태를 보관하고, 메서드를 이용해서 기능을 구현하고, 생성자를 이용해서 객체를 생성하는 방법을 공부 했다. 또한, public, protected, private을 이용한 접근 제어 방법도 살펴봤다.

그럼, 왜 클래스를 이용하는 걸까? C 언어의 구조체와 함수를 이용해도 자바의 클래스와 비슷한 구현이 가능할 것 같은데 말이다. 클래스를 사용하는 이유는 객체 지향 방식으로 구현하기 위해서이다. 자바는 클래스를 이용해서 객체를 표현하고 있으며, 자바 언어로 객체 지향을 잘 하기 위해서는 객체 지향 원칙에 따라 클래스를 작성해 주어야 한다.

그렇다면, 객체 지향의 가장 기본이 되는 원칙은 무엇일까? 바로 이 절의 제목인 '캡슐화(encapsulation)'가 객체 지향의 가장 기본이 되는 대원칙이다. 본 절에서는 완벽하게는 아니어도 조금이나마 독자가 캡슐화가 무엇이고 왜 캡슐화가 중요한 지 느낄 수 있도록 할 것이다.

흔히 객체 지향과 반대되는 개념으로 절차 지향을 언급하는데, 본 절에서는 아주 간단한 스톱워치 기능을 구현하는 과정을 통해서 절차 지향의 단점을 파악하고 캡슐화를 통해 어떻게 이 문제를 해결할 수 있는 지 살펴 볼 것이다.

절차 지향 방식의 구현

성능 측정 어플리케이션을 개발해서 고객에게 납품하기로 했다고 하자. 성능 측정을 위해 필요한 공통 기능은 실행 시간을 측정하는 것이다. 그래서 시간 데이터를 표현하기 위해 다음과 같이 밀리초(1/1000초) 단위로 시간을 보관할 수 있는 클래스를 작성하였다.


ProceduralStopWatch 클래스는 시작 시간과 종료 시간을 저장할 수 있는 두 개의 public 필드를 제공하고 있다. 성능 측정 모듈에서 종료 시간과 시작 시간 사이의 차이를 구하는 코드가 많기 때문에, 흘러간 시간을 쉽게 구할 수 있도록 getElapsedTime() 메서드를 추가로 구현하였다.

이제 ProceduralStopWatch 클래스를 사용하는 코드는 다음과 같은 방식으로 작성될 것이다.


수 개월을 문제 없이 개발해 나갔다. 그런데, 늘 그렇듯이 고객으로부터 요구 사항을 변경하자는 연락이 왔다. 필요에 따라 밀리초(1/1000초) 보다 더 세밀한 단위로 측정할 필요가 있기 때문에 밀리초뿐만 아니라 더 세밀한 단위로도 측정할 수 있게 해 달라는 것이었다.

아주 간단한 방법은 다음과 같이 나노초 단위로 측정이 필요한 코드에서만 startTime 필드와 stopTime 필드에 나노초 단위로 시간을 저장하는 것이다.


하지만, startTime 필드에 어떤 경우에는 밀리초 단위의 값을 보관하고 어떤 경우에는 나노초 단위의 값을 보관하게 되면, 개발 과정뿐만 아니라 유지보수 과정에서 문제가 발생할 것 같다. 이미 개발자 중 몇 명은 기준 없이 밀리초와 나노초를 섞어서 사용하기 시작했다.

그래서, 나노초 단위를 저장할 수 있도록 ProceduralStopWatch 클래스에 startNanoTime, stopNanoTime의 두 필드와 getElapsedNanoTime() 메서드를 추가하기로 결심했다.


이제 나노초 단위를 이용해서 시간을 측정해야 하는 코드를 다음과 같이 변경함으로써, 시간 단위가 나노초 임을 분명히 할 수 있게 되었다.


일단, 급한 불은 껐다. 그런데, 여전히 불안함이 떠나질 않는다. 만약 고객이 초 단위로 값을 구해 달라는 요구가 추가되면 어떻게 해야 하나? 또는 같은 시간을 초 단위, 밀리초 단위, 나노초 단위로 표현해 달라고 하면 어떻게 해야 하나? 아마 코드는 점점 복잡해지고 요구사항이 추가되거나 변경될 때마다 함께 수정되는 코드도 많아질 것이다.

자, 그러면 왜 이런 일이 벌어졌을까? 가장 큰 이유는 데이터를 중심으로 개발했기 때문이다. (데이터를 중심으로 개발하는 것이 전형적인 절차 지향 방식 개발이다.)

[그림3.18] 데이터를 중심으로 개발되는 절차 지향 방식

ProceduralStopWatch 객체를 사용하는 코드는 객체의 필드에 직접 값을 할당하고 값을 가져올 수 있다. 편의상 getElapsedTime() 메서드를 만들었지만, 마음대로 필드의 값을 조작할 수 있다. ProceduralStopWatch 객체의 내부인 startTime 필드와 stopTime 필드를 마음대로 접근할 수 있기 때문에 많은 코드들이 직접 ProceduralStopWatch 객체의 필드 데이터를 조작할 수 있으며, 이로 인해 ProceduralStopWatch의 내부 코드를 변경하게 되면 많은 코드의 변화를 유발하게 된다.

[그림3.19] 절차 지향에서는 데이터의 변화가 많은 코드의 변화를 유발시킴

요구 사항의 변화가 없다면 또는 추가되지 않는다면, 데이터를 중심으로 개발하는 게 문제가 되지 않는다. 하지만, 거의 모든 프로젝트에서 요구사항은 추가되거나 변경되기 마련이며, 데이터를 중심으로 개발할 경우 데이터의 변화는 많은 코드에 수정을 발생시키는 요인이 된다.

그렇다면 어떻게 해야 ProceduralStopWatch 클래스를 사용하는 코드에 영향을 주지 않으면서 (또는 영향을 최소화하면서) ProceduralStopWatch 클래스의 내부 데이터 구조를 변경할 수 있을까? 정답은 바로 ProceduralStopWatch 클래스의 기능을 캡슐화하는 것이다.

객체 지향 방식의 구현

스톱워치 예를 객체 지향 방식으로 재구성해 보겠다. 객체 지향의 핵심 중의 핵심은 캡슐화에 있다. 캡슐화는 자세한 내부 구현을 외부에 드러내지 않고 숨기는 것이다. 캡슐화를 하게 되면 내부에 데이터를 어떻게 저장하는 지, 그 데이터를 어떻게 처리하는 지, 또는 특정 기능을 어떻게 제공하는 지에 대한 내용은 드러내지 않는다. 단지, 객체가 어떤 기능을 제공하는 지만 공유하게 된다.

예를 들어, 스톱워치 예의 경우 시간 데이터를 어떻게 구하는 지 또는 어떤 타입으로 저장하는 지 등의 구현은 외부로 드러내지 않고 다음의 기능만 외부에 제공하게 된다.

• 스톱워치를 시작한다
• 스톱워치를 중지한다.
•  중지와 시작 사이의 시간 차이를 구한다.

스톱워치 기능을 제공하는 클래스를 캡슐화해서 다시 구현해 보자. 아래 코드는 객체 지향 방식으로 새롭게 구현한 스톱워치 클래스이다.


StopWatch 클래스는 시작 시간과 종료 시간을 보관하기 위해 startTime 필드와 stopTime 필드를 사용하는데, 이 두 필드는 private 이다. 따라서, StopWatch 클래스를 제외한 다른 코드에서는 이 두 필드에 직접 접근할 수 없다.

start() 메서드는 startTime 필드에 현재 시간 값을 밀리초 단위로 저장한다. stop() 메서드도 유사하게 stopTime 필드에 밀리초 단위로 현재 시간 값을 저장한다. 즉, 스톱워치의 시작과 중지를 처리하려면 이 두 메서드를 호출해야 한다.

getElapsedTime()은 long이 아닌 Time이라는 클래스 타입을 리턴한다. Time은 시간을 표현하기 위해 만든 클래스로서 아래와 같다.


StopWatch 클래스를 사용해서 시간 차를 구하는 코드는 다음과 같을 것이다.


앞서 절차 지향 방식에서는 필드에 직접 접근해서 필드 값을 변경했던 것에 반해 객체 지향 방식에서는 상세한 구현이 start() 메서드와 stop() 메서드로 캡슐화 되어 있다. StopWatch 클래스를 사용하는 코드는 start() 메서드가 내부적으로 어떻게 시작 시간을 저장하는 지에 대해서는 알 필요 없이, start() 메서드가 스톱워치의 시작 기능을 제공한다는 것만 알면 된다.

스톱워치를 중지한 뒤 흘러간 시간을 구할 때 사용된 리턴 타입은 long이 아닌 Time 클래스이다. long이 아닌 Time 클래스를 사용한 이유는 long은 시간을 표현하는 데 적합하지 않기 때문이다. 그래서 시간을 표현하기 위해 Time 클래스를 추가로 만들었고, Time 클래스로부터 필요한 값을 구하도록 했다.

이제 고객으로부터 새로운 요구사항을 받을 차례가 됐다. 절차 지향 방식을 설명할 때와 동일하게 나노초 단위로도 시간 차이 값을 구할 수 있어야 된다고 한다. 절차 지향 방식에서 ProceduralStopWatch 클래스를 사용하는 수 많은 코드를 변경해야 했던 기억이 새록 새록 떠오를 것이다. 하지만, 걱정하지 마라. 우리는 이미 스톱워치와 시간을 캡슐화하는 데 성공했고, StopWatch 클래스와 Time 클래스를 사용하는 코드에 어떤 영향도 주지 않고 이 두 클래스를 변경할 수 있다.

먼저, StopWatch 클래스가 내부적으로 나노초를 저장하도록 변경해보자. 다음과 같이 밀리초를 가져오는 코드를 나노초를 가져오는 코드로 변경했다.


Time 클래스가 생성자에서 입력받는 값이 밀리초에서 나노초로 변경되었으므로 Time 클래스를 다음과 같이 변경하였다. t 필드가 저장하는 값의 단위가 나노초이므로 getMilliTime() 메서드의 구현이 일부 변경되었고, getNanoTime()메서드가 새로 추가되었다.


나노초 단위를 수용할 수 있도록 StopWatch 클래스와 Time 클래스를 변경하였다. 이제 이두 클래스를 사용하던 코드가 나노초를 사용하도록 변경할 차례이다. 바꿔보자.


어떤가? 나노초 단위로 시간 차이를 구하기 위해서 변경한 코드는 Time 클래스의 getMilliTime() 메서드 대신 getNanoTime() 메서드를 사용하도록 변경한 것뿐이다. 나머지 코드는 하나도 변경되지 않았다.

고객으로부터 요구사항이 또 들어왔다. 초 단위로도 시간 차이를 표현하고 싶단다. 이건 아주 쉽다. 왜냐면 우리는 Time 클래스를 이용해서 시간을 표현하고 있기 때문이다. 다음과 같이 Time 클래스에 메서드 하나만 더 추가해주면 끝이다.


자세한 내부 구현을 숨기고 외부에는 기능만을 제공하도록 StopWatch 클래스를 캡슐화 하였다. 그리고, 스톱워치의 요구 사항이 변경되었지만 StopWatch 클래스를 잘 캡슐화 한 덕분에 StopWatch 클래스를 사용하는 코드에 거의 영향을 주지 않고 StopWatch 클래스를 변경할 수 있었다.

이게 바로 캡슐화의 힘이다. 내부 구현(특히 데이터)을 외부에 노출하지 않고 기능을 잘 캡슐화하게 되면, 해당 기능을 변경해야 하는 상황이 발생할 경우 특정 클래스로만 변화가 수렴되는 특징을 갖게 된다. 변화가 여러 클래스로 확산되지 않기 때문에 그 만큼 캡슐화 된 클래스의 수정은 용이하게 된다.

[그림3.20] 캡슐화는 요구사항 변화에 따른 코드 수정 범위를 최소화 해 준다.

실제로 다수의 소프트웨어는 개발 과정뿐만 아니라 개발이 완료된 이후에도 요구사항의 추가, 버그 수정 등으로 코드를 수정하게 된다. 만약 절차 지향으로 개발했다면 이런 수정 과정에서 변경되는 코드의 범위는 점점 커지게 되고 시간이 흐를수록 변화의 폭은 더욱 증폭된다. 따라서 절차 지향 방식에서 무엇인가를 변경하는 것은 개발자 입장에서 많은 위험과 어려움이 따르는 작업이 된다.

반면에 객체 지향 방식으로 개발했다면 변화의 범위는 소수의 클래스로 한정되는 경향이 있으며, 따라서 새로운 요구 사항을 (절차 지향에 비해) 쉽고 빠르게 수용할 수 있게 된다. 우리는 이미 StopWatch 예제에서 이런 특징을 확인할 수 있었다.

재사용을 위한 전통적인 객체지향 프로그래밍 접근법의 결점에 대한 극복

코드 재사용성 최대화-제 1 단계

코드의 재사용을 위한 방법에는 여러가지가 있다. 클래스의 상속은 그 중 한 방법이지만 연관성이 부족하므로 부분적으로 적합한 방법이라고 할 수 있다. 즉, 하나의 메소드를 재사용하기 위해서는 클래스 내의 다른 메소드와 멤버 데이터들도 상속해야 하기 때문이다. 불필요한 멤버들이 많아질수록 재사용을 위한 코드는 복잡해질 수 밖에 없다. 상속 받은 클래스의 부모 클래스에 대한 의존성은 또 다른 복잡성을 일으킨다. 부모 클래스에 가해진 변화는 자식 클래스들을 파괴한다. 부모 클래스와 자식 클래스 중 한쪽을 수정하면, 어떤 메소드가 오버라이드 되었는지 알기 어려워질 수 있으며, 오버라이드 메소드가 부모 클래스의 해당하는 메소드를 호출해야 하는지도 불분명해질 수 있다.

하나의 개념에 대한 작업을 수행하는 메소드는 자신의 부모 클래스에 의존할 수 있으므로 재사용할 수 있는 첫번째 대상이다. 이를 위하여, 고전적인 프로시져 프로그래밍처럼 코드를 클래스 인스턴스의 외부 메소드로 옮겨서 전역적으로 노출된 프로시져로 만든다. 그리고 이 프로시져의 재사용성을 높이기 위하여 코드를 정적 메소드로 만든다. 즉, 이 프로시져는 주어진 파라미터와 전역적으로 노출된 다른 프로시져만을 사용해야 하며, 로컬 변수 이외에는 사용하면 안된다. 외부 의존도를 축소시킴으로써 프로시져를 사용하는 복잡성을 감소시키고, 어디서나 재사용할 수 있는 가능성을 높인다. 물론, 코드를 재사용할 목적을 가지고 있지 않다고 해도, 이 구조는 확실히 더 명료하다.

자바에서는 클래스의 외부에 메소드가 존재할 수 없으므로, 관련된 프로시져들을 모아서 하나의 클래스 내에 전역적으로 노출된 정적 메소드로 만든다. 예를 들면, 다음과 같은 형태의 클래스를 생각해볼 수 있다.


이 코드를 다음과 같이 바꾼다.


그리고, pPolygon 클래스는 다음과 같다.


pPolygon 클래스는 Polygon 타입의 객체들과 관련된 프로시져들만을 반영하는 클래스이다. 이름 첫자의 p는 단지 이 클래스의 목적이 정적 프로시져들이 전역적으로 보이기 위하여 만든 그룹이라는 것을 나타낸다. 자바에서 클래스 이름이 소문자로 시작하는 것은 표준이 아니므로 pPolygon은 정상적인 클래스의 기능을 수행하기 위한 것이 아니라는 뜻도 포함된다. 즉, 객체를 만들기 위한 클래스가 아니라 단지 자바에서 사용되는 독립 요소일 뿐이다.

위의 예제에서 수행된 변화의 총체적인 효과는 클라이언트 코드가 기능의 재사용을 위하여 더 이상 Polygon 클래스를 상속하지 않아도 된다는 것이다. 그 기능은 이제 pPolygon 클래스에서 프로시져 원리로 사용될 수 있다. 클라이언트 코드는 필요한 기능성만을 사용하면서 필요 없는 기능들을 걱정할 필요가 없어진다.

이러한 새로운 프로시져 프로그래밍 스타일에서 클래스라는 단위가 유용한 목적으로 도움을 줄 수 없다는 것을 의미하는 것은 아니다. 반대로, 클래스는 그룹을 이루고 표현하는 객체의 멤버 필드들을 캡슐화하는 데 필요한 역할을 수행한다. 게다가, 복수의 인터페이스를 상속/구현함으로써 다형성을 지닐 수 있는 능력은 다음 단계에서 설명할 뛰어난 재사용성을 가능하게 해준다.

이 기법과 유사한 형태가 디자인 패턴 서적에 간단히 언급되어 있다. Strategy 패턴은 관련된 알고리즘들의 패밀리 멤버들을 공통 인터페이스 뒤에 캡슐화하여 클라이언트 코드가 그 알고리즘들을 상호교환할 수 있도록 만드는 것을 제안한다. 알고리즘은 보통 하나 또는 몇 개의 독립적인 프로시져로 코딩되므로, 이런 캡슐화는 여러 작업들을 수행하는 코드와 데이터를 포함하는 객체의 재사용을 넘어서 하나의 작업을 수행하는 프로시져의 재사용성을 강조한다.

그러나, 알고리즘을 인터페이스 뒤에 캡슐화하는 것은 알고리즘이 인터페이스를 구현한 객체로 코딩되어야 한다는 것을 암시한다. 이것은 프로시져가 여전히 내포된 객체의 데이터와 다른 메소드들과 커플링되어 있으며, 따라서, 재사용을 복잡하게 한다는 것을 의미한다. 또한 알고리즘이 필요할 때마다 그 객체를 생성해야 하며 프로그램의 성능을 저하시킨다. 디자인 패턴에서는 이 두가지 문제에 대한 해결책을 제시하고 있다. Strategy 패턴의 객체를 코딩할 때 Flyweight 패턴을 적용하면 잘 알려진 공유 인스턴스가 되며, 각 공유 객체는 액세스들 간에 상태를 유지하지 않는다. 즉, 객체는 멤버 데이터를 가지고 있지 않으므로 커플링 문제를 잘 처리할 수 있다. Flyweight-Strategy 패턴은 이 단계의 전역적으로 노출되고 상태가 없는 프로시져로 기능을 캡슐화한 기법과 매우 유사하다.

코드 재사용성 극대화-제 2 단계

클래스를 상속하는 것보다 인터페이스 파라미터 타입을 통하여 다형성의 장점을 추구하는 것이 객체지향 프로그래밍에서 재사용의 원리에 더 충실하다.

"클래스보다 인터페이스로 프로그래밍하는 것으로 재사용성을 얻을 수 있다. 메소드의 모든 파라미터가 이미 알고 있는 인터페이스에 대한 레퍼런스이고, 그 인터페이스가 전혀 알 수 없는 클래스에 의해 구현된다면, 그 메소드는 코드가 작성될 때 존재하지도 않는 클래스의 객체와도 작동할 수 있다. 기술적으로, 재사용 가능한 것은 메소드이며, 메소드로 전달되는 객체가 아니다."

이러한 사항을 1단계의 결과에 적용하면, 어떤 기능의 코드가 독립하여 전역적으로 노출된 프로시져이면, 클래스 타입의 입력 파라미터를 인터페이스 타입으로 바꿈으로서 재사용 가능성을 더 높일 수 있다. 그러면 인터페이스 타입을 구현한 어떤 클래스의 객체도 파라미터로 사용될 수 있게 된다. 따라서, 이 프로시져는 잠재적으로 다수의 객체 타입에 대하여 사용이 가능해진다. 예를 들면, 다음과 같은 전역적으로 노출된 정적 메소드를 생각해보자.


이 메소드는 주어진 사각형이 주어진 좌표를 포함하고 있는지 아닌지를 알려준다. 여기서 rect 파라미터를 클래스 타입 Rectangle에서 인터페이스 타입으로 바꾸어보자.


Rectangular 인터페이스는 다음과 같다.


이제 Rectangular 인터페이스를 구현한 클래스의 객체가 pRectangular.contains() 메소드의 rect 파라미터로 전달될 것이다. 이 메소드는 전달되는 파라미터의 제약으로부터 느슨해지면서 재사용 가능성이 높아졌다.

그러나, 위의 예제에서 Rectangular 인터페이스의 getBounds() 메소드가 Rectangle을 반환한다면 실질적인 이점이 있는지 의아하게 생각될 것이다. 즉, Rectangle 객체가 전달될 것을 안다면 Rectangle 타입을 전달하는 대신에 Rectangular 인터페이스 타입을 전달하는 이유가 무엇인가하는 것이다. 이렇게 하는 가장 중요한 이유는 콜렉션을 다룰 때이다. 다음 메소드를 생각해보자.


위의 메소드는 주어진 콜렉션 내의 사각형 객체 중에 어느것이라도 중첩된 것이 있는지 알려주는 메소드이다. 이 메소드 내에서 콜렉션 내의 객체들을 차례로 순환할 때, 객체의 타입을 Rectangular 같은 인터페이스 타입으로 캐스트 할 수 없다면 객체의 사각좌표를 어떻게 구할 것인가. 유일한 방법은 객체를 원래의 지정된 클래스 타입으로 캐스트하는 것으로, 작동할 때 사용될 클래스 타입을 미리 메소드가 알아야하므로 그 타입의 재사용성이 제한된다. 이 단계에서 꼭 피해야만 할 점이다.

코드 재사용성 극대화-제 3 단계

2단계를 수행할 때, 주어진 클래스 타입을 대신하도록 어떤 인터페이스 타입을 선택해야 할까. 그 답은 프로시져가 파라미터로 필요로 하는 모든 것을 충분히 표현하면서도 부가적인 것들을 최소한으로 가진 것이다. 파라미터 객체가 구현할 것이 작은 인터페이스일수록, 어떤 특정한 클래스가 그 인터페이스를 구현하기에 좋고, 따라서 더 많은 수의 클래스의 객체가 파라미터가 될 수 있다. 다음과 같은 메소드를 보자.


두개의 (사각형인) 윈도우가 중첩되었는지 판별하는 메소드로, 이 메소드는 오직 두 파라미터의 사각좌표만을 필요로 하며, 따라서 이러한 사실을 반영하여 파라미터의 타입을 줄이는 것이 좋다.


위의 코드는 앞의 Window 타입의 객체가 Rectangular 인터페이스를 구현할 수 있다는 것을 가정한다. 이제 모든 사각형 객체들에 대하여 첫번째 메소드에 포함된 기능을 재사용할 수 있다.

파라미터로부터 필요한 것들이 충분히 지정된 유용한 인터페이스가 불필요한 메소드들을 너무 많이 가지고 있는 경우를 경험한적이 있을 것이다. 이 경우에는 이런 모순에 직면한 다른 메소드에 의해 재사용될 수 있도록 전역 이름공간에 새로운 인터페이스를 정의하면 된다.

하나의 프로시져에 대하여 단 하나의 파라미터로부터 필요한 것을 지정하기 위한 단일 인터페이스를 만드는 것이 최적인 경우도 경험한 적이 있을 것이다. 그 인터페이스를 오직 그 파라미터에 대해서만 사용할 것이다. 보통 이런 경우는 C 언어에서 함수 포인터처럼 파라미터를 다루고 싶은 경우이다. 예를 들면, 다음과 같은 프로시져가 있다.


이것은 주어진 리스트의 모든 객체를 제공된 비교 객체인 comp를 사용하여 비교하여 소트하는 것으로, 모든 sort가 comp로부터 원하는 것은 비교를 위해서 comp의 하나의 메소드를 호출하는 것이다. SortComparison은 단 하나의 메소드를 가진 인터페이스가 될 것이다.


이 인터페이스의 단 하나의 목적은 sort 메소드가 그 역할을 할 수 있도록 기능을 제공하는 것이므로, SortComparison 인터페이스는 다른 곳에서는 재사용될 수 없다.

결론

이 세 단계는 전통적인 객체지향 기법을 사용하여 작성된 기존의 코드에 적용될 수 있으며, 또한, 객체지향 프로그래밍과 결합된 세 단계는 새로운 코드를 작성할 때 적용할 수 있는 새로운 기법들과 함께 사용될 수 있으며, 메소드의 재사용성과 결합능력을 증가시키면서 커플링과 복잡성을 감소시킨다.

물론, 이러한 단계를 원래부터 재사용에 부적절한 코드에 적용할 수는 없다. 그러한 코드는 보통 프로그램의 프레젠테이션 계층에서 주로 발견된다. 프로그램의 유저 인터페이스를 만드는 코드와 입력 이벤트를 실제 작업이 수행되는 프로시져에 연결하는 콘트롤 코드는 둘 다 프로그램마다 너무나 다른 기능을 보여주기 때문에 재사용일 불가능한 예이다.

본 글의 저작권은 작성자(이동훈)에게 있으며, 작성자의 허락없이 온라인/오프라인으로 본 글을 유보/복사하는 것을 금합니다.