ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 객체지향의 사실과 오해 2
    언어/객체지향 2023. 8. 2. 10:30

    3.타입과 추상화 (객체의 분류)

    - 지하철 지도를 통한 추상화 예시 

    - 정확성은 버리고 목적에 집중 

     

    3.1 추상화를 통한 복잡성 극복

     

    - 추상화란 불필요한 부분을 도려내고, 본질이 드러나게 하는 과정

    - 추상화는 목적에 의존적이다.

    1. 구체적 사물의 공통점은 취하고 차이점은 버리는 일반화 (분류)

    2. 중요한 부분을 강조하기 위해 불필요한 세부사항 제거 (일반화/특수화)

     

    3.2 객체지향과 추상화

    - 트럼프 예시에서 모든 각양각색의 트럼프 등장인물과 토끼를 트럼프와 토끼의 속성으로 분리

    > 그룹으로 나누어 단순화 하기

    > 개념 

        - 우리가 인식하는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념을 의미 

        - 객체간 차이점을 의도적으로 무시하고 공통점을 강조한 취사선택 

        - 객체를 묶기 위한 그릇을 개념이라 한다. 

        - 개념을 이용하여 객체를 여러 그룹으로 분류(classification)할 수 있다. 

        - 개념 그룹의 일원이 될 떄, 객체를 그 개념의 인스턴스라고 한다.

    > 개념의 세가지 관점

       1. 심볼 : 개념을 가리키는 이름이나 명칭

       2. 내연 : 개념의 완정한 정의 -> 내연을 이용하여 객체가 개념에 속하는지 알 수 있다.

       3. 외연 : 개념에 속하는 모든 객체의 집합 

    > 객체를 분류하기 위한 틀 

        - 외연의 관점에서 객체에 특정 개념을 적용할 수 있다는 것은 동일한 개념으로 구성된 집합임을 의미 

    > 분류는 추상화를 위한 도구이다. 

       - 개념은 객체들의 복잡성을 극복하기 위한 추상화 도구이다 

      

     

    3.3 타입 (분류에 관한 + 개념)

    > 타입은 개념이다. 

       - 개념을 대체하는 말 

       - 타입에 속하는 객체를 타입의 인스턴스라고 한다.

    > 데이터 타입 

        - 타입 시스템의 목적은 메모리안의 데이터가 비트열로 보임으로써 야기되는 혼란을 방지하기 위함이다.

        - 데이터가 잘못 사용되지 않도록 제약사항을 부과하는 것이다.

        1. 데이터가 어떻게 사용되느냐에 관한 것

        2. 타입에 속한 데이터가 메모리에 어떻게 표현되는지는 외부로 철저하게 감춰짐 

    * 데이터 타입은 메모리 안에 저장된 테이더 종류를 분류하는데 사용하는 메모리 집합에 관한 메타데이터

       데이터에 대한 분류는 암시적으로 어떤 종류의 연산이 해당 데이터에 수행될 수 있는지를 결정 

    > 객체와 타입 

       - 객체를 일종의 데이터처럼 사용한다고 생각해보면, 객체를 타입에 따라 분류하고 타입에 이름을 붙이는 것은 

          프로그램에서 사용할 새로운 데이터 타입을 선언하는 것과 같다. 

      - 객체는 행위에 따라 변하는 상태를 가지고 있고, 모든 객체의 상태를 모으면 결국 애플리케이션에서 관리해야 하는 전체 데이터를 표현할 수 있게 된다.

       1. 객체가 어떤 타입에 속하는지 결정하는 것은 객체가 수행하는 행동이다.

       2. 객체 내부적 표현은 외부로부터 철저하게 감춰진다.

            -> 행동이 우선이다.  객체에 행동에 따라 객체의 타입이 결정된다. 

                 - 객체 분류할때 사용하는 명확한 기준은 행동이다. (어떤 데이터를 보유하는 지는 타입 결정에 영향x)

                 - 행동에 따라 객체를 분리할 때 다형성에 의미가 부여된다. 

                 - 다형적인 객체들은 동일한 타입(타입계층)에 속하게 된다.       

     - 이러한 분류의 원칙은 캡슐화로 이어짐 

     - 객체를 분류할때 항상 외부에 제공해야하는 행동을 먼저 생각하자 그 책임을 수행하는데 적합한 데이터를 나중에 결정 

        수행에 필요한 외부 인터페이스 뒤로 캡슐화를 하자 

    - 이러한 책임을 먼저 결정하여 객체를 분류하고 필요한 데이터는 추후에 결정하는 것이 책임-주도 설계이다. 

     

    3.4 타입의 계층

    - 타입에 따라 객체를 나눈 후 -> 타입의 계층을 나누는데 일반화/특수화 관계가 사용된다.

    - 일반화는 외연에서 좀 더 일반적인 개념, 특수화는 객체만이 가지는 일반화를 제외한 특성 (일반화/특수화는 동시에 일어남)

    - 일반/특수화 관계 또한 행동이 결정한다.

    - 일반타입이 특수타입보다 더 적은 행동수, 많은 외연을 지님

    - 일반타입을 슈퍼타입, 특수 타입을 서브타입이라 한다. 

    - 어떤 타입이 다른 타입의 서브타입이 되기 위해서는 행위적 호환성을 만족시켜야 함 (호환성)

     

    > 일반화는 추상화를 위한 도구이다. 

       - 추상화의 두번째 패러다임을 이용하는 구체적인 방법임 (타입 (공통점 1번) -> 계층(2번))

       - 분류, 일반화/특수화를 통해 추상화를 하자 

     

    3.5정적 모델

     

    > 타입의 목적 

       - 타입을 사용하는 목적은 동적으로 변화하는 객체의 복잡성을 극복하기 위해서이다. 

       - 객체의 상태는 변화하지만, 다른 객체와 구별할 수 있는 식별성을 유지하게 된다.

       - 타입은 시간에 따라 동적으로 변하는 객체의 상태를 시간과 무관한 정적인 모습으로 다룰 수 있게 해준다. 

    > 결국 타입은 추상화이다. (분류,일반화/특수화)

    > 동적 모델과 정적 모델 

        - 스냅샷 (객체 다이어그램)  -> 실제 객체 (동적 모델) 

        - 모든 상태와 모든 행동을 시간 독립적 표현 (타입 모델) - 정적 모델

        - 객체 관점에 동적모델과 추상화한 타입 관점의 정적 모델을 적절히 혼용하자 

     

    > 클래스 

       - 정적 모델의 구현 타입을 구현하는 가장 보편적인 방법이다. 

       - 클래스와 타입은 동일한 것이 아님 타입은 객체를 분류하기 위해 사용하는 개념이고, 클래스는 이를 구현할 수 있는 여러 방법 중 하나 

       - 클래스는 타입의 구현 외에도 코드 재사용 용도로도 사용되므로 동일하게 생각하면 혼란을 가중한다. 

       - 객체를 분류하는 기준은 타입이며, 타입을 나누는 기준은 객체가 수행하는 행동 > 타입을 결정하고 타입을 구현하기 위해 클래스를 사용 

     

     

    * 1,2장에서 객체지향적 설계를 위해 협력, 역할, 책임과 각 객체들의 개방성과 자율성을 위한 메시지, 행동, 상태를 살펴봄 

       3장은 구체적으로 객체를 작성하기 위해 추상화에 대해 배움 -> 추상화는 분류,일반화/특수화를 통해 달성 가능 

       분류(공통점)를 위해 개념(타입)이 사용됨 중요한 것은 객체에 상태가 아닌 외부행위이다. 행위 내부적 표현은 감춘다.

       분류를 세분화(타입 계층)하기 위해 일반화/특수화가 사용된다.(차이점) 이 또한 데이터가 아닌 행위 중심

       위와 같은 분류의 목적은 객체에서 동적인 부분을 제외하고 정적으로 다루기 위함이다.

        실제로 타입을 구현하는 것은 클래스이다. - 객체 구현을 위해 사용되는 클래스의 작성법을 배웠다고 볼 수 있다.

        클래스 작성의 목적객체의 생성이고, 이를 위해 행위에 따라 객체를 추상화하고 외연의 객체들을 정적으로 다룰 수 있도록 해준다

     

    객체지향에서 중요한 것은 동적으로 변하는 객체의 상태와 상태를 변경하는 행위 

    클래스는 단지 타입을 구현하기 위해 제공되는 메커니즘이다.

     

    *  객체가 중요하지만, 이를 잘 다루기 위해 객체에 타입을 부여 

        타입의 목적은 추상화(분류,일반특수)를 통한 복잡성 극복, 잘못 사용되지 않도록 제약사항, 혼란방지(식별)

        타입을 먼저 결정하고, 이를 구현하기 위해 클래스를 사용하는 것 뿐

        필요한 것은 동적 앨리스 객체  행동 중심으로 앨리스 객체를 정적으로 정의하고, 분류하기 위해  사용하는 클래스가 아님  

     

    설계에 따라 이런 책임을 수행할 행동과 데이터를 가진 객체들이 필요하겠구나 -> 객체 타입을 결정해서 다시 분류 -> 클래스 작성을 통해 구체적 표현 

    (행동은 책임 +알파)   

    4. 역할, 책임, 협력

    - 행동을 결정하는 문맥은 협력이다. 

    - 협력이라는 문맥이 객체의 행동 방식을 결정한다. (개별 객체보다 중요한 것은 객체 사이 협력)

    - 협력이 자리를 잡으면, 객체의 행동이 들어나고, 상태가 결정됨 

     

    4.1 협력

    - 협력의 본질은 요청과 응답 

    - 공판예시 

    > 재판 속 협력 재판하라 -> 목격자 불러와라 -> 증인석에 입장하라 -> 증언하라의 협력 관계 

      - 요청을 받아들일 수 있는 이유는 요청에 적절한 방식으로 응답하는데 필요한 행동을 가지기 때문

      - 요청과 응답은 협력에 참여하는 객체가 수행할 책임을 정의한다.

     

    4.2 책임

    - 적절한 행동을 할 의무가 있는 경우 객체가 책임을 가진다고 말한다. 

    - 책임은 객체지향 설계에 가장 중요한 재료이다. 객체에게 적절한 책임을 부여해야한다.

    >책임의 분류 

     1. 하는것 : 객체를 생성, 계산, 다른 객체 행동을 시작시키는 것, 다른 객체 활동을 제어하고 조절하는 것

     2. 아는것 : 개인적 정보에 관해 아는 것, 관련된 객체에 관해 아는것, 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것 

    - 객체의 책임을 이야기할 때 외부에서 접근 가능한 공용 인터페이스 관점에서 얘기한다.

       책임은 외부에 제공해 줄 수 있는 아는것과 하는것의 목록이다. 

       책임은 객체의 공용 인터페이스를 구성한다.

    > 책임과 메시지 

        - 요청을 수신한 객체가 책임을 수행 책임을 수행하도록 요청하는 것 -> 메시지 전송 (송신자, 수신자) 

        - 메시지는 협력 참여하는 두 객체 사이의 관계를 강조

        - 책임은 협력에 참여하기 위해 수행하는 행위를 상위 수준에서 개략적으로 서술 -> 하나의 책임이 여러 메시지로 분할 

     

    * 어떤 클래스가 필요하고, 어떤 메서드를 포함해야하는지 결정하는 것은 책임과 메시지에 대한 대략적 윤곽을 잡고하자 

       협력,역할,책임이 좀 더 설계에 가깝다. -> 객체의 자율성을 고려하는 것과 클래스를 통해 추상화/분류는 그 다음 스탭 

     

    4.3 역할

    - 책임의 집합이 의미하는 것 

    - 책임의 집합은 객체가 협력에서 수행하는 역할을 암시한다.

    > 역할이 답이다.

       - 책임의 집합이 역할, 특정 역할을 수행할 수 있다는 것은 특정 책임의 집합을 수행할 수 있음 암시 

       - 역할은 대체 가능성을 의미함 

       - 동일한 역할을 수행하는 객체들이 동일한 메시지를 수신할 수 있음으로, 동일 책임 수행가능하다. 

     -역할은 단순성, 유연성, 재사용성을 뒷받침하는 핵심근거

    > 협력의 추상화 

       - 구체적인 객체로 추상적인 역할을 대체해서 동일한 구조의 협력을 다양한 문맥에서 재사용 

    > 대체 가능성 

       - 역할은 구체적인 객체로 대체될 수 있는 추상적 협력자 (행동의 호환) 

       - 객체는 역할이 암시하는 것 보다 더 많은 책임을 가질 수 있다. 

    4.4 객체의 모양을 결정하는 협력

    - 객체가 존재하는 이유는 협력에 참여하기 위해서 중요한 것은 객체의 행동 책임 

    - 중요한 것은 협력에 참여하는 동적 객체이며 클래스는 정적으로 객체를 표현하고 생성하기 위한 메커니즘일 뿐 

    > 협력에 따라 흐르는 책임

     - 협력을 설계 -> 메시지 결정 -> 책임의 결정 -> 행동의 결정 -> 필요 데이터 결정 -> 클래스 개발 (동적 객체 생성 전 정적으로 객체를 다루기 위한 타입결정(분류)의 과정 

     - 역할은 위 과정에서 협력을 추상화하고, 책임의 대체 가능성을 부여함 

    4.5 객체지향 설계 기법 

    - 책임 -주도 설계 : 협력에 필요한 책임을 식별, 적합 객체에게 책임을 할당 

    - 디자인 패턴 : 역할, 책임,협력의 모둠 

    - 테스트 주도 개발 : 설계를 위한 기법으로 테스트는 설계의 보너스 역할 책임 협력을 가지고 설계하는 건 변하지 않음 

     

     

    * 역할, 책임, 협력에 대해 자세히 알아봄 -> 객체지향 설계 

     협력을 설계 ->역할 분류->  메시지 결정 -> 책임의 결정 -> 책임을 수행하기 위한 구체적 객체 행동의 결정 -> 필요 데이터 결정 -> 클래스 개발 (동적 객체 생성 전 정적으로 객체를 다루기 위한 타입결정(분류)의 과정 

     - 역할은 위 과정에서 협력을 추상화하고, 책임의 대체 가능성을 부여함 

Designed by Tistory.