[오브젝트] ch02 객체지향 프로그래밍

🖋️ 후기

객체지향적으로 코딩을 한다고 하면 우선 클래스를 생각하고 동작이 무엇이고 그에 필요한 데이터는 무엇인가부터 생각했었습니다.

객체지향은 객체를 지향하라는 것. 그렇기에 클래스보다 객체에 초점을 맞추어야 진정한 객체지향 패러다임으로의 전환을 얻을 수 있다는 것이 인상 깊습니다.

1. 어떤 객체가 필요한지 고민, 어떤 객체들이 어떤 상태와 행동을 가지는지 먼저 결정한다.
2. 객체는 기능을 구현하기 위해 협력하는 공동체의 일원

객체지향에서 캡슐화가 중요하며 재사용성이 중요합니다

상속을 통해 중복되는 부분은 부모클래스로 받아와서 재사용성을 높일 수 있습니다.

하지만 상속의 경우 자식 클래스에서 부모클래스에 접근할 수 있고 부모클래스가 변동될 때 자식클래스도 바뀌기 쉽다는 점과 부모, 자식 클래스의 관계를 컴파일 시점에 결정하기에 런타임에서는 객체의 종류 변경이 불가능하기에 유연하지 않다는 점이 있습니다.

그런 문제를 해결하기 위해 합성(compose)을 사용하고 합성의 경우 인터페이스와 인스턴스를 연결하여 설계가 보다 유연해지게 처리될 수 있었습니다. 재사용성은 가져가고 하지만 결합도는 낮기에 의존성이 낮아지는 장점이 있습니다.

그럼에도 상속의 장점은 다형성을 쓸 수 있다는 점이 됩니다.

 

이번주부터 책에 나온 내용을 은행 도메인을 가정하고 적용해서 구현하기로 하였기에 그 이전보다는 좀 더 주의 깊게 요구사항과 구현사항을 보게 되었습니다.

실제로 있을 법한 사례를 기반으로 영화 할인에 대해 할인 정책, 할인 조건들이 나와서 흥미로웠으며 내가 구현한다면 저렇게 여러 객체로 나누지 않을 텐데 여럿으로 쪼개서 표현하는 부분에서도 배울 수 있어 좋았고 어떻게 해야 저렇게 객체를 나눌 수 있을까에 대해 생각해 볼 수 있었습니다.

코드의 일관성을 위해 할인을 하지 않는 경우 NoneDiscountPolicy 클래스를 만들어서 할인이 되던 경우에 호출하는 방식과 동일하게 처리할 수 있게 한 점이 좋은 팁이라 싶었습니다.

 

결국 객체지향 프로그래밍도 트레이드오프가 있다.

가독성을 추구할 것인가? 유연성을 추구할 것인가? 의 선택이 될 수 있으며 구현이라는 것은 결국 트레이드오프이며 작은 코드이더라도 그렇게 구현한 명확한 이유가 있어야 한다 합니다.

코딩을 하다 보면 이전에 했던 관성에 의해서 작성되는 코드들도 더러 생기고 코드를 다시 읽거나 다른이에게 코드리뷰하지 않는 이상 작성한 코드에 대해 문제점을 못 느끼기도 하였는데 그런 점에서 저 문장이 기억에 남습니다.