개인적 감상평

결론부터 얘기하자면, 새로운 자료 타입 추가에 대한 유연성이 필요할때는 객체, 새로운 동작에 대한 유연성이 필요하면 자료 구조와 절차적인 코드를 사용하자.

굳이 OOP에 집착할 필요 없이 그때 그때 상황에 맞는 방법을 선택하면 된다.

내가 평소에 생각했던 부분을 얘기해 준 파트였다. 기껏 객체에서는 각종 필드들을 private로 선언해놓고 접근을 막아놓고서는 setter, getter 를 만들어서 접근/제어가 가능하게 만들면 의존성이 생기고 의존성이 생기면 결합도가 높아지면서 변경이 어려워진다.

그렇다면 어떻게 해야할까? 에 대한 내용으로 객체간에는 메세지만 주고받는다는 말을 설명하는 파트다.

1. 자료 추상화

단순히 변수(field)사이에 함수(method)라는 계층을 넣는다고 구현이 감춰지지는 않는다.

구현을 감추려면 추상화가 필요하다.

추상 인터페이스를 제공해 사용자가 구현을 모른채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다.

자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다.

//구체적인 Vehicle 클래스
public interface Vehicle{
	double getFuelTankCapacityInGallons();
	double getGallonsOfGasoline();
}

//추상적인 Vehicle 클래스
public interface Vehicle{
	double getPercentFuelRemaining();
}

단순히 클래스를 인터페이스화하여 공통 메소드를 뽑아내어 추상화를 할 게 아니라 인터페이스 내에서도 너무 많은 자료를 노출하는 메소드보다는 추상적인 메소드를 만들 필요가 있다.

자료/객체 차이

객체와 자료 구조 사이에는 서로의 장단점이 명확합니다.