게임 클라 개발

6장 - 객체와 자료 구조 흔히 필드를 private로 선언하고 getter, setter를 public으로 놓는데 이게 뭔 의미가 있을까? 저자인 로버트 C. 마틴도 `조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지는 않는다.` 라고 말한다. 그보다는 추상 인터페이스를 제공해야 한다고 말한다. 즉, 자료를 하나하나 공개하기보다는 추상적인 개념으로 묶어서 표현하는 것이 좋다. public interface FuelTank { double getFuelTankCapacity(); double getFuel(); } public interface FuelTank { double getPercentFuelRemaining(); } 즉, 위에꺼보다 아래꺼가 낫다. 개발자는 자료를 표현할 가장 좋은 방법을..

4장 주석 주석은 실패를 의미한다. 코드로 의도를 표현하지 못한 것을 만회하기 위해 주석을 사용한다. 즉, 원래는 주석 없이 코드로만 의도를 표현하는게 가장 이상적이다. 심지어 주석은 보통 나쁘다. 왜냐? 코드를 변경하면서 주석을 유지보수하기란 힘든 일이고, 결국 주석은 낡아지고 잘못된 정보를 드러내게 된다. 그럼에도 좋은 주석이 있다. 코드로 의도를 표현하는 것이 가장 이상적이지만 현실적으로는 힘든 경우가 많다. 다음은 좋은 주석의 예이다. 정보를 제공하는 주석 : 기본적으로는 함수나 변수의 이름에 정보를 담아야 한다. 그러나 시간을 나타내는 문자열의 포맷같은 정보는 유용할 수 있다. 의도를 설명하는 주석 : 프로그램의 의도가 아닌 코드를 작성한 저자의 의도는 타당하다. (저자의 의도를 코드에 담을 수..

로버트 C. 마틴의 클린코드 2,3장을 정리 이름(22p~) 이름은 의도를 분명히 밝혀야 한다. 이름을 보고 존재이유, 수행 기능, 사용 방법을 알 수 있어야 한다. 오해를 불러올 수 있는 이름은 피해라.(24p) 쓸데없는 단어 붙이지 마라 : ~Info, ~Data 이런게 무슨 정보를 제공하는가? customer, customerInfo, customerData 는 관례 없이는 구분하기 힘들다. 읽는 사람이 차이를 알도록 이름을 지어야 한다. Manager, Processor... 등 도 마찬가지 타입을 인코딩하지 마라 : monsterList 는 그냥 monsters로 해라. 타입이 Dict로 바뀌면 어쩔껀가? 타입을 적는다고 해서 이득도 없다. 'm_'이런 접두어도 붙이지 마라 : IDE에서 색 다..

로버트 C. 마틴의 클린 아키텍쳐를 읽고... 12장부터 '대충' 요약 컴포넌트 컴포넌트는 배포할 수 있는 가장 작은 단위를 의미한다. (jar, dll 같은 파일) 컴파일형 언어에서는 바이너리 파일의 결합체, 인터프리터형 언어의 경우 소스파일의 결합체이다. 잘 설계된 컴포넌트라면 반드시 독립적으로 배포가능(=독립적으로 개발가능)해야한다. 어떤 클래스를 어느 컴포넌트에 포함시켜야 할까? 세 가지 원칙을 고려할 수 있다. REP (재사용/릴리스 등가 원칙) : 재사용 단위는 릴리스 단위와 같다. CCP (공통 폐쇄 원칙) : SRP의 컴포넌트 버전. 서로 다른 이유로 변경되는 클래스는 서로 다른 컴포넌트로 분리해라! CRP (공통 재사용 원칙) : 컴포넌트 사용자들을 필요없는 것에 의존하도록 강요하지 마라..

#include class AAA { private: int intA; int intB; double doubleA; }; class BBB { private: int intA; double doubleA; int intB; }; int main() { AAA a; BBB b; std::cout

SRP (단일 책임 원칙) 흔히 이걸 모듈이 단 하나의 일만을 해야 한다는 의미로 오인하기 쉬운데 그렇지 않다. (단, 함수는 단 하나의 일을 해야한다는 원칙이 있긴 한데 이건 설계원칙은 아니고 리팩토링할때나 쓰는 원칙) SRP의 진정한 의미는 '단일 모듈은 변경의 이유가 오직 하나뿐이어야 한다.' 이다. 다시 말하면 '단일 모듈은 그 모듈을 변경하려는 집단(액터)이 하나여야 한다.' 만약 한 집단의 수정사항을 반영한 것이 다른 집단의 작업에 영향을 끼칠 수 있다면 이것이 SRP를 위반한 사례라고 볼 수 있다. (이런 사례는 종종 형상관리툴에서 Merge를 발생시킨다.) 해결책은 무엇일까? 확실한 방법은 액터마다 데이터와 메서드를 분리하고 데이터는 별도의 클래스를 만들어 공유하는 방식이다. 그러나 이런 ..

패러다임 프로그래밍에도 패러다임이 있다. 구조적 프로그래밍 객체지향 프로그래밍 함수형 프로그래밍 프로그래밍 패러다임은 프로그래머가 무엇을 할 지가 아니라 무엇을 하면 안 되는지를 말해준다. 위의 3가지 규칙은 프로그래머에게 goto문, 함수 포인터, 할당문을 뺏는다. 구조적 프로그래밍 goto문은 프로그램의 모듈을 분해하는 것을 방해한다. 만약 모듈을 분해할 수 없다면 분할 정복 기법의 사용이나 각각의 모듈을 테스트 하는데 어려움이 있을 것이다. 구조적 프로그래밍은 goto문의 사용을 제한함으로써 프로그래밍에서 테스트 가능한 단위를 작게 만들어 낸다. 이렇게되면 프로그래머가 각각의 컴포넌트, 모듈...등을 쉽게 테스트할 수 있다. 객체 지향 프로그래밍 흔히 객체 지향 프로그래밍의 요소로 캡슐화, 상속, ..

CAP 이론 개요 CAP 이론이란 분산 시스템 선택에 도움을 주는 정리이다. Consistency(일관성) : 시스템에 접근하는 누구나 같은 결과를 봄 Availablity(가용성) : 누구나 언제든지 시스템에 접근(읽기/쓰기) 가능 => lock 거는 일이 없다. Partition Tolerance (분할 용인) : 시스템을 분할할 수 있음 (병렬 처리, 멀티쓰레딩) 이며 CAP를 모두 충족하는 시스템은 없다는 것이 핵심이다. 멀티 플레이와 CAP 멀티플레이 게임은 기본적으로 'P'를 충족해야 한다고 볼 수 있다. 그러면 멀티플레이 동기화에 있어서 선택지는 두 개가 남는다. 'A'를 택할 것인지, 'C'를 택할것인지 멀티플레이의 동기화 방식 1. 비동기형 Clash of Clans 같은 게임이 해당된다..