2019년 3월 11일

코드스피츠80_OOP design with game (2)- 1. 개요

코드스피츠 강의 정리록

생소한 도메인으로 배우는게 좋다. 익숙한 도메인들은 익숙한 처리방법으로 처리하기때문에 객체지향을 배우기 어렵다. 때문에 80기는 게임을 통해서 진행할 예정.

0. 프로시저 프로그래밍

저번시간의 프로시저 프로그래밍 복습

프로시저 프로그래밍의 특징

함수와 함수가 처리해야 할 데이터가 분리되어있고, 데이터와 함수가 같이 연동되어야 하지만 프로시저가 작동된다. . 프로시저 작동에서는 행위에만 집착하게 된다. (데이터 배열에 무엇을 채웠어 무엇을 비웠어) 데이터를 처리했다는 행위에 집중한다. .
함수형과는 다르게 프로시저들은 가리키고 있는 데이터가 있다. 프로시저는 상태를 지향하며, (유틸리티처럼) 특정 상태를 변화시키는 것에 관심을 둔다. (함수형은 인자로 받거나 지역변수만 사용하는 식으로 데이터를 처리하고 있다.)

프로시저 프로그래밍의 단점

데이터의 변화와 데이터를 처리하는 함수의 변화가 동시에 이루어지지 않는다. .
데이터를 조금만 바꾸던지, 처리를 바꾸면 데이터가 어긋나게 되고 프로그램 전체가 깨지게 된다.

데이터 항목 구성을 변화하거나 데이터 자체에 추가적인 내용이나 연결되어있는 데이터를 만드는 일은 흔하다. => 이런 상황이 생기면 기존의 프로시저가 깨진다.
우리는 프로시저 프로그래밍에 익숙해져 있다. ex_TDD TDD를 사용하면 무조건 프로시저로 짜게 된다. 테스트 메소드 전체는 다 프로시져이다.
- 테스트 메소드가 알 수 없는 외부상태의 것을 테스트하는 함수
  - : 프로시저
- : 객체를 바꾸면 테스트함수가 다 깨짐. 다 바꿔야함.
- 테스트 주도 개발을 하려면, 설계를 잘하면 할 수 있다.
프로시저로 만들면 어떤 일이 생긴냐면.. ex_만약에 폭발형 아이템을 만든다면? => 프로시저 전체를 다 수정하는 수밖에 없다. => if를 넣어서 분기하면서 수정하는 수밖에 없다.(모든 함수에 다 들어간다.) => if가 추가되는 것이 문제가 아니라 기존의 모든 레거시와의 관계를 재검토해서 들어가야하는데..복잡성을 감당할 수 없다.

복잡성이 폭발하면 ? => 버려야합니다.

프로그래밍의 수명은 복잡성 컨트롤 제어에 실패하면 더이상 유지보수할 수 없기 때문에 나머지의 모든 프로그래밍 기법들은 복잡성이 더 복잡해지지 않게 하기 위해.

엔트로피 증가법칙 😎😎

많은 사람들의 요건추가와 변화로 엔트로피가 꾸준히 증가한다. 엔트로피를 증가시키는 것을 최대한 둔화시켜야한다. 프로그래밍 세계에서 엔트로피가 언제 증가하는지 알아가는 것이 우리 스터디에서 배워야할 것. 많은 장치로 엔트로피의 증가를 막을 수있다. 아무리 막아도 내년되면 다시 짜야한다. 잘못짠 프로그램은 엔트로피가 급격하게 증가해서 빨리 버리게 된다. 잘짠 프로그램도 버려야한다.

엔트로피 증가방향을 컨트롤해서 완화시키고 복잡한 환경이나 여러가지 변화상황을 잘 받아들일 수 있는 구조를 짜는것을 디자인이라고 하고 아키텍처라고 한다.

엔트로피 증가를 막으려고.

엔트로피 증가를 막자.

객체지향에서는 어떻게 앤트로피 증가를 막느냐. 역할이라는 것으로 분리해서 막는다.

가장 중요한 변화율

변화율을 기준으로 역할을 분리해서 역할별로 객체들을 만들고 싶은데, 그렇게 하기에는 우리가 해결해야 하는 문제가 너무 큰 덩어리로 되어있는 문제라는 것이다.

사람은 한꺼번에 복잡성 제어를 못 하기 때문에 복잡성 폭발한 프로그램은 버리게 된다. 너무 복잡한 것은 분석할 수 없다. 복잡한 문제는 나눠서 분석해야지만 분석할 수 있다.

복잡한 문제를 나눠서 분석하기 위한 도구를 추상화 도구라고 한다. (다른 글 )

1. Categorizing

분류를 통해서 계속 나눠가면 상쇄 적인 부분만 하나씩 정복해나가면 전체를 이해할 수 있다는 개념

단점: 카테고리가 여러 곳에 소속되어있을 때 처리하기가 많다.

2. Modeling

기억해야만 할 것을 정리하면 모델링이 된다.

없어야 할 데이터는 없어야 한다. 없어야 할 데이터가 있는 것도 오류다. . 현재의 모델링이 미래에 유용한 것도 아니고 미래를 위해서 현재의 모델링을 함부로 확장하는 것도 아니다.
모델링의 단점: 유지보수가 힘들다. 현실 세계에서는 모델이 자주 바뀐다 ex_학생. => 학번, 이름,

데이터에 의존하고 있는 프로시저가 데이터의 변화를 따라갈 수 없기 때문에 프로시저 프로그램들이 에러가 나는 것이다.

현실 세계에서 모델링을 해야 하고 모델링을 다루는 함수들을 강력하게 바인딩시키지 않으면 모델의 변화가 프로시저에 충분히 반영되지 않거나 프로시저의 변화가 모델에 반영되지 않아 둘이 어긋나서 프로그램이 깨지는 것.

3. Grouping

우리가 필요해서 묶어주는 것

enum을 사용하면 단일집합을 사용할 수있다.
class도 집합. 클리스의 인스턴스를 만드는 것도 어떤 그룹인지 마킹을 해주는 의미도 있다. 단지 그룹핑만을 위해서 마커를 사용할 경우에 클래스나 인터페이스를 마커 클래스나 마커 인터페이스라고 한다. ex_ 페이스북에 해시태그에 ‘맛집’도 집합

1. 레이어 분리 (Layering)

(feat. 마틴 파울러의 앤터 프라이즈 디자인 패턴 책) 레이어라는 방법을 사용한다. 레이어는 일종에 카테고라이즈에 가깝다.

먼저 크게 분리한다. client ←→ server presentation ←→ doman ←→ data source

domain: 도메인 로직
data source: 저장하는 로직
presentation: 도메인을 표현하는 로직 (앱, 웹,..)

레이어는 계층적이다. 레이어들간에는 호환되지 않는다! 층을 정확하게 나눠야한다. 2. 기저레이어는 추상레이어를 모른다. 추상레이어 - 기저레이어를 사용하는 레이어 - 기저레이어에 대한 지식을 알고 있는 레이어 - OOP에 대입하면 기저레이어: 부모클래스 추상레이어: 자식클래스 - 자식이 부모를 알고 있다. 부모는 자식을 모른다. 3. 레이어안에 다수의 역할이 소속된다. 레이어안에는 다수의 역할이나 다수의 역할을 수행하는 인스턴스들이 소속된다.

레이어안에는 레이어의 전체적인 레이어 가이드들을 지키고 있는 수많은 레이어들이 존제한다.

인메모리에서 레이어를 나누어보자. 레이어를 나누는 눈이 필요하다.

(함수형) 유틸리티 함수와 메소드의 차이는 this를 쓰냐안쓰냐. OOP에는 기저 인터페이스나 기저 클래스도 유틸리티로 분류하기도 한다.
베이스 클래스
구상 클래스
호스트코드

게임의 실체는 어디일까? 실체는 호스트 코드.

구상 클래스, 베이스 클래스에 로직이 있고, 호스트코드는 사용하는 입장이다.
진짜로 일하는 애는 호스트코드
호스트코드부터 짜는 것이 좋다. 반대로 짜게 되면 사용하지 않을 것들도 만들게 됨.

수업 시간에는 아키텍처를 공부하기 위해 반대로 짜볼 것이다.

0. 유틸리티

함수 호출 하는 방식으로 다른 레이어와 소통한다. 모든 레이어와 소통.

1. 베이스 클래스

베이스 클래스와 구상 클래스의 관계는 상속되거나 소유된다.

1.1 기반이 되는 3가지 클래스

모델 모델링 한 것, 게임 자체를 모델링한 데이터가 존재함. (entity)
뷰 모델을 그림 그릴 수 있는 로직
컨트롤러 뷰와 대화하거나 해당 모델을 처리할 수 있는 로직이 한꺼번에 들어있음

컨트롤러가 여러 개의 모델을 소유하게 될 것이다.

뷰가 인터렉션을 할 때 컨트롤러에게 위임하는데 컨트롤러에게 뷰의 책임을 위임하지 않을 것이다. 뷰가 컨트롤러에 그냥 위임하게 되면 컨트롤러에 뷰의 사정이 들어가게 된다. (네이티브 분리가 안 된다. ex_ dom을 컨트롤하는 로직 등등..)

mvc패턴을 날로쓰면 컨트롤러가 반드시 특정 뷰와 강력한 바인딩이 되어서 뷰를 교체할 수 없다.
강력한 바인딩을 해제하기 위해서는 컨트롤러에게는 순수한 데이터 관련된 요청만 시켜야하고 나머지 인터렉션은 뷰가 가져갸아한다.
- mvp나, mvvm을 쓰면된다.
view에서는 인터렉션 1차 처리를 한다. event listener같은 로직을 넣고,
컨트롤러에는 순수한 데이터만 보낼 것