<div id="readability-page-1" class="page"><div><div><p><h2 id="e1ce">객체지향 바르게 이해하기 : 객체지향의 핵심</h2></p><p id="dc09">조영호 님의 ‘객체지향의 사실과 오해’ 책의 일부 내용을 정리한 글입니다. 부족하다고 생각되는 부분은 내용을 덧붙였으며 제 개인적인 생각이 중간중간 첨가되어 있습니다.</p><figure><div role="button" tabindex="0"><p><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"></p></div></figure></div><div><blockquote><p id="765f"><em>어떤 객체도 섬이 아니다.</em></p></blockquote><h2 id="89ea">협력하는 객체들</h2><p id="86cb">만약 실행 중인 애플리케이션의 내부를 눈으로 직접 볼 수 있다면 그 안에는 쉴 새 없이 메시지를 주고받으며 협력하는 객체가 존재한다는 것을 확인할 수 있을 것이다.</p><p id="0e44">그 협력을 조금 더 자세히 들여다 보면 객체는 다른 객체의 명령에 복종하는 것이 아니라 요청에 응답할 뿐이다. 어떤 방식으로 응답할지는 <strong>객체 스스로 판단하고 결정</strong>한다.</p><p id="3e4f">그리고 이 협력에는 오직 한 가지 의사소통 수단만이 존재한다. 이를 <strong>메시지</strong>라고 한다. 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 객체가 수신된 <strong>메시지를 처리하는 방법을 메서드</strong>라고 부른다.</p><p id="72de">메시지와 메서드의 분리는 객체의 협력에 참여하는 객체들 간의 자율성을 증진시킨다. <strong>외부의 요청이 무엇인지를 표현하는 메시지</strong>와 <strong>요청을 처리하기 위한 구체적인 방법인 메서드를 분리</strong>하는 것은 객체의 자율성을 높이는 핵심 메커니즘이다. 이것은 캡슐화(encapsulation)라는 개념과도 깊이 관련돼 있다.</p></div><div><h2 id="0e86">객체지향의 핵심은 클래스가 아니다.</h2><p id="cf74">클래스가 객체지향 프로그래밍 언어의 관점에서 매우 중요한 구성요소인 것은 분명하지만 객체지향의 핵심을 이루는 중심 개념이라고 말하기에는 무리가 있다.</p><p id="5ba7">객체지향을 올바르게 이해하기 위해선 객체지향을 바라보는 관점을 코드를 담는 클래스의 관점에서 메시지를 주고받는 객체의 관점으로 전환하는 것이다. <strong>중요한 것은</strong> ‘<strong>어떤 클래스가 필요한가</strong>’ <strong>가 아니라</strong> ‘<strong>어떤 객체들이 어떤 메시지를 주고받으며 협력하는가</strong>’ <strong>이다</strong>. 클래스는 객체들의 협력 관계를 코드로 옮기는 도구에 불과하다.</p><p id="5548">클래스는 협력에 참여하는 객체를 만드는 데 필요한 구현 메커니즘일 뿐이다. 객체지향의 중심에는 클래스가 아니라 겍체가 위치하며, 중요한 것은 클래스들의 정적인 관계가 아니라 메시지를 주고받는 객체들의 동적인 관계다.</p><p id="b8df"><strong>객체지향은 객체를 지향하는 것이지 클래스를 지향하는 것이 아니다.</strong></p></div><div><h2 id="a122">객체의 상태와 행동</h2><p id="0ede">객체는 자율적인 존재다. 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다. 이런 객체지향의 세계에서 외부 객체가 간접적으로 다른 객체의 상태를 변경하거나 조회할 수 있는 방법이 필요하다.</p><p id="a45e">행동은 다른 객체로 하여금 간접적으로 객체 자신의 상태를 변경하는 것을 가능하게 한다. 객체는 스스로의 행동에 의해서만 상태가 변경되는 것을 보장함으로써 객체의 자율성을 유지한다.</p><p id="82a7">현실 세계의 객체와 객체지향 세계의 객체 사이에는 중요한 차이점이 있다. 현실 속에서 앨리스는 스스로 음료를 마시는 능동적인 존재지만 음료는 스스로 아무것도 할 수 없는 수동적인 존재다. 현실 세계라면 음료의 양을 줄여 음료의 상태를 변경시키는 주체는 음료를 마신 앨리스가 될 것이다.</p><p id="7e4b">그러나 객체지향의 세계에서 객체의 상태를 변경시키는 주체는 객체 자신이어야 한다. 즉, 음료 객체의 양을 줄이는 것은 음료 자신이어야 한다. 앨리스는 직접적으로 음료의 상태를 변경할 수 없다. 앨리스는 단지 음료 객체에게 음료를 마셨다는 메시지를 전달할 뿐이고, 음료의 양을 줄이는 것은 전적으로 음료 객체 스스로의 몫이다.</p><p id="a7a1">이를 그림으로 나타내면 다음과 같다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/0*INnaK-GE5dBuB54l.png" width="700" height="323" 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"></p></div></figure><p id="5ad2">앨리스에게 전달되는 drinkBeverage() 메시지와 음료에게 전달되는 drunken(quantity) 메시지를 보고 음료의 양이 줄어든다는 상태 변경을 예상할 수 있겠는가?</p><p id="3200">이것이 캡슐화가 의미하는 것이다. <strong>객체가 외부에 노출하는 것은 행동뿐이며, 상태를 캡슐 안에 감춰둔 채 외부로 노출하지 않는다.</strong></p><p id="7b8b"><strong>메시지를 전달하는 송신자는 수신 객체의 상태가 변경된다는 사실을 알 수 없어야 한다.</strong></p><h2 id="ad9d">행동이 상태를 결정한다</h2><p id="aece">설계는 상태가 아니라 행동에 초점을 맞춰야한다. 객체는 다른 객체와 협력하기 위해 존재하고 행동은 객체가 협력에 참여할 수 있는 유일한 수단이다. 따라서 어떠한 객체가 어떤 상황에 적합한지를 결정하는 것은 그 객체의 상태가 아니라 행동이다. <strong>우리가 애플리케이션 안에서 어떤 행동을 원하느냐가 어떤 객체가 적합한지를 결정한다.</strong></p><p id="03a4">행동을 결정한 후에야 행동에 필요한 정보가 무엇인지를 고려하게 되며 이 과정에서 필요한 상태가 결정된다. 따라서 먼저 객체의 행동을 결정하고 그 후에 행동에 적절한 상태를 선택하게 된다.</p><p id="84eb">협력 안에서 객체의 행동은 결국 객체가 협력에 참여하면서 완수해야 하는 책임을 의미한다. 따라서 <strong>어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 한다.</strong></p></div><div><h2 id="f656">객체지향은 현실 세계의 모방이 아니다</h2><p id="99e9">객체지향 패러다임의 목적은 현실 세계를 모방하는 것이 아니라 <strong>현실 세계를 기반으로 새로운 세계를 창조하는 것</strong>이다. 현실 세계에서는 사람이 직접 주문 금액을 계산하지만 소프트웨어 세계에서는 주문 객체가 자신의 금액을 계산한다.</p><p id="22ff">현실 속에서는 수동적인 물체가 소프트웨어 객체로 표현될 때에는 능동적으로 변한다. 이것은 의인화에 가깝다. 현실 세계에서 컵은 스스로 자신에게 담긴 음료의 양을 줄이거나 늘릴 수 없다. <strong>소프트웨어 세계에서 모든 객체는 능동적이고 자율적이다.</strong></p><p id="9b6f">객체지향 세계의 거리는 현실 속의 객체보다 더 많은 특징과 능력을 보유한 객체들로 넘쳐난다.</p><p id="fe15">객체지향 설계자로서 우리의 목적은 현실을 모방하는 것이 아니다. 현실을 닮아야 한다는 어떤 제약이나 구속도 없다. 다만 우리가 창조한 객체의 특성을 남들에게 상기시키기 쉽게 하기 위해 현실 속의 객체의 이름을 이용할 수는 있겠지만 말이다. 이 또한 쉽지 않다면 현실을 깔끔하게 무시하고 우리만의 새로운 세계를 창조해보자!</p></div><div><h2 id="d6df">책임</h2><blockquote><p id="14e9">명확한 책임이 애플리케이션의 미래를 결정짓는다.</p></blockquote><p id="7d96">어떤 객체가 어떤 요청에 대해 응답해 줄 수 있거나, <strong>적절한 행동을 할 의무</strong>가 있는 경우 해당 객체가 책임을 가진다고 말한다.</p><p id="289d">책임은 객체에 의해 정의되는 응집도 있는 행위의 집합으로, 객체가 알아야 하는 정보와 객체가 수행할 수 있는 행위에 대해 개략적으로 서술한 문장이다.</p><p id="3d75">즉, 책임은 객체의 외부에 제공해 줄 수 있는 정보와 제공해줄 수 있는 서비스의 목록이다. 따라서 책임은 객체의 공용 인터페이스(public interface)를 구성한다.</p><p id="691a">책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소다. <strong>객체지향 설계의 예술은 적절한 객체에게 적절한 책임을 할당하는 데 있다.</strong></p><blockquote><p id="0f48">책임을 얼마나 잘게 혹은 얼마나 크게 나눠야 할지도 굉장히 어려운 문제로 보인다.</p></blockquote><h2 id="97b3">역할</h2><p id="63cb"><strong>역할은 책임의 집합</strong>을 간단하게 정의한 것이다. 그래서 역할은 협력 내에서 한 객체를 다른 객체로 대체할 수 있음을 나타내는 일종의 표식이다. 이말은 곧, 하나의 역할을 대체할 수 있는 객체는 동일한 메시지를 이해할 수 있는 객체라는 말이다.</p><p id="ecdf">동일한 역할을 수행하는 객체들이 동일한 메시지를 수신할 수 있기 때문에 동일한 책임을 수행할 수 있다는 것은 매우 중요한 개념이다. 이를 제대로 이해해야만 객체지향이 제공하는 많은 장점을 누릴 수 있다.</p><p id="6de1">역할의 개념을 사용하면 유사한 협력을 하나의 인터페이스로 추상화할 수 있다. 위에서 책임은 객체의 공용 인터페이스를 구성한다고 했다. 그 이유가 여기에 있다. 유사한 협력을 역할로 추상화 한 것이 공용 인터페이스이다.</p><p id="7bb8">인터페이스로 협력이 유연해지며 다양한 객체들이 동일한 협력에 참여할 수 있기 때문에 재사용성이 높아진다.</p><blockquote><p id="0971">객체지향의 핵심은 클래스를 어떻게 구현할 것인가가 아니라 객체가 협력 안에서 어떤 책임을 갖고 어떤 역할을 수행할 것인지를 결정하는 것이다.</p></blockquote></div><div><h2 id="2e99">테스트 주도 개발 (Test-Driven-Development)</h2><p id="d82e">테스트 주도 개발(이하 TDD)는 좋은 객체지향 설계에 대한 깊은 고민에서 나온 개발 방법론이다. 객체지향에 대한 이해가 부족한 상태에서 TDD 의 개념을 접하면 잘 와닿지가 않는다. TDD 는 개발 속도를 느리게 하는 그저 번거로운 장치로 보이기 쉽다. 하지만 객체지향의 핵심을 이해하고 <strong>책임과 협력의 관점에서 객체를 바라보고 TDD 를 이해</strong>해보자. TDD 의 진짜 의미를 이해할 수 있을 것이다.</p><p id="78f9">TDD 의 기본적인 틀은 테스트 코드를 작성하고, 테스트를 통과하는 코드를 작성한 후 리팩토링하는 과정이다. <strong>이 간단한 흐름은 우리가 객체의 책임을 먼저 생각하고 구현을 그 뒤에 하도록 강제한다.</strong> 우리가 앞서 말했던 좋은 객체지향 설계를 강제하는 것이다!</p><p id="f41f">테스트를 작성하기 위해 객체의 메서드를 호출하고 반환값을 검증하는 것은 객체가 수행해야 하는 책임에 관해 생각한 것이다. 그 과정에서 stub, mock 객체를 사용하는 것은 객체와 협력하는 대상에 대해 고민한 결과를 코드로 표현한 것이다.</p><p id="0d03"><strong>객체의 역할, 책임, 협력에 집중하고 객체지향의 원칙을 적용하려는 깊이 있는 고민과 노력을 통해서만 TDD 의 혜택을 누릴 수 있다.</strong></p></div></div></div>

Stories by allocProc on Medium

jaeyeong

객체지향 바르게 이해하기 : 객체지향의 핵심
조영호 님의 ‘객체지향의 사실과 오해’ 책의 일부 내용을 정리한 글입니다. 부족하다고 생각되는 부분은 내용을 덧붙였으며 제 개인적인 생각이 중간중간 첨가되어 있습니다.
어떤 객체도 섬이 아니다.
협력하는 객체들
만약 실행 중인 애플리케이션의 내부를 눈으로 직접 볼 수 있다면 그 안에는 쉴 새 없이 메시지를 주고받으며 협력하는 객체가 존재한다는 것을 확인할 수 있을 것이다.
그 협력을 조금 더 자세히 들여다 보면 객체는 다른 객체의 명령에 복종하는 것이 아니라 요청에 응답할 뿐이다. 어떤 방식으로 응답할지는 객체 스스로 판단하고 결정한다.
그리고 이 협력에는 오직 한 가지 의사소통 수단만이 존재한다. 이를 메시지라고 한다. 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 객체가 수신된 메시지를 처리하는 방법을 메서드라고 부른다.
메시지와 메서드의 분리는 객체의 협력에 참여하는 객체들 간의 자율성을 증진시킨다. 외부의 요청이 무엇인지를 표현하는 메시지와 요청을 처리하기 위한 구체적인 방법인 메서드를 분리하는 것은 객체의 자율성을 높이는 핵심 메커니즘이다. 이것은 캡슐화(encapsulation)라는 개념과도 깊이 관련돼 있다.
객체지향의 핵심은 클래스가 아니다.
클래스가 객체지향 프로그래밍 언어의 관점에서 매우 중요한 구성요소인 것은 분명하지만 객체지향의 핵심을 이루는 중심 개념이라고 말하기에는 무리가 있다.
객체지향을 올바르게 이해하기 위해선 객체지향을 바라보는 관점을 코드를 담는 클래스의 관점에서 메시지를 주고받는 객체의 관점으로 전환하는 것이다. 중요한 것은 ‘어떤 클래스가 필요한가’ 가 아니라 ‘어떤 객체들이 어떤 메시지를 주고받으며 협력하는가’ 이다. 클래스는 객체들의 협력 관계를 코드로 옮기는 도구에 불과하다.
클래스는 협력에 참여하는 객체를 만드는 데 필요한 구현 메커니즘일 뿐이다. 객체지향의 중심에는 클래스가 아니라 겍체가 위치하며, 중요한 것은 클래스들의 정적인 관계가 아니라 메시지를 주고받는 객체들의 동적인 관계다.
객체지향은 객체를 지향하는 것이지 클래스를 지향하는 것이 아니다.
객체의 상태와 행동
객체는 자율적인 존재다. 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다. 이런 객체지향의 세계에서 외부 객체가 간접적으로 다른 객체의 상태를 변경하거나 조회할 수 있는 방법이 필요하다.
행동은 다른 객체로 하여금 간접적으로 객체 자신의 상태를 변경하는 것을 가능하게 한다. 객체는 스스로의 행동에 의해서만 상태가 변경되는 것을 보장함으로써 객체의 자율성을 유지한다.
현실 세계의 객체와 객체지향 세계의 객체 사이에는 중요한 차이점이 있다. 현실 속에서 앨리스는 스스로 음료를 마시는 능동적인 존재지만 음료는 스스로 아무것도 할 수 없는 수동적인 존재다. 현실 세계라면 음료의 양을 줄여 음료의 상태를 변경시키는 주체는 음료를 마신 앨리스가 될 것이다.
그러나 객체지향의 세계에서 객체의 상태를 변경시키는 주체는 객체 자신이어야 한다. 즉, 음료 객체의 양을 줄이는 것은 음료 자신이어야 한다. 앨리스는 직접적으로 음료의 상태를 변경할 수 없다. 앨리스는 단지 음료 객체에게 음료를 마셨다는 메시지를 전달할 뿐이고, 음료의 양을 줄이는 것은 전적으로 음료 객체 스스로의 몫이다.
이를 그림으로 나타내면 다음과 같다.
앨리스에게 전달되는 drinkBeverage() 메시지와 음료에게 전달되는 drunken(quantity) 메시지를 보고 음료의 양이 줄어든다는 상태 변경을 예상할 수 있겠는가?
이것이 캡슐화가 의미하는 것이다. 객체가 외부에 노출하는 것은 행동뿐이며, 상태를 캡슐 안에 감춰둔 채 외부로 노출하지 않는다.
메시지를 전달하는 송신자는 수신 객체의 상태가 변경된다는 사실을 알 수 없어야 한다.
행동이 상태를 결정한다
설계는 상태가 아니라 행동에 초점을 맞춰야한다. 객체는 다른 객체와 협력하기 위해 존재하고 행동은 객체가 협력에 참여할 수 있는 유일한 수단이다. 따라서 어떠한 객체가 어떤 상황에 적합한지를 결정하는 것은 그 객체의 상태가 아니라 행동이다. 우리가 애플리케이션 안에서 어떤 행동을 원하느냐가 어떤 객체가 적합한지를 결정한다.
행동을 결정한 후에야 행동에 필요한 정보가 무엇인지를 고려하게 되며 이 과정에서 필요한 상태가 결정된다. 따라서 먼저 객체의 행동을 결정하고 그 후에 행동에 적절한 상태를 선택하게 된다.
협력 안에서 객체의 행동은 결국 객체가 협력에 참여하면서 완수해야 하는 책임을 의미한다. 따라서 어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 한다.
객체지향은 현실 세계의 모방이 아니다
객체지향 패러다임의 목적은 현실 세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것이다. 현실 세계에서는 사람이 직접 주문 금액을 계산하지만 소프트웨어 세계에서는 주문 객체가 자신의 금액을 계산한다.
현실 속에서는 수동적인 물체가 소프트웨어 객체로 표현될 때에는 능동적으로 변한다. 이것은 의인화에 가깝다. 현실 세계에서 컵은 스스로 자신에게 담긴 음료의 양을 줄이거나 늘릴 수 없다. 소프트웨어 세계에서 모든 객체는 능동적이고 자율적이다.
객체지향 세계의 거리는 현실 속의 객체보다 더 많은 특징과 능력을 보유한 객체들로 넘쳐난다.
객체지향 설계자로서 우리의 목적은 현실을 모방하는 것이 아니다. 현실을 닮아야 한다는 어떤 제약이나 구속도 없다. 다만 우리가 창조한 객체의 특성을 남들에게 상기시키기 쉽게 하기 위해 현실 속의 객체의 이름을 이용할 수는 있겠지만 말이다. 이 또한 쉽지 않다면 현실을 깔끔하게 무시하고 우리만의 새로운 세계를 창조해보자!
책임
명확한 책임이 애플리케이션의 미래를 결정짓는다.
어떤 객체가 어떤 요청에 대해 응답해 줄 수 있거나, 적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 가진다고 말한다.
책임은 객체에 의해 정의되는 응집도 있는 행위의 집합으로, 객체가 알아야 하는 정보와 객체가 수행할 수 있는 행위에 대해 개략적으로 서술한 문장이다.
즉, 책임은 객체의 외부에 제공해 줄 수 있는 정보와 제공해줄 수 있는 서비스의 목록이다. 따라서 책임은 객체의 공용 인터페이스(public interface)를 구성한다.
책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소다. 객체지향 설계의 예술은 적절한 객체에게 적절한 책임을 할당하는 데 있다.
책임을 얼마나 잘게 혹은 얼마나 크게 나눠야 할지도 굉장히 어려운 문제로 보인다.
역할
역할은 책임의 집합을 간단하게 정의한 것이다. 그래서 역할은 협력 내에서 한 객체를 다른 객체로 대체할 수 있음을 나타내는 일종의 표식이다. 이말은 곧, 하나의 역할을 대체할 수 있는 객체는 동일한 메시지를 이해할 수 있는 객체라는 말이다.
동일한 역할을 수행하는 객체들이 동일한 메시지를 수신할 수 있기 때문에 동일한 책임을 수행할 수 있다는 것은 매우 중요한 개념이다. 이를 제대로 이해해야만 객체지향이 제공하는 많은 장점을 누릴 수 있다.
역할의 개념을 사용하면 유사한 협력을 하나의 인터페이스로 추상화할 수 있다. 위에서 책임은 객체의 공용 인터페이스를 구성한다고 했다. 그 이유가 여기에 있다. 유사한 협력을 역할로 추상화 한 것이 공용 인터페이스이다.
인터페이스로 협력이 유연해지며 다양한 객체들이 동일한 협력에 참여할 수 있기 때문에 재사용성이 높아진다.
객체지향의 핵심은 클래스를 어떻게 구현할 것인가가 아니라 객체가 협력 안에서 어떤 책임을 갖고 어떤 역할을 수행할 것인지를 결정하는 것이다.
테스트 주도 개발 (Test-Driven-Development)
테스트 주도 개발(이하 TDD)는 좋은 객체지향 설계에 대한 깊은 고민에서 나온 개발 방법론이다. 객체지향에 대한 이해가 부족한 상태에서 TDD 의 개념을 접하면 잘 와닿지가 않는다. TDD 는 개발 속도를 느리게 하는 그저 번거로운 장치로 보이기 쉽다. 하지만 객체지향의 핵심을 이해하고 책임과 협력의 관점에서 객체를 바라보고 TDD 를 이해해보자. TDD 의 진짜 의미를 이해할 수 있을 것이다.
TDD 의 기본적인 틀은 테스트 코드를 작성하고, 테스트를 통과하는 코드를 작성한 후 리팩토링하는 과정이다. 이 간단한 흐름은 우리가 객체의 책임을 먼저 생각하고 구현을 그 뒤에 하도록 강제한다. 우리가 앞서 말했던 좋은 객체지향 설계를 강제하는 것이다!
테스트를 작성하기 위해 객체의 메서드를 호출하고 반환값을 검증하는 것은 객체가 수행해야 하는 책임에 관해 생각한 것이다. 그 과정에서 stub, mock 객체를 사용하는 것은 객체와 협력하는 대상에 대해 고민한 결과를 코드로 표현한 것이다.
객체의 역할, 책임, 협력에 집중하고 객체지향의 원칙을 적용하려는 깊이 있는 고민과 노력을 통해서만 TDD 의 혜택을 누릴 수 있다.

객체지향 바르게 이해하기 — 객체지향의 핵심

댓글