[개발자_객체지향_디자인패턴] 객체

객체의 정의

• 객체는 데이터와 그 데이터를 조작하는 프로시저(오퍼레이션, 메서드, 함수) 로 구성된다.
• 객체의 물리적인 특성일뿐… 객체의 본질을 정의하지 않는다고 한다.

본질

• 객체는 제공하는 기능으로 정의된다.
• 내부적으로 어떤 데이터를 가지고 있는지는 중요하지 않고
  • 어떤 기능을 제공하는가 가 중요하다
• 개발자의 관점이 아니라, 클라이언트 즉, 사용자의 관점에서 바라보아야 한다

예시

• 소리 크기를 제어하는 객체가 제공하는 기능은

  1. 소리 크기 증가

  2. 소리 크기 감소

  3. 음소거

     이지, 내부적으로 어떻게 소리를 크게 증가시키고 줄이고 음소거시키는 지는 알 수가 없다.

인터페이스와 클래스

• 객체는
  • 객체가 제공하는 기능으로 정의된다.
• 객체에는
  • 기능을 정의한 오퍼레이션 이 존재한다
• 오퍼레이션에서

  1. 기능 식별 이름

  2. 파라미터 및 파라미터 타입

  3. 기능 실행 결과 값

     은 시그니처 라고한다.

• 객체가 제공하는 모든 오퍼레이션은의 집합.. 혹은 명세
  • 인터페이스 이다.

객체의 책임과 크기

• 객체가 갖은 책임을 정의한 것
  • 타입 / 인터페이스
• 구현방법
  1. 프로그램을 만들기 위한 기능 목록이 필요함.

기능 목록 정리

1. 파일의 byte 데이터를 제공함.
2. 파일에 byte 데이터를 쓴다.
3. byte 데이터를 암호화하여 새로운 byte 데이터를 생성
4. 전체 흐름을 제어.

• 어떻게 책임 분배를 하느냐에 따라

  

  • 위와 같은 그림의 3가지 구조로 나눠진다.

  • 상황에 따라 객체가 가져야 할 기능의 종류와 개수가 달라져서

    • 정답은 없다.

  • 그러나..

    객체의 책임의 크기가 작으면 작을 수록 아무래도 관리하기가 편해질 것이다.

  • 이러한 경우를 역으로 생각해보자

    

    • 한 객체에 너무 많은 기능이 존재하면
      • 객체에 정의된 오퍼레이션들이 데이터들을 공유하는 방식으로 개발이 될 텐데, 절차지향적 프로그래밍과 다를게 없어진다.
        

• 여기서 결국 파생되는 것이

  • 단일 책임 원칙 이다
  • SRP 라고 하는데 하나의 객체는 단 하나의 책임만 가져야 한다는 원칙이다.
    • 내 생각에는 순수 함수가 SRP 를 가장 잘 지킨 하나의 사례라고 생각한다
    • 그러나, 개발을 하다 보면 완벽하게 책임을 분리는 사실 힘들다. 그러나 생각 염두에 두고, 테스트 코드를 짤 경우까지 생각해서 코드를 짜야한다.