강의 듣고 기록한 포스트
- 클래스보다 객체
- 객체보다 메시지
- 상태보다 행동
- 메시지와 메서드의 분리는 유연한 설계의 기반이다.
이렇게 네 가지를 기억해두자
객체와 클래스
클래스보다 객체가 중요하고, 객체보다 메시지가 중요하다
객체지향 시스템과 협력
객체지향적인 시스템을 짠다는 것은 시스템을 객체의 집합으로 바라본다는 것이다. 객체는 항상 다른 객체들과 연관되어 있으며, 다른 객체에게 메시지를 전송하며 그 과정에서 시스템의 요구사항을 해결하는데, 객체지향에서는 이런 상호작용을 '협력'이라고 부른다.
객체와 클래스, 런타임과 컴파일 타임
객체지향 수업을 들으면 가장 먼저 배우는 것이 객체와 클래스이다. 보통 클래스는 붕어빵 틀, 자동차 설계도에 비유하고 객체를 붕어빵 틀로 찍어낸 붕어빵, 자동차 설계도에 따라 만들어진 자동차에 비유하는데, 객체가 클래스의 정의에 의해 실제 메모리에 할당된 인스턴스라는 것이다.
그러나 객체지향 시스템을 구현하며 고려해야 할 핵심적인 부분은 객체는 런타임, 클래스는 컴파일타임 측면의 개념이라는 것이다.
시스템을 구현할때는 두가지 측면을 함께 다룬다.
1. 런타임 : 시스템이 런타임에서 어떻게 동작하며 요구사항을 해결할지를 정의한 것. (객체)
2. 컴파일타임 : (객체가 런타임에서 의도한 대로 돌아갈 수 있도록) 클래스와 연관관계, 상속, 구현을 정의한 것. (클래스)
객체지향을 처음 배우고 코딩을 할 때는 주로 2번 컴파일 타임에 집중하게 되지만 실제로는 런타임 측면을 우선적으로 생각하고 고려하여 코딩을 해야 한다. 왜냐하면 좋은 코드란 사용자에게 좋은 가치를 제공하는 코드이기 때문이다. (=잘 돌아가는 코드) 뜬금없는 소리 같기도 하지만... 좋은 코드란 무엇인지 생각해 보면 다음 두 가지가 떠오를 것이다.
- 사용자 (사용자에게 필요한 기능, 가치를 어떻게 제공할지)
- 개발자가 읽기 쉽고 변경하기 쉬운 품질 좋은 코드 (추상화, 결합도, 응집도, 의존성, 캡슐화를 잘 고려한 멋있는 코드)
아무리 내가 개쩌는 코드를 짰다고 해도 그게 사용자가 필요한 기능을 충족하지 않는다면 의미가 없다. 물론 잘하는 개발자가 되려면 2번이 아주 아주 중요하지만 그것은 1번이 선행되었을 때의 이야기이다.
따라서 객체지향 시스템을 잘 짜려면, 기능을 구현하는 객체들의, 동적으로 변화하는 모습을 고안하고 코드설계가 이어져야 한다.
다시 말해, 동적인 모델이 정적인 모델을 주도해야 한다.
객체지향 설계
동적으로 움직이는 객체들과 그 사이 협력을 설계하는 것은, 단순한 클래스를 설계하는 일과 완전히 다른 영역이다.
책임-주도 설계
말 그대로 객체에 할당할 '책임'이 설계를 주도한다.
데이터, 메소드, 클래스보다 중요한 것이 책임이다.
- 협력을 위한 문맥 안에서
- 책임을 수행할
- 역할(객체)을 선택, 필요한 협력 요청
- 끝나면 클래스 설계 시작! (메시지를 처리할수 있는 메서드 구현
클래스가 많아지는 걸 두려워하지 말자. 클래스, 파일은 많아져도 코드의 복잡도는 줄어들 것.
CRC Card(Candidate, Responsibility, Collaborator) : 책임, 협력을 표현하기 위한 객체지향 설계 도구 (주로 학습용으로 사용된다)
메시지로부터 추상화 발견하기
객체지향의 핵심은 협력이고, 협력의 방법은 메시지이다.
클래스와 객체가 다른 것처럼 메시지와 메서드 또한 다른 개념이다. 런타임 측면의 메시지를 처리하는 컴파일타임 측면의 방법이 메서드라고 생각하면 될 것 같다
다형성과 디자인 패턴들도, '메서드와 메시지는 다르다'는 전제에서 출발한 개념이다
추상화란 '필요한 것만 남기는' 작업이다. 인터페이스를 통해 다형성을 갖게 하는 것은 'A라는 메시지로부터 반응할 수 있는지' 만 남기고, 구체적인 구현은 구현체에게 맡기는 것이다. (이들 사이에 구현도 좀 공유해야 할 것 같으면 추상 클래스를 쓰면 된다.)
메시지와 메서드의 분리는 유연한 설계의 기반이다!
애플리케이션은 클래스로 구성되지만, 메시지를 통해 정의된다.
References
Jopro 님 강의
