<div id="readability-page-1" class="page"><div><h2 id="f81b">객체지향 바르게 이해하기 : 클래스 &amp; 인터페이스</h2>조영호 님의 ‘객체지향의 사실과 오해’ 책의 일부 내용을 정리한 글입니다. 부족하다고 생각되는 부분은 내용을 덧붙였으며 제 개인적인 생각이 중간중간 첨가되어 있습니다.<figure><div role="button" tabindex="0"><img alt="" src="https://miro.medium.com/max/1400/1*IKVMvSdWRJFdAvwTjxwxbQ.png" width="700" height="394" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="eager" role="presentation"></div></figure></div><div><blockquote>현상은 복잡하다. 현실은 단순하다. 버릴 게 무엇인지 알아내라.-리처드 파인만</blockquote><h2 id="b1e4">추상화를 통한 복잡성 극복</h2>현실은 있는 그대로 모두 받아들이기에는 너무나 복잡하다. 이 지독하게 복잡한 현실 속에서 우리는 우리에게 필요한 본질들만 골라낼 수 있어야한다. 이 과정을 추상화라고 부른다.추상화의 목적은 불필요한 부분을 무시함으로써 현실에 존재하는 복잡성을 극복하는 것이다. 그래서 추상화란 현실에서 출발하되 불필요한 부분을 도려내가면서 사물의 놀라운 본질을 드러나게 하는 과정이라고 할 수 있다.훌륭한 추상화는 목적에 부합하는 것이어야한다. 추상화가 의도된 목적이 아닌 다른 목적으로 사용된다면 안하느니만 못하다. 추상화의 수준, 이익, 가치는 목적에 의존적이다.추상화를 사용함으로써 우리는 극도로 복잡한 이 세상을 그나마 제어 가능한 수준으로 단순화 할 수 있는 것이다.<h2 id="a7c6">타입</h2>데이터 타입은 메모리 안에 저장된 데이터의 종류를 분류하는 데 사용하는 메모리 집합에 관한 메타데이터다. 데이터에 대한 분류는 암시적으로 어떤 종류의 연산이 해당 데이터에 대해 수행될 수 있는지를 결정한다.데이터 타입에 대해 정의한 이유는 전통적인 데이터 타입과 객체지향의 타입 사이에 깊은 연관성이 있기 때문이다. 객체를 타입에 따라 분류하고 그 타입에 이름을 붙이는 것은 결국 프로그램에서 사용할 새로운 데이터 타입을 선언하는 것과 같다.전통적인 데이터 타입의 개념은 객체의 타입에도 그대로 적용된다.<ol><li id="0638">어떤 객체가 어떤 타입에 속하는지를 결정하는 것은 객체가 수행하는 행동이다. 동일한 행동을 수행할 수 있다면 동일한 타입으로 분류될 수 있다.</li><li id="3077">객체의 내부적인 표현은 외부로부터 철저하게 감춰진다.</li></ol>객체의 내부 표현 방식이 다르더라도 어떤 객체들이 동일하게 행동한다면 그 객체들은 동일한 타입에 속한다. 결과적으로 동일한 책임을 수행하는 일련의 객체는 동일한 타입에 속한다고 말할 수 있다.이로서 우리는 객체를 타입으로 분류할 때 사용해야 하는 명확한 기준을 깨달았다. 어떤 객체가 타입에 속한 다른 객체와 동일한 행동을 한다면 동일한 타입으로 분류할 수 있다. 다른 행동을 한다면 그 객체들은 서로 다른 타입으로 분류돼야 한다.결론적으로 객체의 타입을 결정하는 것은 객체의 행동뿐이다.여기서 객체지향의 다형성의 의미를 알 수 있다. 동일한 행동을 하는 동일한 타입에 속한 객체는 내부의 데이터 표현 방식이 다르더라도 동일한 메시지를 수신하고 이를 처리할 수 있다. 다만 메시지를 처리하는 내부의 구체적인 방식은 다를 수 있는 것이다.그래서 훌륭한 객체지향 설계는 외부에 행동만을 제공하고 데이터는 행동 뒤로 감춰야 한다. 이 원칙을 캡슐화라고 부른다. 데이터가 캡슐의 벽을 뚫고 객체의 인터페이스를 오염시키는 순간 객체의 분류 체계는 급격히 위험에 노출되고 결과적으로 유연하지 못한 설계를 낳는다.객체를 디자인하기 위해서는 데이터가 아니라 행동을 먼저 생각해야 한다.<ol><li id="b1e8">객체가 외부에 제공해야 하는 책임을 먼저 결정하고</li><li id="ee8e">그 책임을 수행하는 데 적합한 데이터를 결정한 후 (구현)</li><li id="23b7">데이터를 책임을 수행하는 데 필요한 외부 인터페이스 뒤로 캡슐화해야 한다.</li></ol>데이터를 먼저 결정하고 객체의 책임을 결정하는 방법은 유연하지 못한 설계라는 악몽을 초래한다.<h2 id="c993">클래스</h2>타입을 구현하는 가장 보편적인 방법은 클래스를 이용하는 것이다. ‘타입을 구현한다’는 말은 클래스와 타입은 동일하지 않다는 말이다. 클래스는 단지 타입을 구현할 수 있는 여러 구현 메커니즘 중 하나일 뿐이다. JS와 같은 프로토타입 기반의 언어에는 클래스가 존재하지 않는다.객체지향 패러다임을 주도하는 대부분의 프로그래밍 언어는 클래스를 기반으로 하기 때문에 대부분의 사람들은 클래스와 타입을 동일한 개념이라고 생각한다.객체를 분류하기 위해 타입을 결정해야 하는데, 프로그래밍 언어를 이용해 타입을 구현할 수 있는 한 가지 방법이 클래스라는 사실을 아는 것 만으로도 충분하다.클래스는 타입을 구현하기 위해 프로그래밍 언어에서 제공하는 구현 메커니즘이라는 사실을 기억하자!<h2 id="0241">인터페이스</h2>일반적으로 인터페이스란 어떤 두 사물이 마주치는 경계 지점에서 서로 상호작용할 수 있게 이어주는 방법이나 장치를 의미한다. 그리고 인터페이스는 다음과 같은 세 가지 특징을 지닌다.<ol><li id="6e26">인터페이스의 사용법을 익히기만 하면 내부 구조나 동작 방식을 몰라도 쉽게 대상을 조작하거나 의사를 전달할 수 있다.</li><li id="c377">인터페이스 자체는 변경하지 않고 단순히 내부 구성이나 작동 방식만을 변경하는 것은 인터페이스 사용자에게 큰 영향을 미치지 않는다.</li><li id="763f">그 대상이 변경되더라도 동일한 인터페이스를 제공하기만 하면 사용자와의 상호작용에는 아무런 문제가 없다.</li></ol>객체지향의 세계에서 협력에 참여하는 객체들 역시 인터페이스를 통해 다른 객체와 상호작용한다. 그리고 위의 세가지 특성은 똑같이 적용된다. 다른 객체의 작동방식을 몰라도 상호작용에는 전혀 문제가 없으며 그 인터페이스만 유지된다면 다른 객체로 대체된다고 하더라도 무방하다.수신 가능한 메시지가 모여 인터페이스를 구성한다. 메시지를 먼저 결정하고 메시지를 수신하여 처리할 객체를 구현하는 과정은 인터페이스가 어떤 방식으로 결정되는지를 명확하게 보여준다.최소 인터페이스 원칙인터페이스를 최소로 유지하면 객체의 내부 동작에 대해 가능한 한 적은 정보만 외부에 노출할 수 있다.이는 까다로운 원칙처럼 들리지만 위에서 설명했던 메시지(책임)을 먼저 결정하고 객체의 구현을 나중에 생각하는 설계 방법을 따르면 자연스럽게 지킬 수 있는 원칙이다. 이 순서를 지키면 객체는 실제로 협력에 필요한 메시지 이외의 불필요한 메시지를 공용 인터페이스에 포함하지 않아도 되기 때문이다.반대로 클래스를 먼저 생각하고 메시지와 협력에 초점을 맞추지 않고 설계할 경우 불필요한 인터페이스가 외부로 노출되기 쉽다.<blockquote>유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다.- 헤라클레이토스(Heraclitus of Ephesus)</blockquote>인터페이스와 구현의 분리객체 지향 설계의 핵심은 객체를 외부에 공개되는 ‘인터페이스’와 내부에 감춰지는 ‘구현’ 이라는 두 개의 분리된 요소로 분할해 설계하는 것이다.우리는 왜 굳이 힘들고 귀찮게 인터페이스와 구현을 분리해야할까? 왜냐하면 소프트웨어는 항상 변하기 때문이다. 수많은 객체들이 물고 물리며 돌아가는 복잡한 객체지향 세계에서 어떤 한 객체가 변경 되었을 때 그 변화가 어디까지 영향을 미칠 지 판단하는 것은 곡예에 가깝다. 객체 구현의 모든 부분이 외부에 공개되어 있다면 변경에 의한 파급 효과가 세계의 구석구석까지 파고들 것이다.객체의 변경에 의한 파급효과를 감당해야하는 것은 다른 누구도 아닌 개발자인 우리다. 우리는 기계가 아닌 사람인지라 그 변화를 하나하나 추적하는 것은 불가능하다. 이런 가혹하기 그지없는 상황에서 우리가 취할 수 있는 마지막 생존 전략이 ‘인터페이스와 구현의 분리’ 라는 원칙이다.소프트웨어의 변경은 불가피하다. 하지만 그 변경이 영향을 미치는 범위를 가능한 한 최소화하자는 것이다. 객체를 인터페이스와 구현으로 분리하면 객체 변화의 영향은 적어도 구현까지만으로 좁혀진다. 해당 객체의 인터페이스를 바라 보고 있는 수많은 다른 객체들은 해당 객체의 구현부가 어떻게 바뀌든 아무런 영향을 받지 않는다. 외부 객체들이 영향을 받는 유일한 순간은 인터페이스가 수정될 때 뿐이다.인터페이스와 구현의 분리 원칙을 다시 한번 고급스럽게 정리하면 ‘메시지의 송신자와 수신자가 구체적인 구현 부분이 아니라 느슨한 인터페이스에 대해서만 결합되도록 만드는 것’ 이다.정말 아름다운 생존 전략이다.객체지향이 과거의 개발 방법에 비해 좀 더 유연하고 재사용 가능하다고 알려진 이유는 객체의 내부와 내부를 명확하게 구분하기 때문이다.객체의 외부와 내부를 명확하게 구분하라. 그러면 설계가 단순하고 유연해지며 변경하기 쉬워질 것이다.<h2 id="932c">객체의 자율성</h2><blockquote>객체가 얼마나 자율적인지가 전체적인 협력의 설계 품질을 결정한다.자율은 곧 추상이다.</blockquote>객체의 외부와 내부를 구분짓고 외부만 바라볼 수 있게 하는 것은 곧 객체를 자율적인 존재로 바라보게 한다. 객체의 내부를 어떻게 구성하는 지는 객체 자신의 자율이기 때문이다.<ul><li id="1bf1">송신자가 수신자의 세부 구현에 대해 관여하는 순간 객체의 자율성은 없어진다.</li><li id="469f">구현에 관여하지 않는다 하더라도 그 인터페이스가 너무 세세해서 하나의 책임으로 판단하기 힘들다면 그 때도 자율성은 없어진다.</li></ul>위에서 인터페이스에 대해 말했던 여러가지 원칙들이 객체의 자율성을 보장하기 위한 원칙이라고도 말해도 무방하다.객체가 자율적일수록 협력이 이해하기 쉬워지고 변경에 유연해진다. 자율적인 책임의 강력함을 느껴보자.</div></div>

Stories by allocProc on Medium

jaeyeong

객체지향 바르게 이해하기 : 클래스 & 인터페이스
조영호 님의 ‘객체지향의 사실과 오해’ 책의 일부 내용을 정리한 글입니다. 부족하다고 생각되는 부분은 내용을 덧붙였으며 제 개인적인 생각이 중간중간 첨가되어 있습니다.
현상은 복잡하다. 현실은 단순하다. 버릴 게 무엇인지 알아내라.
-리처드 파인만
추상화를 통한 복잡성 극복
현실은 있는 그대로 모두 받아들이기에는 너무나 복잡하다. 이 지독하게 복잡한 현실 속에서 우리는 우리에게 필요한 본질들만 골라낼 수 있어야한다. 이 과정을 추상화라고 부른다.
추상화의 목적은 불필요한 부분을 무시함으로써 현실에 존재하는 복잡성을 극복하는 것이다. 그래서 추상화란 현실에서 출발하되 불필요한 부분을 도려내가면서 사물의 놀라운 본질을 드러나게 하는 과정이라고 할 수 있다.
훌륭한 추상화는 목적에 부합하는 것이어야한다. 추상화가 의도된 목적이 아닌 다른 목적으로 사용된다면 안하느니만 못하다. 추상화의 수준, 이익, 가치는 목적에 의존적이다.
추상화를 사용함으로써 우리는 극도로 복잡한 이 세상을 그나마 제어 가능한 수준으로 단순화 할 수 있는 것이다.
타입
데이터 타입은 메모리 안에 저장된 데이터의 종류를 분류하는 데 사용하는 메모리 집합에 관한 메타데이터다. 데이터에 대한 분류는 암시적으로 어떤 종류의 연산이 해당 데이터에 대해 수행될 수 있는지를 결정한다.
데이터 타입에 대해 정의한 이유는 전통적인 데이터 타입과 객체지향의 타입 사이에 깊은 연관성이 있기 때문이다. 객체를 타입에 따라 분류하고 그 타입에 이름을 붙이는 것은 결국 프로그램에서 사용할 새로운 데이터 타입을 선언하는 것과 같다.
전통적인 데이터 타입의 개념은 객체의 타입에도 그대로 적용된다.
어떤 객체가 어떤 타입에 속하는지를 결정하는 것은 객체가 수행하는 행동이다. 동일한 행동을 수행할 수 있다면 동일한 타입으로 분류될 수 있다.
객체의 내부적인 표현은 외부로부터 철저하게 감춰진다.
객체의 내부 표현 방식이 다르더라도 어떤 객체들이 동일하게 행동한다면 그 객체들은 동일한 타입에 속한다. 결과적으로 동일한 책임을 수행하는 일련의 객체는 동일한 타입에 속한다고 말할 수 있다.
이로서 우리는 객체를 타입으로 분류할 때 사용해야 하는 명확한 기준을 깨달았다. 어떤 객체가 타입에 속한 다른 객체와 동일한 행동을 한다면 동일한 타입으로 분류할 수 있다. 다른 행동을 한다면 그 객체들은 서로 다른 타입으로 분류돼야 한다.
결론적으로 객체의 타입을 결정하는 것은 객체의 행동뿐이다.
여기서 객체지향의 다형성의 의미를 알 수 있다. 동일한 행동을 하는 동일한 타입에 속한 객체는 내부의 데이터 표현 방식이 다르더라도 동일한 메시지를 수신하고 이를 처리할 수 있다. 다만 메시지를 처리하는 내부의 구체적인 방식은 다를 수 있는 것이다.
그래서 훌륭한 객체지향 설계는 외부에 행동만을 제공하고 데이터는 행동 뒤로 감춰야 한다. 이 원칙을 캡슐화라고 부른다. 데이터가 캡슐의 벽을 뚫고 객체의 인터페이스를 오염시키는 순간 객체의 분류 체계는 급격히 위험에 노출되고 결과적으로 유연하지 못한 설계를 낳는다.
객체를 디자인하기 위해서는 데이터가 아니라 행동을 먼저 생각해야 한다.
객체가 외부에 제공해야 하는 책임을 먼저 결정하고
그 책임을 수행하는 데 적합한 데이터를 결정한 후 (구현)
데이터를 책임을 수행하는 데 필요한 외부 인터페이스 뒤로 캡슐화해야 한다.
데이터를 먼저 결정하고 객체의 책임을 결정하는 방법은 유연하지 못한 설계라는 악몽을 초래한다.
클래스
타입을 구현하는 가장 보편적인 방법은 클래스를 이용하는 것이다. ‘타입을 구현한다’는 말은 클래스와 타입은 동일하지 않다는 말이다. 클래스는 단지 타입을 구현할 수 있는 여러 구현 메커니즘 중 하나일 뿐이다. JS와 같은 프로토타입 기반의 언어에는 클래스가 존재하지 않는다.
객체지향 패러다임을 주도하는 대부분의 프로그래밍 언어는 클래스를 기반으로 하기 때문에 대부분의 사람들은 클래스와 타입을 동일한 개념이라고 생각한다.
객체를 분류하기 위해 타입을 결정해야 하는데, 프로그래밍 언어를 이용해 타입을 구현할 수 있는 한 가지 방법이 클래스라는 사실을 아는 것 만으로도 충분하다.
클래스는 타입을 구현하기 위해 프로그래밍 언어에서 제공하는 구현 메커니즘이라는 사실을 기억하자!
인터페이스
일반적으로 인터페이스란 어떤 두 사물이 마주치는 경계 지점에서 서로 상호작용할 수 있게 이어주는 방법이나 장치를 의미한다. 그리고 인터페이스는 다음과 같은 세 가지 특징을 지닌다.
인터페이스의 사용법을 익히기만 하면 내부 구조나 동작 방식을 몰라도 쉽게 대상을 조작하거나 의사를 전달할 수 있다.
인터페이스 자체는 변경하지 않고 단순히 내부 구성이나 작동 방식만을 변경하는 것은 인터페이스 사용자에게 큰 영향을 미치지 않는다.
그 대상이 변경되더라도 동일한 인터페이스를 제공하기만 하면 사용자와의 상호작용에는 아무런 문제가 없다.
객체지향의 세계에서 협력에 참여하는 객체들 역시 인터페이스를 통해 다른 객체와 상호작용한다. 그리고 위의 세가지 특성은 똑같이 적용된다. 다른 객체의 작동방식을 몰라도 상호작용에는 전혀 문제가 없으며 그 인터페이스만 유지된다면 다른 객체로 대체된다고 하더라도 무방하다.
수신 가능한 메시지가 모여 인터페이스를 구성한다. 메시지를 먼저 결정하고 메시지를 수신하여 처리할 객체를 구현하는 과정은 인터페이스가 어떤 방식으로 결정되는지를 명확하게 보여준다.
최소 인터페이스 원칙
인터페이스를 최소로 유지하면 객체의 내부 동작에 대해 가능한 한 적은 정보만 외부에 노출할 수 있다.
이는 까다로운 원칙처럼 들리지만 위에서 설명했던 메시지(책임)을 먼저 결정하고 객체의 구현을 나중에 생각하는 설계 방법을 따르면 자연스럽게 지킬 수 있는 원칙이다. 이 순서를 지키면 객체는 실제로 협력에 필요한 메시지 이외의 불필요한 메시지를 공용 인터페이스에 포함하지 않아도 되기 때문이다.
반대로 클래스를 먼저 생각하고 메시지와 협력에 초점을 맞추지 않고 설계할 경우 불필요한 인터페이스가 외부로 노출되기 쉽다.
유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다.
- 헤라클레이토스(Heraclitus of Ephesus)
인터페이스와 구현의 분리
객체 지향 설계의 핵심은 객체를 외부에 공개되는 ‘인터페이스’와 내부에 감춰지는 ‘구현’ 이라는 두 개의 분리된 요소로 분할해 설계하는 것이다.
우리는 왜 굳이 힘들고 귀찮게 인터페이스와 구현을 분리해야할까? 왜냐하면 소프트웨어는 항상 변하기 때문이다. 수많은 객체들이 물고 물리며 돌아가는 복잡한 객체지향 세계에서 어떤 한 객체가 변경 되었을 때 그 변화가 어디까지 영향을 미칠 지 판단하는 것은 곡예에 가깝다. 객체 구현의 모든 부분이 외부에 공개되어 있다면 변경에 의한 파급 효과가 세계의 구석구석까지 파고들 것이다.
객체의 변경에 의한 파급효과를 감당해야하는 것은 다른 누구도 아닌 개발자인 우리다. 우리는 기계가 아닌 사람인지라 그 변화를 하나하나 추적하는 것은 불가능하다. 이런 가혹하기 그지없는 상황에서 우리가 취할 수 있는 마지막 생존 전략이 ‘인터페이스와 구현의 분리’ 라는 원칙이다.
소프트웨어의 변경은 불가피하다. 하지만 그 변경이 영향을 미치는 범위를 가능한 한 최소화하자는 것이다. 객체를 인터페이스와 구현으로 분리하면 객체 변화의 영향은 적어도 구현까지만으로 좁혀진다. 해당 객체의 인터페이스를 바라 보고 있는 수많은 다른 객체들은 해당 객체의 구현부가 어떻게 바뀌든 아무런 영향을 받지 않는다. 외부 객체들이 영향을 받는 유일한 순간은 인터페이스가 수정될 때 뿐이다.
인터페이스와 구현의 분리 원칙을 다시 한번 고급스럽게 정리하면 ‘메시지의 송신자와 수신자가 구체적인 구현 부분이 아니라 느슨한 인터페이스에 대해서만 결합되도록 만드는 것’ 이다.
정말 아름다운 생존 전략이다.
객체지향이 과거의 개발 방법에 비해 좀 더 유연하고 재사용 가능하다고 알려진 이유는 객체의 내부와 내부를 명확하게 구분하기 때문이다.
객체의 외부와 내부를 명확하게 구분하라. 그러면 설계가 단순하고 유연해지며 변경하기 쉬워질 것이다.
객체의 자율성
객체가 얼마나 자율적인지가 전체적인 협력의 설계 품질을 결정한다.
자율은 곧 추상이다.
객체의 외부와 내부를 구분짓고 외부만 바라볼 수 있게 하는 것은 곧 객체를 자율적인 존재로 바라보게 한다. 객체의 내부를 어떻게 구성하는 지는 객체 자신의 자율이기 때문이다.
송신자가 수신자의 세부 구현에 대해 관여하는 순간 객체의 자율성은 없어진다.
구현에 관여하지 않는다 하더라도 그 인터페이스가 너무 세세해서 하나의 책임으로 판단하기 힘들다면 그 때도 자율성은 없어진다.
위에서 인터페이스에 대해 말했던 여러가지 원칙들이 객체의 자율성을 보장하기 위한 원칙이라고도 말해도 무방하다.
객체가 자율적일수록 협력이 이해하기 쉬워지고 변경에 유연해진다. 자율적인 책임의 강력함을 느껴보자.

객체지향 바르게 이해하기 - 클래스 & 인터페이스

댓글