이 글은 오브젝트 책 2장을 읽고 정리한 내용입니다.
1장에서는 객체지향적 코딩이 필요한 이유를 공부했었다. 2장은 이러한 객체 지향적 코딩을 하기 위해서 어떤 것을 고려해야하는지를 정리해놓았다.
객체지향을 위한 코딩을 진행할 때는
- 어떤 클래스가 필요한지를 고민하기전에 어떤 객체들이 필요한지 고민하라
- 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야한다.
이 두가지를 고려해야한다고 강조한다.
먼저 1번 문장을 이해해보자.
객체 고려하기
어떤 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야를 도메인이라고 한다. 이러한 도메인의 요구사항과 프로그램을 객체라는 관점에서 바라 볼 수 있기 때문에 객체를 구성하는 개념들이 프로그램의 객체와 클래스로 매끄럽게 이어질 수 있다.
그렇다면 객체는 무엇일까?
객체는
1. 상태와 행동을 가지고 있다.
2. 자율적인 존재이다.
를 만족하는 클래스라고 생각이 된다.
다만 객체는 상태라는 것을 가지고 있고 이들은 자신의 행동에 의해서만 바뀔 수 있게 되야한다. 이러한 것을 캡슐화라고 한다. 또한 객체는 상태라는 것이 다른 객체로 부터 방해를 받기 않게 하기 위해 접근제어자라는 것을 사용할 수 있다.
이러한 캡슐화와 접근제어자는 객체를 2가지 부분으로 나누게 된다. 인터페이스와 구현이 그것이다.
인터페이스는 외부에서도 접근 가능한 부분을 이야기한다. 구현 부분은 이와 반대로 내부에서만 접근 가능한 부분을 이야기한다.
인터페이스를 통해 외부 객체가 자신의 객체에 대해 공개된 행동을 하도록 요청을 할 수 있는데 이를 메시지 수신이라고 한다.
또한 이러한 요청을 받은 객체는 자신의 메소드에 따라 응답을 처리하고 반환하게 된다.
이렇게 내부와 외부에서 접근 가능한 영역을 나누게 되면 협력을 할 때 다른 사용자의 코드에 의해 자신의 객체의 상태가 바뀔 걱정을 안해도 된다. 따라서 다른 객체와의 의사소통은 여전히 인터페이스로 인해 가능해지지만 다른 외부의 간섭에 대해 자율적인 존재가 되는 것이다.
협력하기
위에서도 짧게 언급했지만 객체간의 협력은 메시지 수신이라는 것으로 연결되어 있다. 즉 인터페이스를 활용해서 여러 객체가 협력을 하게 된다.
하지만 단일 객체가 어떤 공통적인 속성을 가진 객체와 협력을 하기위해서는 어떻게 해야할까? 공통적인 속성의 모든 객체를 인스턴스화 시킬 수도 없을 것이다. 이럴 때 사용하는 것이 상속과 다형성이다.
먼저 예시를 보고 이야기를 해보자
영화에 따라 할인 정책을 다양한 것을 사용할 수 있다. 그럼 Movie를 생성할 때마다 조건문을 부여해서 할인정책을 선정해야할 것이다. 하지만 그렇게 되면 각 할인정책과 Movie간의 결합도가 증가하고 이에 따라 코드 수정이 어려워질 것이다.
추상화
이 시점에서 필요한 것은 할인정책이라는 공통적인 속성과의 소통이다. 그런 속성을 가진 클래스가 DiscountPolicy인것이다. 그리고 그러한 추상적인 속성을 구체화한 것이 AmountPolicy와 PercentDiscountPolicy이다. 이를 추상화라고 이야기 할 수 있다.
이러한 추상화는 다음과 같이 2가지 장점을 가질 수 있게 된다.
- 요구사항의 정책을 높은 수준에서 서술할 수 있다는 것 추상화를 사용하면 세부적인 내용을 무시한 채 상위 정책을 쉽고 간단하게 표현할 수 있다. 즉, 애플리케이션에서 객체의 협력 흐름을 기술한다고 이야기 할 수 있을 것이다.
- 설계가 좀 더 유연해진다. 추상화는 설계가 구체적인 상황에 결합되는 것을 방지하기 때문에 기존에 요구사항이 바뀌거나 확장이 필요한 경우 유연하게 확장이 가능해진다.
자 여기까지는 개념적인 이야기 이고 그럼 어떻게 추상화를 코드상에서 구현을 할까?
상속과 다형성
먼저 상속을 이용해서 부모 클래스와 다른 부분만 추가해서 새로운 클래스를 쉽고 빠르게 만드는 방법을 차이에 의한 프로그래밍이라고 한다.
이러한 상속은 2가지로 분류될 수 있는데 구현 상속과 인터페이스 상속이다. 구현상속은 메서드나 인스턴스 변수를 재사용하기 위해 상속을 사용하는 것이고 인터페이스 상속은 부모클래스의 추상적인 개념을 자식 클래스에 상속 시켜 다른 객체와의 협력에 있어서 공통적인 속성을 통해 협력하기 위한 것이다.
이렇게 인터페이스 상속을 해서 같은 속성이지만 다르게 반응하는 여러 클래스를 만들어 놓을 수 있다. 따라서 이들은 같은 메시지를 받고 타입에 따라 반응이 달라지게 될 것이다. 이를 다형성이라고 부른다.
위의 예시로 다시 돌아와서 보면 Movice는 DiscountPolicy라는 추상클래스와 소통을 한다. 그럼 언제 이러한 DiscountPolicy를 상속받아서 구현한 자식 클래스 중에 어떤 것이 Movice와 소통할지 어떻게 정해질까?
여기서 추상화의 단점이 존재한다. 추상화는 코드상의 의존성이랑 실행 시점에서의 의존성이 다르다. 즉, 실행시점에 어떤 클래스와 Movie가 소통할지 결정된다는 것이다. 따라서 지나친 추상화는 오히려 디버깅에 어려움을 줄 수 있다.
이 글은 오브젝트 책으로 부터 내용을 정리한 글입니다.
더 자세한 내용은 아래 오브젝트 책을 참고해주세요.
http://www.yes24.com/Product/Goods/74219491
긴 글 읽어주셔서 감사합니다.
틀린 부분이 있으면 댓글을 달아주시면 감사하겠습니다.
📧 : may3210@g.skku.edu
'Computer Science > 객체지향' 카테고리의 다른 글
[오브젝트] 역할 책임 협력 (0) | 2022.02.28 |
---|---|
[오브젝트] 절차지향과 객체지향 (0) | 2022.02.21 |