001. 협력하는 객체들의 공동체

시너지를 생각하라. 전체는 부분의 합보다 크다

 

객체지향소프트웨어 - 실세계의 투영

객체 - 현실 세계의 사물에 대한 추상화

 

객체의 직접적으로 대응하는 실세계의 사물을 찾기 어려움

 

객체지향의 목표는 실세계를 모방하는 것이 아님, 오히려 새로운 세계를 창조하는 것의 의미가 더 큼.

 

역할 / 책임 / 협력

책에는 커피 공화국의 예시를 들었지만, 지금 와플대학에서 이 글을 작성하고 있어서 비유를 좀 바꿔봐야겠다(공부가 되겠지?)

 

손님으로 와플대학 키오스크에 주문을 했다.

키오스크는 주문을 받았고 주문번호를 생성하며, 점원에게 어떤 주문이 들어왔는지를 전달한다.

점원은 키오스크로부터 어떤 주문이 들어왔는지 확인하고, 주문을 제조한다.

점원이 주문 제조가 끝나면 호출 시스템을 통해 키오스크가 생성한 주문번호를 호출한다.

손님인 나는 호출 시스템의 호출에 따라, 수령처로 가서 와플을 받는다. (맛있게 먹으면서 글을 쓴다)

 

역할

손님(나) - 주문하고, 결제하고, 영수증을 수령하고, 제조가 완료되면 제조된 상품을 수령하고 섭취한다

키오스크 - 주문 가능한 메뉴를 출력하고, 결제를 수행하고, 주문번호를 생성하고, 점원에게 주문정보를 전달한다.

점원 - 키오스크로부터 전달받은 주문 내역과 호출번호를 보고, 주문을 제조하고 주문 제조가 완료되면 호출 시스템에 호출번호를 전달하여

손님(나)에게 주문 제조가 완료되었다는 사실을 통지한다.

 

와플 주문이라는 협력에 참여하는 모든 사물들은 와플이 정확하게 주문되고 주문된 제품이 정확하게 제조. 전달될 수 있도록 책임을 다한다.

 

요청과 응답으로 구성된 협력

협력의 성공은 특정한 역할을 맡은 개인이 얼마나 요청을 성실하게 이행하는가에 달려있다.

 

위의 비유에서처럼, 손님은 키오스크에게 주문에 대한 요청을 보내고 키오스크는 들어온 주문에 대한 제조요청을 점원에게 보내고

점원은 다시 호출 시스템에 주문한 손님을 호출할 것을 요청하고 호출시스템은 손님에게 제조한 제품을 수령할것을 요청한다.

 

응답은 반대방향으로, 키오스크는 손님에게 주문이 성공적으로 완료되었다 응답하고,

호출 시스템은 호출이 정상적으로 되었음을 점원에게 응답한다.

 

역할과 책임

역할은 의미적으로 책임이라는 개념을 내포한다.

 

역할의 특징은 다음과 같다

 

- 여러 사람이 동일한 역할을 수행할 수 있다.

 

- 역할은 대체 가능성을 의미한다(Sustainable)

 

- 책임을 수행하는 방법은 자율적으로 선택할 수 있다

요청을 받은 사물은 요청을 처리하는 방법을 자유롭게 선택할 수 있음(Abstract, Interface와 Implements 간의 관계로 보면 되는것같다)

동일한 요청을 받더라도, 역할을 수행하는 사람들마다 다른 방식으로 요청을 수행할 수 있다는 뜻 (Polymorphism - 다형성)

 

- 한 사람이 동시에 여러가지 역할을 수행할 수 있다.

(SRP? -> 할 수 있는데 하지 말라는 뜻인듯, 객체지향의 개념과 다르게 저건 유지보수나 어떤 객체지향이 좋은가를 말하는거라 다른듯함)

 

 

역할 책임 협력

사람/사물 - 객체

사람/사물이 보내는 요청 - 메세지

사람/사물이 요청을 처리하는 방식 - 메서드

 

일상생활에서 목표 - 사람들의 협력을 통해 달성 - 더 작은 책임으로 분할되고 책임을 수행할 수 있는 적절한 역할을 가진 자에 의해 수행

(Divide And Conquer?) -> 협력내에서는 여러 객체(사물)가 연쇄적인 요청과 응답을 통해 하나의 목표를 이룸

 

 

워드 커닝험 / 켄트 벡 : 어떤 객체도 섬이 아니다 => 모든 객체는 역할과 책임을 다하는 동시에 서로 상호작용한다.

 

사람 : 공통의 목표를 달성하기 위해 상호 협력

객체 : 애플리케이션의 기능 구현을 위해 상호 협력 (시스템을 구성하는 단위로 해석해도 될듯)

 

객체지향의 설계 : 객체에게 적절하게 책임을 부여하는 것 (즉, 책임이 곧 객체지향 설계의 품질을 좌우함)

책임이 불분명하고 모호한 객체는 결국 애플리케이션의 미래 또한 불분명하게 만든다(코드 가독성 저하를 의미한다고 해석)

 

역할 - 유연하고 재사용 가능한 협력 관계를 구축하는데 중요한 설계 요소

 

협력 속에 사는 객체

객체지향 - 패러다임의 중심에 객체가 있는 것

1. 객체는 충분히 협력적이어야 한다. (모든것을 스스로 처리하려고 하는 전지전능한 객체는 지양하자)

다른 객체의 명령에 오직 복종하는 것도 아니고, 혼자 전부 처리하려고 하는 객체도 아니다.

어떤 방식으로 응답하고 요청할지는 객체 스스로 판단하고 결정할 수 있어야한다.

 

https://progyun.tistory.com/107

009. 4회차 미션

 

이전에 스터디를 하면서 과제를 할 때, 어떤 객체에 어느 속성을 부여해야하는가?

어디까지 책임을 지게 해야 하는가에 대한 고민을 한번 토로했었고, 재성님께서 좋은 피드백을 주셨었다.

(이 책을 추천해주셔서 지금 이 책을 읽으면서 정리하고 있습니다!)

 

이 글을 읽고 어떻게 보면 내가 너무 Library 클래스에 모든 책임을 집중시키려고 했던건 아닌가 하는 생각이 든다.

책의 글쓴이께서 앞부분에 서술하신것이, 대부분의 객체지향을 설명할때 이해하기 쉽도록 현실세계와 결부하여 설명하는 경우가 많은데

사실 실무적인 관점으로 보면 좀 어긋나는 부분이 많다고 하시는데, 이것도 어쩌면 그 중 하나일지도 모르겠다.

 

 

2. 객체는 충분히 "자율적"이어야 한다.

자기 스스로의 원칙에 따라 어떤 일을하거나 자기 스스로를 통제하여 절제하는 것 (즉, 자율적인 존재가 되는 것)

 

상태와 행동을 함께 지닌 자율적인 객체

객체 : 상태와 행동을 함께 지닌 실체라고 정의

객체가 협력하는 과정 속에서 스스로 자율적인 존재로 남기 위해서는 필요한 행동과 상태를 함께 지니고 있어야 함.

 

자율성 - 내부와 외부를 확실하게 구분하는 것으로 부터 나옴.

사적인 부분은 아예 스스로 관리하고 밖에서 간섭할 수 없도록 해야함 / 허락된 부분을 통해서만 소통.

 

다른 객체는 의사소통하는 객체가 무엇을 수행하는지는 알 수 있지만, 어떻게 수행하는지는 알 수 없어야 함(의존 X)

 

-> 유지보수와 재사용에 용이

 

- 정의를 알게되니 어떤 메서드를 어디에 놔야하는지도 생각할 수 있게 된다.

https://progyun.tistory.com/109

011. 5회차 [과제] 객체상속, 메서드 다중정의, 재정의

다음 고민했던 과제에서 Info에 있는 다음 코드는 사실 처음에는 ExamProgram에 있었다

public double getAverageScore() {
        return (IntStream.of(this.getHtmlScore(), this.getCssScore(),
            this.getJsScore()).average()).orElseThrow(IllegalAccessError::new);
    }

(추후 추가 작성)

메서드와 자율성

객체는 다른 객체와 협력하기 위해 메세지를 전송

 

수신된 메세지를 이해할 수 있는지 여부를 먼저 판단

자신만의 방법에 따라 메세지를 처리 -> 이 처리하는 방식을 메서드라고 함.

 

메서드는 클래스 안에 포함된 함수 또는 프로시저(?)를 통해 구현

 

출처 : ChatGPT (성능 확실하네)

객체지향 프로그래밍 언어는 메세지를 수신한 객체가 실행 시간에 메서드를 선택할 수 있다는 점이 다른 프로그래밍 언어와 차별화된 점임.