해당 글은 최범균님 - 인프런 | 객체지향 프로그래밍 입문 강의를 바탕으로 작성하였습니다.
너무 좋은 강의이니 추천드립니다.
객체
절차지향과 비용
복잡해져가는 코드
절차 지향으로 개발을 하게된다면 시간이 갈수록 복잡해지고 수정이 어려워지게 되며, 비슷한 코드가 늘어나고 복사를 시작하게 된다.
객체지향
객체 지향에서는 객체의 데이터는 프로시져(객체의 메소드라고 봐야할 듯)만 접근할 수 있도록 한다. 다른 객체에서는 해당 객체의 데이터에 바로 접근할 수 없도록 한다.
처음에는 적응하기 쉽지않겠지만, 연습만이 살길..
객체란
- 객체의 핵심 ->기능 제공
- 객체는 제공하는 기능으로 정의
기능명세
메소드를 이용해서 기능명세
- 이름, 파라미터, 결과로 구성
객체와 객체
- 객체와 객체는 기능을 사용해서 연결
- 기능 사용 = 메서드 호출
![]()
용어 메시지
객체와 객체 상화 작용을 메시지를 주고 받는다고 표현 (메소드를 호출하는 메시지, 리턴하는 메시지, 익셉션 메시지)
이것은 객체인가?
흔히 사용하는 DTO 클래스인데 데이터라고 보는게 맞을 것 같다. (구조체, VO)
기능이 붙게되면 그 때부터 객체 타이틀을 가질 수 있지 않을까 싶다.
캡슐화
캡슐화만 잘해도 굉장히 깔끔한 코드를 짤 수 있다.
- 데이터 + 관련 기능 묶기
- 객체가 기능을 어떻게 구현했는지 외부로부터 감춤
- 정보은닉 의미 포함
- 외부에 영향 없이 객체 내부 구현 변경 가능
캡슐화하지 않으면 펼쳐지는 일
처음엔 간단한 기능이였지만 추가된 요구사항으로 인해 안좋은 코드가 나왔다.
캡슐화 하면
Account 객체에서 정상회원 권한을 확인할 수 있는 기능(메소드)을 제공하고 상세한 구현을 감추게 되면 
정산회원 권한 기능 조건이 변경되더라도 내부 구현만 변경되고, 외부에서는 신경쓰지 않아도 된다.
캡슐화는 연쇄적인 변경 전파를 최소화 할 수 있다.
캡슐화를 위한 중요한 규칙
Tell, Do not Ask.
데이터를 달라고 하지말고 해달라고 하자.
위 예시처럼 회원상태 만료일자 같은 정보를 달라고 하지말고 Account객체한테 정상권한 회원인지 체크를 해달라고 하자.
Demeter’s Law
- 메소드에서 생성한 객체의 메소드만 호출
- 파라미터로 받은 객체의 메소드만 호출
- 필드로 참조하는 객체의 메소드만 호출
결론 : 메소드만 호출하라.
후기
강의를 보기전에도 알고 있는 내용이였고, 저렇게 하면 안된다는걸 알고 있었지만
잘 지키지 않았고 다시 한번 상기시킬 수 있었습니다. 안좋은 코드가 여러줄 생각 나서 리팩토링해서 캡슐화 해야겠습니다.