인프런, 객체 지향 프로그래밍 입문 - 2

객체란

객체의 핵심은 어떤 기능을 제공하느냐 이다.
객체는 기능으로 정의한다.

• 기능의 명세는 메서드를 이용해서 작성한다.
• 객체와 객체는 기능을 사용해서 연결된다.
• 객체와 객체가 상호작용하는것 메세지라고 부른다.
  (메소드 호출, exception 메세지, return 메세지 등등)

단순한 Dto(vo)는 객체라고 부를수 없다.
vo - 데이터의 getter,setter 만 있는 구조체(record 같은것)

캡슐화

• 절차 지향 프로그래밍의 경우 기능이 추가될수록 유지보수 비용이 늘어난다.
  (데이터를 여러개의 프로시저가 공유하는 방식)
• 같은 데이터를 사용하는 코드가 여러군데 흩어져있게 되고 수정도 어려워진다.

그렇다면 객체 지향은?

• 하나의 객체가 데이터를 각각 가지고 있고 다른객체가 서로의 데이터를 알수 없다.

• 프로시져를 호출하는 방식을 통해 연결됨.

• 객체가 기능을 어떻게 구현했는지 외부에 감춘다.

• 데이터 + 관련기능 묶기
  => 외부에 영향없이 기능수정 가능!

캡슐화는 어떤점이 좋아?

요구사항의 변화가 데이터 구조/사용에 변화를 일으킨다고 가정!
=> 데이터를 사용하는 코드의 많은 수정이 발생 (절차 지향 방식의 단점)

• 예를 들어 Date를 LocalDateTime으로 변경할려고 할때 모든 Date를 바꿔줘야함.

• 캡슐화를 잘하면 연쇄적인 변경 전파를 최소화한다.

• 객체 안의 기능만 수정하면 된다!

• 캡슐화된 기능(객체)을 사용하는 코드의 영향을 최소화 할 수 있다.

어떻게 캡슐화?

현재 비지니스 요구사항에 대한 이해도를 높여야 한다!
비지니스 요구사항을 작은 기능들로 바꾼것을 캡슐화의 기준점으로..

• Tell, Don't Ask
  데이터 달라하지말고 해달라고 하기!

• 예를 들어, 정회원인지 직접 비교하지않고 객체에게 책임을 넘겨서 정회원의 권한을 가졌는지 확인하는 메소드를 호출해서 확인!

• Demeter's Law

1. 메서드에서 생성한 객체의 메서드만 호출
2. 파라미터로 받은 객체의 메서드만 호출
3. 필드로 참조하는 객체의 메서드만 호출
   => 객체의 메서드를 하나만 호출하는 방식으로 바꾼다.

기능을 구현하는 코드에 영향을 최소화하면서 내부 구현을 변경할 수 있는 유연함이 큰 장점이다.