loop-study
개발 공부할래?
loop-study
전체 방문자
오늘
어제
  • 분류 전체보기 (186)
    • 목표 및 회고 (25)
    • 세미나 & 워크샵 (1)
    • 교육 및 인강 (67)
      • TDD, Clean Code with Java (5)
      • ATDD, 클린 코드 with Spring (6)
      • DDD 세레나데 (3)
      • 인프라 공방 (6)
      • 이규원의 현실 세상의 TDD (19)
      • 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 (18)
      • 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 (0)
      • 모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한 (8)
      • 코딩으로 학습하는 GoF의 디자인 패턴 (1)
      • 스프링 시큐리티 완전정복 6.x (1)
    • 서적 (62)
      • 객체지향의 사실과 오해 (1)
      • 객체지향과 디자인패턴 (7)
      • 만들면서 배우는 클린 아키텍처 (3)
      • 테스트 주도 개발로 배우는 객체 지향 설계와 실천 (1)
      • 오브젝트: 코드로 이해하는 객체지향 설계 (17)
      • 리팩토링 : 코드 구조를 체계적으로 개선하여 효율적인 리팩터링 구현하기 (0)
      • 토비의 스프링 (3)
      • 엔터프라이즈 애플리케이션 아키텍처 패턴 (9)
      • 개발자의 글쓰기 (1)
      • 소프트웨어 장인 (17)
      • Real MySQL 8.0 (2)
      • JVM 밑바닥까지 파헤치기 (0)
    • 개발 & 방법론 (29)
      • Java (13)
      • TDD (5)
      • ATDD (3)
      • DDD (6)
      • 인프라 (2)
      • SQL (0)
    • 개인이야기 (1)

블로그 메뉴

  • 홈
  • 태그
  • 방명록

공지사항

  • 백엔드 로드맵

인기 글

태그

  • 인프런
  • 추상화
  • Patterns of Enterprise Application Architecture
  • study
  • 이규원
  • 오브젝트
  • JUnit
  • fastcampus
  • 백기선
  • ATDD
  • 마틴 파울러
  • 스터디
  • nextstep
  • 스프링
  • 엔터프라이즈 애플리케이션 아키텍처 패턴
  • 김영한
  • Test Driven Development
  • 객체지향
  • DDD 세레나데
  • 모든 개발자를 위한 HTTP 웹 기본 지식
  • 테스트 주도 개발
  • 장인정신
  • 현실세상의 TDD
  • 소프트웨어 장인
  • 자바
  • java
  • 조영호
  • 넥스트스탭
  • 인프라공방
  • TDD

최근 댓글

최근 글

티스토리

hELLO · Designed By 정상우.
loop-study

개발 공부할래?

오브젝트 03_ 역할, 책임, 협력
서적/오브젝트: 코드로 이해하는 객체지향 설계

오브젝트 03_ 역할, 책임, 협력

2021. 6. 8. 20:09

역할, 책임, 협력에 대한 주제로 내용이다.

이전 챕터에서 언급되어 겹치는 내용이 많아 생략된 게 있으니 

자세한 내용이 궁금하면 오브젝트를 펼쳐보는 걸 추천드립니다.📖

 

오브젝트

역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라!객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두번째 걸음은 객체를

www.yes24.com


객체지향 패러다임의 핵심 3가지

 

- 협력(collaboration) : 기능을 구현하기 위한 상호작용

- 책임(responsibility) : 객체가 협력을 위해 수행하는 로직

- 역할(role) : 객체가 협력안에서 수행하는 책임 

 

협력

협력은 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다. 이 협력을 위한 커뮤니케이션 수단은 메시지 전송이다. 

메시지를 수신한 객체는 요청에 처리할 방법을 스스로 선택해 요청에 응답한다. 이것은 객체가 자율적인 존재라는 것을 의미한다. 

 

애플리케이션에 어떤 객체가 필요하다면 이유는 하나다. 그 객체가 어떤 협력에 참여하기 때문이다. 협력에 참여하는 것은 적절한 행동을 가진 거다. 이는 협력이 객체의 행동을 결정하고, 행동에 필요한 정보에 따라 객체의 상태를 결정한다.  

결론적으로 협력이 객체의 행동과 상태를 모두 결정하며, 설계에 필요한 문맥(context)를 제공한다. 

 

책임

협력에 참여하기 위해 객체가 수행하는 행동을 책임이라 한다. 객체의 책임은 두 가지로 분류된다.

첫째, 하는 것(doing) - 객체를 생성하거나 계산을 수행하는 등의 스스로 하는 것, 다른 객체의 행동, 활동을 제어하고 조작하는 것

둘째, 아는 것(knowing) -사적인 정보, 관련된 객체에 아는 것, 스스로 계산할 수 있는 거에 아는 것

 

객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것, 크레이그 라만

 

자율적인 객체를 만드는 기본 방법은 해당 전문가에게 책임을 할당하는 것이다. 이를 정보 전문가(INFORMATION EXPERT) 패턴이라고 부른다. 현실세상에서 문제가 생기면 해당 전문가를 찾는 것처럼 객체의 세계에서도 마찬가지며, 이처럼 적절한 객체를 찾아 책임을 할당하고 설계하는 걸 책임 주도 설계(Responsibility-Driven Design, RDD)라고 부른다.

 

* 갓 입문한 사람들이 자주 실수하는 것은 객체의 행동이 아니라 상태에 집중한다. 상태를 먼저 생각하고 구현하는 것을 데이터-주도 설계라 한다.

 

역할

객체가 협력 안에서 수행하는 책임의 집합을 역할이라 부르며, 모델링할 때에는 객체가 아니라 역할에 책임을 할당한다고 생각하는게 좋다.

역할이 중요한 이유는 유연하고 재사용 가능한 협력을 얻을 수 있기 때문이다.

이 역할을 구현하는 가장 일반적인 방법은 추상화와 인터페이스다. 협력의 관점에서 바라보면 추상화와 인터페이스는 구체 클래스들이 따라야 할 책임의 집합을 서술한 것이기 때문이다.

 

그런데 한 종류의 객체만 협력에 참여하는 상황에서도 역할이 유용할까?  

객체와 역할 둘의 차이는 무엇일까?
만약 동일한 종류의 객체가 하나의 역할을 항상 수행한다면 둘은 동일한 것이다.
하지만 어떤 협력에서 하나 이상의 객체가 동일한 책임을 수행할 수 있다면 역할은 서로 다른 방법으로 실행할 수 있는 책임의 집합이 된다. [레베카 워프스브록]

책임을 수행하는 대상이 한 종류라면 간단하게 객체로 간주한다. 여러 종류의 객체들이 참여한다면 역할이라 보면 된다.

 

'서적 > 오브젝트: 코드로 이해하는 객체지향 설계' 카테고리의 다른 글

오브젝트 05_ 책임 할당하기  (0) 2021.06.09
오브젝트 04_ 설계 품질과 트레이드 오프  (0) 2021.06.08
오브젝트 02_ 객체지향 프로그래밍  (0) 2021.06.08
오브젝트 01_ 객체, 설계  (0) 2021.06.07
오브젝트 포스팅을 시작하며  (0) 2021.06.04
    '서적/오브젝트: 코드로 이해하는 객체지향 설계' 카테고리의 다른 글
    • 오브젝트 05_ 책임 할당하기
    • 오브젝트 04_ 설계 품질과 트레이드 오프
    • 오브젝트 02_ 객체지향 프로그래밍
    • 오브젝트 01_ 객체, 설계
    loop-study
    loop-study
    오늘도 공부하자

    티스토리툴바