객체지향 이란?

• 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법
• 자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체
• 객체는 시스템의 행위를 구현하기 위해 다른객체와 협력, 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다.
• 객체는 다른 객체와 협력하기 위해 메세지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는데 적합한 메서드를 자율적으로 선택한다.
• 메시지는 곧 책임이다.

역할, 책임, 협력

• 객체는 협력을 위해 특정할 역할을 맡고 적합한 책임을 수행한다.
• 여기서 역할은 대체 가능성을 의미한다.
• 각 객체는 책임을 수행하는 방법을 자율적으로 선택 하고 다른 객체와 협력한다.
• 객체는 다른 객체가 '무엇(what)'을 수행하는지는 알수 있지만 '어떻게(how)' 수행하는지에 대해서는 알 수 없다.
• 객체지향 세계에서는 오직 '메시지' 라는 의사소통만이 존재한다.

협력

• 협력은 한 사람이 다른 사람에게 도움을 요청할 때 시작된다.
• 요청 받은 사람은 응답을 한다.
• 요청과 응답은 협력에 참여하는 객체가 수행할 책임을 정의하게 된다.

책임

• 적절한 행동을 한 의무가 있는 경우에 해당 객체가 책임을 가진다고 할 수 있다.

• 책임은 주로 하는것(doing)과 아는것(knowing)으로 분류된다.

  • 하는 것

    • 객체를 생성하거나 계산을 하는 등의 스스로 하는것
    • 다른 객체의 행동을 시작시키는 것
    • 다른 객체의 활동을 제어하고 조절하는 것

  • 아는 것

    • 개인적인 정보에 관해 아는 것
    • 관련된 객체에 관해 아는 것
    • 자신이 유도하거나 계산할 수 있는 것에 관해 아는것
• 즉, 책임은 객체의 외부에 제공해 줄 수 있는 정보(아는것의 측면)와 외부에 제공해 줄 수 있는 서비스(하는 것의 측면)의 목록이고 이 책임은 객체의 공용 인터페이스를 구성하게 된다.

역할

• 어떤 객체가 수행하는 책임의 집합은 객체가 협력 안에서 수행하는 역할을 암시한다.
• 역할은 재사용이 가능하고 유연한 객체지향 설계를 낳는 매우 중요한 구성요소이다.
• 역할은 협력 내에서 다른 객체로 대체할 수 있음을 나타내는 일종의 표식이다. 즉, "이 자리는 나 대신 이 역할을 수행할수 있다면 누구라도 대체할 수 있어" 라고 말하는것과 같다.
• 역할은 객체지향 설계의 "단순성" , "유연성" , "재사용성" 을 뒷바침 하는 핵심 개념이다.
• 역할을 사용하면 협력을 추상화 시킬 수 있다.

타입과 추상화

추상화

• 추상화란 실제의 사물에서 자신이 원하는 특성만 취하고 필요 없는 부분을 추려 핵심만 표현하는 행위이다.
• 추상화는 어떤양상, 세부사항, 구조를 좀 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법.
• 구체적인 사물 간의 공통점은 취하고 차이점을 버리자.
• 중요한 부분을 강조하기 위해 불필요한 세부사항을 제거해 단순화 하자.
• 추상화 매커니즘의 종류로는 '분류와 인스턴스화' , '일반화와 특수화' , '집합과 분해' 가 있다.

분류의 인스턴스화

• '분류와 인스턴스화' 의 예로는 자동차 , 새 , 나무 등이 되겠다.
• '분류' 라는것은 세상에 존재하는 객체에 개념을 적용하는 과정이다. 객체의 특정한 개념을 나타내는 집합의 구성 요소로 포함시킨다.
• 사람들은 이 '분류'를 통해 개별 현상을 하나의 개념으로 다루고 이때 수많은 객별적인 현상들을 '객체' , '하나의 개념' 을 '타입' 이라고 한다.

일반화와 특수화

• 일반화와 특수화는 계층 관계를 이루고 있다. 'is-a' 관계.

집합과 분해

• 복잡성은 '계층'의 형태를 띤다.
• 단순한 형태로부터 복잡한 형태로 진화하는 데 걸리는 시간은 그 사이에 존재하는 '안정적인 형태'의 수와 분포에 의존한다.
• 안정적인 형태의 부분으로부터 전체를 구축하는 행위를 집합이라고 한다.
• 반대로 전체를 부분으로 분할하는 행위를 분해라고 한다.
• 집합의 가치는 불필요한 세부사항을 배제하고 큰 그림에서 대상을 다룰 수 있게 한다. 즉, 불필요한 부분을 추상화 한다.
• 합성 관계는 부분을 전체 안에 캡슐화함으로써 인지 과부하를 방지한다. 즉, 어느 한 객체 안에 아예 포함시키는 것이다.
• 연관 관계는 단순한 물리적 통로가 존재한다는 사실만 나타낸다. 연관관계로 연결된 두 객체는 생명주기와 관련된 어떤테약도 부과하지 않는다. 즉, 독립적이다.
• 합성관계가 내부에 포함된 객체들의 존재를 감춤으로써 내부 구조를 추상화 하는 것처럼 패키지는 내부에 포함된 클래스들을 감춤으로써 시스템의 구조를 추상화 한다.

개념

• 공통점을 기반으로 객체를 묶기 위한 그릇을 개념(concept) 라고 한다.
• 개념의 관점 : 심볼(symbol), 내연(intension), 외연(extension)
• symbol : 개념을 가리키는 이름이나 명칭
• intension : 개념의 완전한 정의 이 의미로 인해 객체가 개념에 속하는지 여부를 확인할 수 있다.
• extension : 개념에 속하는 모든 객체의 집합.
• 개념을 이용해 객체의 복잡성을 극복하고 분류하자.

타입

• 타입은 개념이다.
• 타입은 공통점을 기반으로 객체들을 묶기 위한 틀이다.
• 어떤 객체의 타입이 자동차라고 말할 수 있으려면 자동차가 무엇인지에 대한 명확한 정의가 필요하다.
• 타입은 개념과 마찬가지로 심볼, 내연, 외연을 이용해 서술할 수 있으며 타입에 속하는 객체 역시 타입의 인스턴스라고 한다.
• '타입이 없다' 라는 말은 메모리 안의 데이터를 다룰 수 있는 단 하나의 타입만이 존재한다는 것을 의미. 사실 메모리 세상엔 타입이라는 질서가 없다.
• 타입이 없는 체계에서는 메모리 안의 값이 어떤 의미인지 말할수 있는 사람은 없다. '1001001'만 보고 숫자인지 문자열인지 해석할 수 있는가?
• 데이터 타입이란 메모리 안의 데이터에 특정한 의미를 부여한 것이다. 사람들은 자신이 다뤄야 하는 데이터의 용도와 행동에 따라 그것들을 분류한것이다.
• 타입 시스템의 목적은 메모리 안의 모든 데이터가 비트열로 보임으로 그 혼란을 막기 위함이다. 메미로 안에 저장된 0과 1에 대해서 수행 가능한 작업과 불가능 작업을 구분함으로써 데이터가 잘못 사용되는것을 방지한다.

객체와 타입

• 객체를 타입에 따라 분류하고 그 타입에 이름을 붙이는 것은 결국 프로그램에서 사용할 새로운 데이터 타입을 선언하는것과 같다.
• 객체가 어떤 타입에 속하는지는 객체가 수행하는 행동이다. 동일한 행동을 수행할 수 있다면 그 객체들은 동일한 타입으로 분류될 수 있다.
• 내부적인 표현은 외부로부터 철저하게 감춰진다.
• 객체를 결정하는 것은 행동이다. 데이터는 단지 행동을 따를 뿐이다.
• 객체가 외부에 제공해야 하는 행동을 먼저 생각하자.
• 객체는 시시각각 변할 수 있기 때문에 타입을 사용하면 시간과 무관한 정적인 모습으로 다룰수 있게 해준다. 즉, 타입은 추상화이다. 객체의 상태 변경이라는 복잡성을 단순화 할수 있는 방법이다.

일반화/특수화 ( 슈퍼타입/서브타입 )

• 일반화 / 특수화의 적절한 예는 고양이과 동물 / 사자 를 들수 있을 것이다.
• 일반화 / 특수화 관계를 결정짓는 것은 객체의 상태가 아닌 행동이다.
• 여기서 일반적인 타입은 특수적인 타입의 모든 행동중에서 일부 행동만 가진다.
• 특수한 타입이란 일반적인 타입이 가진 모든 타입을 포함하지만 거기에 자신만의 행동을 추가하는 타입을 가리킨다.

클래스

• 클래스는 단지 타입을 구현할 수 있는 여러 구현 메커니즘 중 하나이다.
• 자바스크립트의 경우에는 프로토타입 기반의 언어라 클래스가 존재하지 않는다.

상태, 행동, 식별자

상태

• 상태를 이용하면 과거의 행동 이력을 설명하지 않아도 행동의 결과를 쉽게 예측 하고 설명할 수 있다.
• 즉, 상태는 특정시점에 객체가 가지고 있는 정보의 집합이다.
• 객체는 상태를 스스로 관리하는 자율적인 존재다.
• 상태를 외부에 노출시키지 않고 캡슐화 하는것은 객체의 자율성을 높인다.

행동

• 객체의 상태를 변경하는 것은 객체의 자발적인 행동이다.
• 객체의 행동은 상태에 영향을 받는다.
• 행동이란 외보의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동
• 행동의 결과로는 객체의 자신의 상태를 변경하거나 다른 객체에 메시지를 전달할 수 있다.
• 행동은 다른객체와의 협력에 참여하므로 외부에 가시적이다.
• drinkBeverage() -> 나 객체 -> drunken(quantity) -> 음료객체

식별자

• 서로를 구별할 수 있는 특정한 프로퍼티가 식별자라고 한다.
• 값의 상태는 변하지 않기에 immutable state를 가진다.
• 객체의 상태는 행동에 의해 변할수 있기에 mutable state라고 한다.
• 동등성 : 상태를 기반으로 비교 , 동일성: 식별자를 기반으로 비교
• 객체의 경우 상태가 가변적이기에 상태 변경에 독립적인 별도의 식별자를 이용해서 두 인스턴스를 비교할 수 있다.

은유와 객체

• 현실속에서는 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다. 예를 들면 소프트웨어에선 상품이 가격계산을 스스로 수행할수 있다는 것이다.
• 객체를 창조할때 현실 객체를 모방하려 하지말고 현실 속의 객체에 대한 은유를 쓰자. 은유란 하나의 의미를 다른 것을 이용해 전달한다는 의미를 가지고 있다.
• "A라는 객체는 전화기 같아요" 라고 했을때 A라는 객체는 전화를 걸 수 있다는 사실을 알 수 있다.
• 은유 관계에 있는 실제 객체의 이름을 소프트웨어 객체의 이름으로 사용하면 표현적 차이를 줄여 소프트웨어의 구조를 쉽게 예측할 수 있다. 그래서 유지보수가 용이한 소프트웨어를 만들 수 있다.

객체지향 설계 기법

책임-주도 설계

• 객체지향 설계란 app의 기능을 구현하기 위한 협력 관계를 고안하고, 협력에 필요한 역할과 책임을 식별한 후 이를 수행할 수 있는 적절한 객체를 식별해 나가는 과정.
• 이 설계는 객체의 책임을 중심으로 시스템을 국축하는 설계 방법
• 시스템은 더 작은 규모의 책임으로 분할되고 각 책임은 책임을 수행할 적절한 객체에게 할당된다. 객체가 책임을 수행하는 도중에 필요하다면 적절한 객체를 찾아 필요한 작업을 요청한다. 만약 책임을 여러 종류의 객체가 수행할 수 있다면 협력자는 객체가 아니라 추상적인 역할로 대체된다.
• 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.
• 시스템 책임을 더 작은 책임으로 나눈다.
• 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
• 객체가 책임을 수행하는 중에 다른객체의 도움이 필요한 경우 이를 책임질 적절한 객체를 찾는다.
• 해당 객체에게 책임을 할당함으로써 두 객체가 협력하게 된다.

디자인패턴

• 반복적으로 발생하는 문제와 그 문제에 대한 해법의 쌍
• 패턴으로 해결하는 문제가 무엇인지를 명확하게 파악하고 패턴을 적용할수 있는 상황과 적용할 수 없는 상황을 인지하자.
• COMPOSITE 패턴은 전체와 부분을 하나의 단위로 추상화해야하는 경우에 사용된다.
• 위 예로는 사용자 관점에서 대상이 파일인지 폴더인지 상관없이 파일의 경로를 바꿀수도 있지만 폴더의 경로를 바꾸게 되면 그 안에 있는 파일까지도 한번에 변경 할수도 있어야 한다. 사용자는 단지 대상을 선택한 후 경로를 바꾸기만 하면 된다.
• 즉, 메시지 수신자가 부분(파일) 인지 전체(폴더) 인지에 상관 없이 동일한 메시지(경로변경)을 이용해 동일한 방식으로 대상과 상호작용하고 싶을때 이용한다.

책임과 메시지

자율적인 책임

• 자율성 그것은 자기 스스로의 원칙에 따라 어떤 일을 하거나 자신을 통제해서 절제하는 성질이나 특성이다.
• 객체가 어떤 행동을 하는 유일한 이유는 다른 객체로부터 요청을 수신했기 때문이다.
• 자율적인 책임의 특징은 객체가 '어떻게 (how)' 해야 하는가가 아니라 '무엇 (what)' 을 해야 하는가를 설명한다는 것이다.

메시지와 메서드

• 객체의 행동을 유발하는 행위를 가리켜 메시지-전송 이라고 한다.
• 모자장수.증언하라(어제,왕국);
• 객체는 메시지를 수신하면 먼저 해당 메시지를 처리할 수 있는지 여부를 확인한다. 그 후에 메시지를 처리할 방법인 메서드를 선택하게 된다.
• 메시지는 '어떻게' 수행될 것인지는 명시하지 않는다.

다형성

• 다형성이란 서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것을 의미한다.
• 서로 다른 타입에 속하는 객체들이 동일한 메시지를 쉰할 경우 서로 다른 메서드를 이용해 메시지를 처리할 수 있는 메커니즘을 가리킨다.
• 서로 다른 객체들이 다형성을 만족시킨다는 것은 객체들이 동일한 책임을 공유한다는 것을 의미한다.
• 메시지를 보내는 객체는 수신하는 객체를 할 필요가 없다. 단지 보내는 메시지를 이해하면 해당 역할을 수행할 수 있는 수신자라면 어떤 누구와도 협력이 가능하다.

what/who 사이클

• 먼저 '어떤 행위(what)'을 수행할 것인지를 결정한 후에 '누가(who)' 그 행위를 수행할 것인지를 결정해야 한다는 것.
• 수신 가능한 메시지가 모여 객체의 인터페이스를 구성한다.
• 참여할 객체를 결정하기 전에 협력에 필요한 메시지를 먼저 결정한다.
• 메시지를 결정하기 전까지 객체에 관해 고민하지 말아야 한다.
• '묻지 말고 시켜라' 단지 송신자는 수신자가 어떤 객체인지는 모르지만 자신이 전송한 메시지를 잘 처리할 것이라는 것을 믿고 메시지를 전송한다.

객체 인터페이스

• 인터페이스는 사용법만 익히면 내부 구조를 몰라도 쉽게 대상을 조작하거나 의사를 전달할 수 있다.
• 인터페이스 자체는 변경하지 않고 단순히 내부 구성이나 작동방식을 바꾸는 것은 인터페이스 사용자에게 어떤 영향도 미치지 않는다.
• 대상이 변경되더라도 동일한 인터페이스를 제공하기만 하면 아무런 문제 없이 상호작용 할 수 있다.
• 객체의 외부에 공개된 인터페이스를 공용 인터페이스라고 한다.
• 객체지향 패러다임 안에서 자기 스스로에게 뭔가를 요청하는 경우에도 메시지를 전송해야 한다.
• 외부에서 사용할 필요가 없는 인터페이스는 최대한 노출하지 말자.

구현

• 객체를 구성하지만 공용 인터페이스에 포함되지 않는 모든 것이 구현에 포함된다.
• 객체는 상태와 행동을 지닌다 이 부분들을 구성하는 코드 자체는 객체 외부에 노출되는 공용 인터페이스의 일부는 아니기 때문에 객체의 구현부분에 포함된다.
• 이 부분을 수정하더라도 객체 외부에 영향을 미쳐서는 안된다. 객체 외부에 영향을 미치는 변경은 객체의 공용 인터페이스를 수정할 때뿐이다.

캡슐화

• 상태와 행위의 캡슐화 , 외부에 반드시 접근해야만 하는 행위만 골라 공용 인터페이스를 통해 노출한다.
• 데이터 캡슐화는 인터페이스와 구현을 분리하기 위한 전제조건이다.
• 객체가 자율적이기 위해서는 자기 자신의 상태를 스스로 관리할 수 있어야 하기 때문에 데이터 캡슐화는 자율적인 객체를 만들기 위한 전제 조건이기도 하다.
• 외부에 제공해야 할 필요가 있는 메시지만을 객체의 공용 인터페이스에 포함시키고 개인적인 비밀은 공용 인터페이스의 뒤에 감춤으로써 외부의 불필요한 공격과 간섭으로 부터 내부 상태를 격리할 수 있다.

책임과 메시지의 정리

• 자율적인 책임은 협력을 단순하게 만든다.
• 자율적인 책임은 모자 장수의 외부와 내부를 명확하게 분리한다.
• 책임이 자율적인 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.
• 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.
• 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.

객체지향의 예를 살펴보자

커피 전문점

• 커피 전문점에서 주문하기

  • 메뉴판( 4개의 메뉴 ) : 4개의 메뉴는 4개의 객체를 말하고 메뉴판은 그 객체를 포함하는 객체라고 볼수있다.
  • 손님은 메뉴판을 보고 바리스타에게 메뉴를 주문한다.
  • 바리스타는 커피를 제조한다. 아메리카노 , 카푸치노, 카라멜 마키아또, 에스프레소
  • 바리스타는 자율적으로 커피를 제조하는 객체로 볼 수 있으며 커피 역시 자신만의 경계를 가지므로 객체로 볼 수 있다.
  • 도메인은 손님객체 , 메뉴항목객체 , 메뉴판객체 , 바리스타 객체 , 커피객체로 구성된 작은 세상
  • 동적인 객체를 정적인 타입으로 추상화해서 복잡성을 낮추자.
  • 손님타입 , 메뉴판타입, 메뉴 항목타입, 바리스타 타입 , 커피타입으로 나눈다.
  • 메뉴 항목이 메뉴판에 포함된다. ( 합성 )
  • 손님은 메뉴판을 알아야 하니 서로를 알고만 있으면 된다. ( 연관 )
  • 바리스타는 커피를 제조해야하므로 커피를 알고있어야 한다. ( 연관 )
  • 손님은 바리스타를 알아야 한다. ( 연관 )

• 커피 전문점 설계

  • 협력을 찾자. 메시지가 객체를 선택하게 해야한다. 메시지를 먼저 선택하고 그 후에 메시지를 수신하기에 적절한 객체를 선택해야 한다는 것이다. 이제 미시지를 수신할 객체는 메시지를 처리할 책임을 맡게 되고 객체가 수신하는 메시지는 객체가 외부에 제공하는 공용 인터페이스에 표현된다.
  • 어떤 객체가 커피를 주문할 책임을 져야 하는가?? 커피를 주문하라 ( 메뉴이름 ) 이 메시지에 대한 책임은 손님이다.
  • 손님은 '메뉴 항목을 찾아라' 라는 새로운 메시지를 보낸다. 메뉴이름 이라는 인자도 함께 보낸다.
  • 현실 메뉴판은 스스로 메뉴를 찾지 않지만 소프트웨어는 능동적이고 자율적인 존재다. 따라서 설계자는 무생물을 생물처럼 '의인화' 해야한다.
  • 손님은 메뉴항목을 얻었으니 이제 커피를 제조해달라고 요청할 수 있다.

• 인터페이스 정리하기

  • 손님 : 제품을 주문하라
  • 메뉴판 : 메뉴 항목을 찾아라
  • 바리스타 : 커피를 제조하라
  • 커피 : 생성하라

    class Customer{
        constructor(){}
  
        order: function(menuName){}
    }
  
    class MenuItem{}
  
    class Menu{
        constructor(){}
  
        choose: function(name){}
    }
  
    class barista{
        constructor(){}
  
        makeCoffee: function(menuItem){}
    }
    
    class Coffee{
        constructor(menuItem){
  
        }
        
    }

• 구현하기

  • 고객은 메뉴와 바리스타 객체에 접근을 해야한다.
  • 메뉴는 menuName에 해당하는 MenuItem을 찾아야 하는 책임이 있다. 따라서 Menu 가 MenuItem을 관리하고 있어야 한다.
  • 바리스타는 MenuItem을 이용해서 커피를 제조한다.

  class Customer{
        constructor(){}
  
        order: function(menuName, menu, barista){
            let menuItem = menu.choose(menuName);
            let coffee = barista.makeCoffee(menuItem);
  
            //...
        }
    }
  
  class Menu{
    constructor(items){
        this._items = items || [];
        this._itemsLength = items.length();
    }
  
    choose: function(name){
        for(let i = itemLength; i > 0; i--){
            if(this._items[i].getName() === name){
                
                return this._items[i];
            }
        }
    }
  }
  
  class barista{
        constructor(){}
  
        makeCoffee: function(menuItem){
            let coffee = new Coffee(menuItem);
            return coffee;
        }
    }
  
  class Coffee{
      constructor(opts){
        this._name = opts.name;
        this._price = opts.price;
      }
  }
  
  class MenuItem{
      constructor(opts){
          this._name = opts.name;
          this._price = opts.price
      },
  
      getCost: function(){
          return this._price;
      }
      getName: function(){
          return this._name;
      }
  }

정리

• 코드는 세가지 관점을 모두 제공해야한다.

  • 개념관점, 명세관점, 구현관점

    • 개념관점 : 도메인을 구성하는 중요한 개념과 관계를 반영한다면 변경을 관리하기 쉽고 유지모수성을 향상 시킬수 있다.
    • 명세관점 : 클래스의 인터페이스를 바라본다. 클래스의 public 메서드는 다른 클래스가 협력할 수 있는 공용 인터페이스를 드러낸다.
    • 구현관점 : 클래스의 내부 구현을 바라본다 내구 구현과 속성이 변경되더라도 외부의 객체에게 영향을 미쳐서는 안된다.

• 도메인 개념을 참조하자.

  • 사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다.
  • 도메인 모델이란 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태다.
  • 어떤 메시지가 있을때 그 메시지를 수신할 객체는 도메인 개념중에 가장 적절한 것을 선택하는 것이다.

• 인터페이스와 구현을 분리하라

  • 클래스를 봤을 때 클래스를 명세 관점과 구현 관점으로 나눠볼수 있어야 한다는 것이다.