공부/개발 독서 (20) 썸네일형 리스트형 오브젝트 - 7 ※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다. 197p~215p 원칙의 함정 소프트웨어 설계에 절대적인 법칙이란 존재하지 않는다. 법칙에는 예외가 없지만 원칙에는 예외가 넘쳐난다. 잊지 말아야 하는 사실은 설계가 트레이드오프의 산물이라는 것이다. 설계가 적절하게 트레이드오프 할 수 있는 능력이 숙련자와 초보자를 구분하는 가장 중요한 기준이라고 할 수 있다. 디미터법칙은 하나의 도트(.)를 강제하는 규칙이 아니다 - 디미터 법칙은 결합도와 관련된 것이며, 이 결합도가 문제가 되는 것은 객체의 내부 구조가 외부로 노출되는 경우로 한정한다. 결합도와 응집도의 충돌 - 클래스는 하나의 변경 의도만을 가져야 한다. - 디미터법칙과 묻지 말고 시켜라 원칙을 무작정 따르면 애.. 오브젝트 - 6 ※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다. 181p~197p 협력과 메시지 파트의 용어 정리 메시지: 객체가 다른 객체와 협력하기 위해 사용하는 의사소통 메커니즘. 객체의 오퍼레이션이 실행되도록 요청하는 것을 '메시지 전송'이라고 부른다. 오퍼레이션: 객체가 다른 객체에게 제공하는 추상적인 서비스, 메시지를 수신하는 객체의 인터페이스를 강조 메서드: 메시지에 응답하기 위해 실행되는 코드 블록, 오퍼레이션의 구현 퍼블릭 인터페이스: 객체가 협력에 참여하기 위해 외부에서 수신할 수 있는 메시지의 묶음 시그니처: 시그니처는 오퍼레이션이나 메서드의 명세를 나타낸 것. 이름과 인자의 목록을 포함 인터페이스와 설계 품질 좋은 인터페이스는 최소한의 인터페이스와 추상적인 인.. 오브젝트 - 5 ※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다. 169p~181p 일반적으로 명확성의 가치가 클래스의 길이보다 더 중요하다. 객체를 자율적으로 만들자 - 자율적인 객체가 될 수 있가 메서드를 적절한 클래스로 이동시키자. 자신이 소유하고 있는 데이터를 스스로 처리하게 만드는 것이 자율적인 객체를 만드는 지름길이다. - 데이터를 사용하는 메서드를 데이터를 가진 클래스로 이동시키고 나면 캡슐화와 높은 응집도, 낮은 결합도를 가지는 설계를 얻게 된다. 챕터6. 메시지와 인터페이스 객체지향 프로그래밍에 대한 가장 흔한 오해는 애플리케이션이 클래스의 집합으로 구성된다는 것이다. 애플리케이션은 객체들 사이의 메시지를 통해 정의된다. 1) 협력과 메시지 클라이언트-서버 모델 - .. 오브젝트 - 4 ※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다. 159p~169p 도메인의 구조가 코드의 구조를 이끈다 - 변경 역시 도메인 모델의 일부이다. - 다시 강조하지만 구현을 가이드할 수 있는 도메인 모델을 선택하라 변경과 유연성 - 변경이 자주 발생한 지점은 복잡성이 증가하더라도 유연성을 추가하는 것이 좋다 - 런타임에 정책을 변경하는 경우, 상속보다 합성이 유리할 수 있다. - 유연성은 의존성 관리의 문제. 요소들 사이의 의존성의 정도가 유연성의 정도를 결정한다. - 코드의 구조가 바뀌면 도메인에 대한 관점도 바뀐다. 메서드 응집도 - 몬스터 메서드: 길고 응집도가 낮아 이해하기 어렵고 재사용하기도 어려우며 변경하기 어려운 메서드 - 긴 메서드가 명령문들의 그룹으로 .. 오브젝트 - 3 ※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다. 129p~159p 5. 책임 할당하기 책임 중심 설계를 위해 - 데이터보다는 행동을 먼저 결정하라 - 협력이라는 문맥 안에서 책임을 결정하라 객체가 메시지를 선택하는 것이 아닌, 메시지가 객체를 선택해야 한다. 객체를 만들었기에 메시지가 필요한 것이 아닌, 메시지를 전송하기 떄문에 객체를 갖게된 것이다. -> 이러한 방식으로 협력을 설계하면 기본적으로 메시지 수신자가 깔끔하게 캡슐화된다. 책임 할당을 위한 GRASP 패턴 - General Responsibility Assignment Software Pattern 1.도메인 개념에서 출발하기 - 도메인 개념들을 책임 할당의 대상으로 사용하면 코드에 도메인의 모습을 투.. 오브젝트 - 2 ※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다. 86p~129p 역할 - 역할은 객체가 참여할 수 있는 일종의 슬롯 (추상 클래스나 인터페이스로 구현) - 협력에 참여하는 후보가 여러 종류의 객체에 의해 수행될 필요가 있다면 그 후보는 역할, 아니라면 객체 - 설계시 역할을 사용할지, 객체를 사용할지 애매하다면, 단순하게 객체로 시작하고, 책임과 협력을 정제해가면서 필요한 순간에 객체로부터 역할을 분리해내는 것이 가장 좋은 방법이다. - 객체는 다양한 역할을 가질 수 있지만, 특정한 협력 안에서는 오직 하나의 역할로 보여진다. 4. 설계 품질과 트레이드 오프 객체지향 설계의 핵심은 역할, 책임, 협력 - 역할: 대체 가능한 책임의 집합 - 책임: 객체가 다른 객체와.. 오브젝트 - 1 ※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다. ~86p 객체지향 프로그래밍 - 협력, 객체, 클래스 o 어떤 클래스가 필요한지 이전에 어떤 객체들이 필요한지 고민하라. o 객체를 독립적인 존재가 아닌 공동체의 일원으로 봐야 한다. 클래스는 도메인과 최대한 유사하게 만들어야 한다. (가능하다면 기획서에 있는 구조로 클래스를 짜야지) TEMPLATE METHOD 패턴 - 부모 클래스에 기본적 알고리즘의 흐름을 구현하고, 중간에 필요한 처리를 자식 클래스에게 위임하는 패턴 영화 예매 시스템 예제 클래스 사이의 의존성은 객체 사이의 의존성이랑 다를 수 있음 (런타임 결정) 설계가 유연해질수록 코드를 이해하고 디버깅하기는 점점 더 어려워진다. 협력이 설계를 위한 문맥을 결.. 추억속 아케이드 게임을 이끌어 온 기술 ~ 1990(완) 1984: 마블 매드니스 - C언어와 레이 트레이싱 마블 매드니스는 C언어를 사용해 제작되었다. C언어는 고급 언어 중에서도 기술하기 쉽다는 점과(어셈블리어랑 비교하면..) 저급 언어에 가까운 실행속도를 얻을 수 있는 언어이다. 같은 동작을 하는 어셈블리어와 C언어를 비교하면 프로그램의 규모가 크고 복잡할 때는 C언어가 개발 효율이 높다는 것을 알 수 있다. 마블 매드니스는 스테이지를 레이 트레이싱 기술을 활용하여 렌더링하였다. 레이트레이싱이란 이름 그대로 플레이어의 눈에 닿는 광선의 길을 더듬어 봄으로 현실에 가까운 외형을 그려내는 그래픽 기법이다.(라고 하지만 레이트레이싱이 적용된건지 모르겠네) 최근에는 고성능 GPU를 이용하여 매 프레임 단위로 실시간 레이트레이싱을 수행하기도 하지만, 마블 매드니스.. 이전 1 2 3 다음
