2018년 10월 1일

CodeSpitz78 4/ OOAD와 테트리스 (1)

🌕🌑🌑

🔥 코드스피츠 수업을 수강하면서 복습한 내용을 정리했습니다. OOA, OOD까지만의 내용만 다루었습니다. 강의와 추가로 찾아본 자료와 섞여있습니다.

1. 개요 ### 1-1 OOAD? 개념 (Object-Oriented Analysis and Design) 소프트웨어를 개발하는 하나의

방법론으로 모든 소프트웨어 시스템의 주요 기본요소를 사물을 가리키는 객체와 그 객체들을 하나의 집합으로 묶은 클래스로 구성하는 객체지향적인 분석과 설계 방법을 말한다. 객체지향적이란 것은 현실세계에 실재하는 사물, 즉 객체들을 지향한다는 것이다.

OOA: 분석하자
OOD: 설계하자
OOP: 프로그래밍 하자

1-2 객체 지향의 키워드

1-2-1 클래스 class => 추상 (abstract)

클래스는 추상, 오브젝트는 클래스가 실체로 만들어진 것

클래스 클래스는 표현 대상들의 공통적인 특징에 대한 서술(추상)을 말한다

추상 추상은 사용자가 구체적인 내용을 생각하지 않고도 사용할 수 있는 기능

프로시져 추상화 Procedural abstraction : 함수
데이터 추상화 Data abstraction : 구조체, 배열, 포인터

1-2-2 오브젝트 object => 실체 (instance)

오브젝트는 클래스의 인스턴스이다. 오브젝트는 instance of class => 클래스가 실체로 만들어진 것.

오브젝트는 데이터와 데이터에 대한 조작의 묶은 것
오브젝트 모양은 클래스에 서술되어 있다.

cf__ 다양한 용어지만 같은 뜻

attribute = data = member variables = state = field
behavior = operation = member function = method
클래스 class = 개념 concept = 타입 type
객체 object = 실체 instance = 변수 variable

1-2-3 캡술화 encapsulation

데이터와 (data) 데이터를 다루는 방법을 (operation on data) 묶는 것

관련 있는 것을 묶어서 이름을 부여한 것 => 추상화
객체지향에서 객체끼리 지켜야할 최소한의 룰 은닉: 숨기다.
- 어디까지 안보여주는 거지?
- 이상적인 은닉: 아무것도 안보여주겠어!
- 언어 차원에서도 강제로 뜯어볼 수 없는 장치를 마련했으면 좋겠다.
- 옵셔널하게 지원하는 기능: 데이터 하이딩을 직접 지원에서 내부를 볼 수 없게 한다. (언어마다 다르다.) 캡슐화
- 은닉과 상관없다.
- 몰라도 되게 만들고 싶은 것.
- 자세히 알면 독이 되기 때문.
- 가장 모르는 수준까지만 알려준다.
- 추상화된 행위만 알려준다.
- 예_ ATM 기계

최대한 은닉하고 최대한 캡슐화해서 상대방과 대화한다.

솔리드 원칙
헐리우드 원칙 (참고 )
드라이 원칙
…

1-2-4 상속성 inheritance

하나의 클래스가 가지고 있는 특징들(데이터 + 조작)을 그대로 다른 클래스가 물려 받는 것

상속성은 계보(계층의 의미도 있다.)
재사용과 유연성
대체 가능성
자식이 부모를 대체할 수 있다.
자바스크립트 : prototype chain을 이용해 상속 ⇒ 대체 가능성을 구현한다. (__proto__)
Chaining 시스템으로 대체가능성을 구현할 수 있기 때문에 자바스크립트도 객체지향을 지원한다고 얘기할 수 있다.

1-2-5 다형성 polymorphism == 내적 동질성

상속성의 계층을 따라서 각각의 클래스에 한가지 이름을 줄 수 있다.

같은 명령을 각기 다른 오브젝트에 줄 수 있다.


Dog d;
d = new Poodle()
d.bark()
 
d = new Bulldog()
d.bark()
 
d = new Husky()
d.bark()

처음 만들어졌을 때 원형이 누구냐에 따라서 오버라이드 되어있거나 오버라이딩 된 속성을 반드시 만들어진 구상객체를 사용하도록 되어있다.

cf__ 메세지 전달 message passing 객체지향관점에서 프로그램은 오브젝트에 message를 보내는 것으로 실행

실제 구체적 동작과 관계없이 객체와 객체에 대한 상호작용 관점을 제공..

객체지향 프로그래밍은 패러다임(관점) 중 하나이다.

구조적 프로그래밍 (파스칼, C)
객체지향 프로그래밍 (자바, C++)
명령형 프로그래밍 (파스칼, C, …)
선언형 프로그래밍 (SQL, 프롤로그)
함수형 프로그래밍 (하스켈, 리스프)
객체기반 (자바스크립트, 에이다,)
이벤트 드리븐 프로그래밍
절차적 프로그래밍
…

1-3. 객체지향 분석 및 설계 1. 문제영역에서 배우(actor)를 찾아내고 2. 각 배우들의 책임과 역할을

정의하고 3. 배우들간의 관계를 지정하고 4. 각 배우들에 대한 대본(script)를 쓴다.

👇

식별하고
일반화하고(object, class),
대상들 간의 관계 (inheritance, embedded)를 설정하고,
상호작용 하도록(behavior)한다.

👇

도메인 => 도메인 개념의 시각화 => 설계 객체를 구현

use case 정의

요구분석

도메인 모델 정의

문제영역 분석 및 표현
객체지향분석은 영역객체를 분류하는 관점에서 관심영역을 기술하는 것과 연관
도메인 : 해결하고자 하는 대상 영역 =>
소프트웨어는 도메인의 문제를 해결하기 위한 수단
추상화

인터렉션 다이어그램 정의

상호협력 관계 표현

설계 클래스 정의

난감한 도메인을 만났을때 우리는 어떻게 데이터 분석을 해서 처리할 수 있는가 ⇒ 데이터 분석의 결과가 객체지향이 될 수 있게 하는 것이 우리의 목표

2. 추상화 Abstraction

: 대상에서 특징만 뽑아낸 것 : 사람은 상징체계를 만들고, 발전시켜 다음 세대애 물려준다. (=> 추상화 능력) 객체지향은 기본적으로 추상화 라는 영역에 속해 있다.

2-1. Categraization 분류를 일정한 기준으로 묶어 놓는 것. 디테일을 숨기고 카테고리의 특징만

뽑아내서 이해하게 된다.

2-2. 모델링 현실세계에 있는 실물에서 내가 기억해야할 것들을 모아 놓은 것.

모델링에서 가장 중요한 것

이 도메인에서 꼭 기억해야할 게 모지? 를 먼저 정해야한다.
how? 도메인에서
데이터 분석
을 통해서 반드시 기억해야만 하는 후보를 정하는 행위 ⇒ 모델링
기억해야만 할 특징을 정의하는 행위

2-3. 집합 - 가장 기초적인 추상화 - 그냥 모아놨기 때문에 카테고라이제이션이라고 하지 않는다. -

무작위 적인 그룹핑을 시킬 수 있다.

3. 테트리스 OOAD 카테고라이제이션으로 관리할 수 있나? 그냥 그룹화해서 관리할 수 있나? 본인이

역할(role)과 책임이 있나? 권한과 책임을 일치하게 나눌 수 있냐..

cf__설계시 유의해야할 점

simplex: 의존성이 한쪽 (단방향 참조)
multiplex: 의존성이 양쪽 (양방향 참조)

- 혹시나 하는 의존성을 찾기 위해서 전체 그림을 그려본다. - UML - 설계시에는 simplex를 유지하자.

인지하기 쉬운 객체 찾기

DATA (프로토콜)

Render와 게임정보 사이의 프로토콜 역할
상호 간에 약속한 형태(프로토콜)를 끠어넣으면 둘 사이의 의존성이 줄어들게 된다.
프로토콜 = 의정서, 합의서, 약정서
게임본체와 렌더러는 서로 몰라도 되고, 프로토콜만 알면 된다.
1. Game 게임본체: stage + score + block + 범용패널 을 포함한다.
- Stage: 현재 스테이지 정보
- Score: 점수 및 계산법
- Block: 다양한 타입의 블록
- 범용패널
  - 시작화면
  - 종료화면
  - 죽음
  - 클리어
  - 결과화면
1. 범용 렌더링 처리기 Renderer : 데이터를 받아서 그리는 역할
- Table 렌더러
- Canvas 렌더러