기억을 위한 기록들

1. MVC 패턴이란? - Model + View + Controller를 합친 용어. Model : 프로그램에 사용되는 데이터와 그 데이터를 처리하는 부분 View : 데이터의 시각적인 표현을 담당하는 부분. 사용자 인터페이스를 나타내며, 모델의 상태를 보여주거나, 사용자의 입력을 받아 모델에 전달. Controller : 모델과 뷰 사이의 상호작용 관리하며, 사용자의 입력을 받아 모델을 업데이트하고, 그 결과를 적절한 뷰로 보여주는 역할을 한다. 동작 순서 : 1. User의 Request가 Controller에 전달 2. Controller는 Request를 확인하고 Model에 업데이트 - 3. 업데이트 된 Model의 정보를 Controller는 여러 개의 View에 알맞게 전달(전달되는 방법은..

Solid 디자인 원칙은 무조건 이렇게 해야한다! 이렇게 하지 않으면 틀린다! 가 아니라 이 원칙들을 지키면 직관적인 코드가 되고 코드들의 유지보수가 쉬워진다고 한다. S (Single Responsibility Principle / SRP) - 단일 책임 원칙 - 각 클래스는 단 한 가지의 책임을 부여받아, 수정할 이유가 단 한 가지여야 한다. ex) 어떤 몬스터 클래스가 있다고 하자. class Monster{ int Hp; int Damage; //..기타등등 변수들 void Attack(); //공격하기 위해 void Death(); //죽었을때 호출하기 위해 void PrintState(); // 해당 함수를 호출하면 이 몬스터 객체에 대해 로그를 남겨준다. }; 예와 같이 이런식의 클래스가 있..

디자인패턴의 목적 -> 읽기 쉽고, 이해 하기 쉽고, 수정하기 쉽기 위해 쓴다. 읽기 쉬워지기 위해서 디자인 패턴을 쓰는게 아니라, 디자인패턴을 쓰기 위해 코드가 더 어려워 지기도한다. 결국은 클래스 중심의 OOP 패턴들이 많이 있다. 오히려 간단한 함수 인터페이스나, 함수형 프로그래밍이나 멀티 패러다임(여러가지 섞은)이 더 나을 수도 있다. OOP 중심의 디자인 패턴을 학습하면 클래스에 대한 관점이 더 유연해지고, 문제에 맞는 클래스를 구조를 생각하는데 도움이 된다고 한다.

"오직 한개의 클래스 인스턴스만을 갖도록 보장하고, 이에 대한 전역적인 접근점을 제공합니다." (보통 '한개의 클래스 인스턴스'와 '전역접근' 중에서 보통은 '전역 접근'이 싱글턴 패턴을 선택하는 이유이다.) 싱글턴 패턴은 의도와는 달리 득보다는 실이 많다. 부적당한 곳에서 사용하면 쓸모가 없다. 싱글턴 패턴이란? 오직 한 개의 클래스 인스턴스만 갖도록 보장 클래스가 인스턴스를 하나만 가지도록 컴파일 단계에서 강제. 전역 접근점을 제공 로깅, 콘텐츠 로딩, 게임 저장 등 여러 내부 시스템에서 파일 시스템 래퍼 클래스를 사용할 것이다. ex)파일 시스템 클래스 인스턴스를 따로 생성 할 수 없다면, 파일 시스템에는 어떻게 접근해야할까? 여기에 대한 해결책도 제공한다. 하나의 인스턴스만 생성하는 것에 더해서,..

"객체의 내부 상태에 따라 스스로 행동을 변경할 수 있게 허가하는 패턴으로, 이렇게 하면 객체는 마치 자신의 클래스를 바꾸는 것처럼 보입니다." GoF의 디자인 패턴 35쪽 간단한 횡스크롤 플랫포머게임을 만든다고 쳐보자. 사용자가 B 버튼을 누르면 점프를 해야 한다. 캐릭터 Heroine이라는 클래스가 있다고 가정한다. 하지만 위 코드엔 버그가 있다. 바로 '공중점프' 즉, 무한 점프가 가능하다. 이 버그는 점프 상태를 확인하는 불리언 변수를 추가해 간단히 고칠 수 있다. 다음으로, 주인공이 땅에 있을 때 아래 버튼을 누르면 엎드리고, 떼면 다시 일어서는 기능을 추가했다. 하지만 이번에도 이번에도 버그가 있다. 1. 엎드리기 위해 아래 버튼을 누른 뒤, 2. B 버튼을 눌러 엎드린 상태에서 점프하고 3...

"원형(Prototypical)이 되는 인스턴스를 사용하여 생성할 객체의 종류를 명시하고, 이렇게 만든 견본을 복사해서 새로운 객체를 생성합니다" 예를들어서.. 게임에 나오는 몬스터마다(Ghost, Demon, Sorcerer 같은...) 클래스를 만들어본다고 하자. 이제 몬스터롤 스폰하기 위해 Spawner 클래스를 만든다고 치면, 한 가지 스포너는 한 가지 몬스터 인스턴스만 만든다. 스포너 클래스 상속 구조가 몬스터 클래스 상속구조를 따라가게 된다. 영 별로다. 클래스도 많지, 행사코드도 많지, 반복 코드도 많지, 중복도 많지,,, 많지 많지... 이런 걸 프로토타입 패턴으로 해결할 수 있다. 핵심은 어떤 객체가 자기와 비슷한 객체를 스폰(Spawn)할 수 있다는 점이다.. 유령 객체 하나로 다른 유..

초안 : 2020-05-05수정 : 2023-02-02 의도 "한 개체가 여러 분야를 서로 커플링 없이 다룰 수 있게 한다." 3가지의 방식 1. 컨테이너 객체의 상태를 변경하는 방식 (ex 캐릭터(위치값)->(전달)->입력 컴포넌트 and 피직스 컴포넌트) - 컴포넌트들은 서로 디커플링 상태를 유지한다. 예를 들어 InputComponent에서 캐릭터의 속도를 변경하고, PhysicsComponent에서 그 값을 사용하면 이들 두 컴포넌트는 서로 몰라도 된다. 그저 캐릭터의 속도가 알 수 없는 무엇인가에 의해 변경되었다고 짐작만 할 수 있다. - 컴포넌트들이 공유하는 정보를 컨테이너 객체에 전부 넣어야한다. 예를 들어, 그래픽 관련 상태를 공유해야 하는데, 이런 상태를 다른 모든 컴포넌트가 접근 할 수..

최초 작성 : 2020년 3월23일 1차 수정 : 2023년 1월 29일 경량패턴 이름에서도 알 수 있듯이 경량패턴은 어떤 객체의 개수가 너무 많아서 좀 더 가볍게 만들고 싶을 때 사용. 인스턴스 렌더링에서는 메모리 크기보다 렌더링할 나무 데이터를 하나씩 GPU버스로 보내는데 걸리는 시간이 중요하지만, 기본 개념은 경량 패턴과 같다. 이런 문제를 해결하기 위해 경량 패턴은 객체 데이터를 두 종류로 나눔. 1. 고유상태(or 자유문맥) : 메시(나무 형태), 텍스쳐 등 해당 2. 외부상태 : 위치, 크기, 색 등 즉, 한개의 고유 상태를 다른객체에서 공유하게 만들어 메모리 사용량을 줄일 수 있다. ex) 한그루의 나무 클래스를 만들어 숲을 만들어야한다. 나무 객체에 들어 있는 데이터 대부분이 인스턴스별로 ..