[우테코 권장도서] 객체지향 사실과 오해 3장

중간에 블로그에 올리는걸 까먹어서 순서가 뒤죽박죽이 되었다

3장 타입과 추상화

추상화라는것이 참 어려운 이야기 같은데 지하철역 지도를 통해서 쉽게 설명하고있다.

추상화라는것은 두가지 측면에서 볼 수 있다고 한다.

1.분류를 위해 공통점을 취하고 차이점을 버리는 일반화를 통해 단순화 시키는 작업이라고 하는데

-> 한마디로 그냥 공통적인것들에 집중하여 분류 기준을 가져오는것이라고 생각한다 이때 사소한 차이점들은 과감히 버린다.

(클래스든 인터페이스든 타입을 만드는 방법들에서는 공통적인 행위를 분리해내는것이 포인트라고 생각한다.)

2.중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거 단순하게 만드는것이다.

이것도 공통점을 취하는 과정에서 차이점들은 버려야하는데 이것들을 필요에 맞게 과감하게 버리라는 뜻으로 해석했다.

이때 주의사항으로 현재 도메인에 맞는 특성이 있기 때문에 무조건적으로 버리는것이 아니라

그 도메인의 특성에 맞는 공통점을 취하고 차이점을 버려야한다.

즉 용도에 맞지않는 추상화는 적절하지 못하다.

지하철 노선도에서 정확한 예시가 있는데 실제 지도상에 지하철 역같은것은 위치가 맞지 않는다.

하지만 도메인에 맞는 용도로 추상화되었기 때문에 실제로 정확한 지도보다 더 직관적이다.

이런 도메인에 맞는 추상화 과정은 참어렵겠지만 추상화의 가장 주를 두고 노력해야하는 부분이 아닌가 싶다.

그룹으로 나누어 단순화하기

앨리스 이야기에 다양한 등장인물들을 트럼프로 퉁쳐버린다.

왜냐하면 분류기준에서는 하트니 발이달렸느니 그런것은 딱히 필요가 없기 때문이다

이렇게 단순화를 통해서 복잡성을 통제하는 것이다.(이런 부분에서 남는것들은 도메인상 중요한 것들일 것이다.)

개념이라는 이라는 개념이 등장하는데

개념은 분류를 위한 수단이다.

개념은 3가지 요소를 지닌다

심볼: 개념을 가르키는 이름

내연: 완전한 정의 내연의 의미를 통해서 분류를 할수 있다.

외연: 개념에 속하는 객체의 집합

이렇게 나뉘는데 어느것을 분류하기 위한 기준점을 말로 잘풀어서 설명한것같다.

즉 개념은 분류를 위해 존재한다.

분류는 객체지향의 가장 중요한 개념중 하나라고 한다.

객체를 적절한 개념(도메인 상황에 맞는)을 도입하여 나눈다면 유지보수가 용이하고 유연해 진다고 한다.

결국 잘 나눈 개념과 분류를 통해서 다형성을 적절히 사용한다면 코드를 쉽게 갈아끼우고 유지보수력이 올라갈것이라고 생각했다.

타입

타입은 개념이랑 일치한다.

개념에서 내연을 통해서 분류했듯

타입은 어떤행동을 갖는가가 분류할수 있는 기준이다.

데이터 타입을 이용해서 열심히 설명하는데 결국 타입을 결정하는 것은 상태가 아니라 행동이라는것이 주요 내용이다.

그리고 그행동을 수행하는것은 외부로 부터 철저하게 감춰내야한다.-> 이런게 캡슐화이다.

캡슐화를 통해서 안에서 어떻게 돌아가는지는 객체 오마카세로 구성하는것이 객체의 자율성을 높일수 있다.

즉 상태가 어쩌구 저쩌구 해봐야 상태는 타입을 나타내는데 1도 상관없고 결국 행동의 구성만이 타입을 결정한다.

그래서 내부가 어떻게 돌아가던 행동에서 요구하는 사항을 만족할수 있다면(나는 자꾸 행동의 집합 타입이 인터페이스라고 생각된다. 물론 상태값이 없는 상태를 강요하지도 않는) 서로 갈아 끼우는데 전혀 문제가 없을것이다.

그래서 같은 타입이더라도 내부 상태값은 제각기 다를수 있고 구현하는 방식또한 제각기 다를수 있다.

-> 다형성이라는 키워드가 나오는데

동일안 요청에 대해 서로 다른 방식으로 응답할수 있는 능력이라고 한다.

근데 나는 이렇게 해석했다 타입이 같고 그걸 구현하는건 제각기 다르더라도(우리가 보는 실체가 달라서 햇갈리게 하겠지만) 분명 요구사항을 다 만족하기 때문에 필요한 지점에서 갈아끼울수 있다는 능력이라고.

그리고 이런 행동만이 타입에 고려대상이라는것은 외부에 데이터를 감춰야 한다는것이다.(캡슐화)

-> 즉 괜히 다른 데이터 값을 외부로 광고하여 같은 분류를 가진 애들을 다르게 보이게 하지 말라 이런 의미라고 생각한다(헷갈리게 하지말자)

캡슐화가 깨지면 유연하지 못하게 되는 설계를 낳는다.

Ex) 상태를 직접 꺼내서쓰는데 인터페이스(행동)은 상태를 강제하지 않기 때문에 다른 객체라고 그상태를 갖는다는 보장이없다.

그럼 못갈아끼운다 다형성도 캡슐화도 꺠진것이다.

계층

일반화 특수화 관계

계층 분류의 기준인 개념의 내연이 곂칠수 있을것이다.

이때 한쪽이 한쪽의 부분집합이라면 내연이 적은쪽이 일반화 내연이 많은쪽이 특수화 일것이다.

일반화는 슈퍼타입 특수화는 서브타입으로 대치되며

특수화된 타입은 일반화 타입이 할수 있는 행동을 동일하게 수행할수 있어야한다.

그래서 여기서 리스코프 치환원칙이 나온다.-> 상속받으면 그 상속의 슈퍼타입객체에 완벽히 대체될수있어야한다.

정적모델 동적모델

정적모델은 객체를 시간순서에 맞춰 변화하는 상태에따라 죄다 분류해놓으면 그것을 행동과 상태를 통해서 상태가 어떻게 변할수있는지 시간에 대한것만 뺴놓은것이고

동적모델은 그냥 객체의 흐름 그자체이다.객체가 살아움직이는 상태에서 구체적으로 어떤상태를 가지는가(현재 객체의 상태)를 표현하는것을 객체의 스냅샷, 객체지향 모델링을 위한 표준언어인 UML에서는 객체 다이어그램 이라고 한다고 한다.

뭐 정적인거 동적인거 프로그래밍하면서 다 고려할요소이고 알아야한다고 한다.

클래스

클래스는 그냥 타입을 구현할수있는 한가지 방법일뿐 타입이랑 대치되지않는다. 그리고 자바스크립트같은 프로토타입 기반언어는 클래스가 애초에 없다.

클래스를 타입과 햇갈리지말고 클래스 중요하지만 오히려 클래스가 너무 고평가 받다보니 이책에서는 계속 깐다.

클래스는 타입 + 코드를 재사용하는 용도 또한 수행하므로 정확한 대치는 아니라고 한다.

나는 타입은 인터페이스가 더 적절한 대치라고 생각하긴한다.