본문 바로가기

전체 글

 (336)
오브젝트 - 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 패턴 - 부모 클래스에 기본적 알고리즘의 흐름을 구현하고, 중간에 필요한 처리를 자식 클래스에게 위임하는 패턴 영화 예매 시스템 예제 클래스 사이의 의존성은 객체 사이의 의존성이랑 다를 수 있음 (런타임 결정) 설계가 유연해질수록 코드를 이해하고 디버깅하기는 점점 더 어려워진다. 협력이 설계를 위한 문맥을 결..
간신 개발 목표 (유니티 RPG 프로젝트) 지난 글에 이어 현재 작업하고 있는 내용과 상반기 목표를 정리하기 위해 이 글을 작성함 2월 - 필드 몬스터 시스템 + 조작개선 캐릭터 조작 변경 Riko 애니메이션 변경 몬스터 AI 수정(Nav Mesh기반 이동 추가) 몬스터 스텟 시스템 제작 전투 시스템 제작(플레이어와 몬스터가 서로 공격을 주고받는 부분) HUD UI 제작 HUD UI를 제작함으로써, 위에서 적용된 모든 피쳐를 합한 결과를 확인할 수 있을것 3월 - 캐릭터 시스템 완성 기본 캐릭터 시스템 (스킬, 스태미너, 체력) 캐릭터 3종 완성 ( Riko 제외 궁극기는 제외될 가능성 있음 ) Ai의 경우 화살 처리를 어떻게 할껀지 고민 필요 캐릭터 관리 시스템 캐릭터 UI 제작 캐릭터 스텟 제어 시스템 제작 GitHub - eugene-doo..
간신 개발 일지 - 23.02.11(유니티 RPG 프로젝트) 계속 개발중이긴 했는데 티스토리의 존재를 잊어서 포스팅을 안하고 있었음. 개발기록을 티스토리 같은 곳에 남기는것보다 그냥 깃허브 이슈탭에 남기는게 훨씬 편하다.. 현재까지 작업된 내용은 이런것들이 있다. 지금까지는 프로젝트 기반작업과 사용할 라이브러리에 익숙해지는 시간을 갖고 있었고, 현재 2월 작업에서는 몬스터와 관련된 콘텐츠들을 작업하고 있다. 현재 조작법 너무 불편하고.. 아무리 생각해도 캐릭터 애니메이션 에셋 뽑기를 잘못한거같아서 지금 캐릭터 애니메이션과 조작법을 뜯어고치는 작업을 하고 있다. 작업을 하면서 느낀점은.. 1. 오브젝트들을 개발자가 자유롭게 제어하기 위해서는 유니티 물리는 사용하지 않는게 좋다. 그게 사실적인 움직임일지는 모르겠지만, 개발자가 예상치 못한 케이스가 자꾸 일어나고 무엇..
추억속 아케이드 게임을 이끌어 온 기술 ~ 1990(완) 1984: 마블 매드니스 - C언어와 레이 트레이싱 마블 매드니스는 C언어를 사용해 제작되었다. C언어는 고급 언어 중에서도 기술하기 쉽다는 점과(어셈블리어랑 비교하면..) 저급 언어에 가까운 실행속도를 얻을 수 있는 언어이다. 같은 동작을 하는 어셈블리어와 C언어를 비교하면 프로그램의 규모가 크고 복잡할 때는 C언어가 개발 효율이 높다는 것을 알 수 있다. 마블 매드니스는 스테이지를 레이 트레이싱 기술을 활용하여 렌더링하였다. 레이트레이싱이란 이름 그대로 플레이어의 눈에 닿는 광선의 길을 더듬어 봄으로 현실에 가까운 외형을 그려내는 그래픽 기법이다.(라고 하지만 레이트레이싱이 적용된건지 모르겠네) 최근에는 고성능 GPU를 이용하여 매 프레임 단위로 실시간 레이트레이싱을 수행하기도 하지만, 마블 매드니스..

티스토리툴바