(정리 필요)
public -> inspector 로 하겠다
public : 설정한 요소 유니티에서 보임
---------------------------------
🌱 수준별 특강 – 자연어 기반 객체지향 설계 실습
📌 핵심 목표
- 기획 내용을 구어체로 듣고 → 객체지향 구조로 설계하는 직관과 감각 키우기
- 구조 설계를 통해 유지보수 쉬운 코드를 만드는 연습
- 설계 철학과 실습을 통해 클래스와 메서드의 자연스러운 분리 체득하기
🎯 실습 흐름 요약
1. 구어체/자연어 기획 → 구조로 해석
- 예시: "플레이어가 검으로 적을 베고 보스를 쓰러뜨린다"
⬇️
명사(객체 후보): 플레이어, 검, 적, 보스, 스테이지
동사(기능): 베다, 쓰러뜨리다, 이동하다
2. 명사/동사 → 클래스/메서드 후보 도출
- 명사 기준:
- 행동 수행하는가?
- 상태를 가지는가?
- 게임 내 실체가 있는가?
- 여러 개 존재 가능한가?
- 동사 기준:
- 실제로 하는 일인가?
- 반복성, 시점성, 호출 가능성 있는가?
- 상태가 아닌가?
❗ 점수, 체력, 위치 등은 속성(Field)
❗ isJumping, isDead 등은 상태 값
🔧 객체-기능 매핑 실습 예시
"플레이어가 상점에서 아이템을 구매하고 인벤토리에 장착한다."
- 객체: Player, Shop, Item, Inventory
- 메서드 후보: BuyItem(), EquipItem(), AddToInventory()
- 구조 고민 포인트:
- Shop이 아이템을 생성할까?
- Inventory는 Player의 필드일까, 별도 관리될까?
🧠 객체지향 설계 철학
SOLID 원칙
- SRP: 클래스는 하나의 책임만
- OCP: 확장엔 열려, 변경엔 닫혀
- LSP: 부모 대체 가능성
- ISP: 불필요한 인터페이스 구현 X
- DIP: 추상화에 의존할 것
🎯 책임 분리 기준 (Fire() 메서드 예시)
- 재사용 가능성: 적/보스/플레이어 모두 사용 → 무기로 분리
- 내부 상태 보유: 탄창, 쿨타임 등 있음
- 복잡도: 산탄/연사/조건 분기 많음
- 독립 테스트: 무기만 따로 테스트 가능
🔹 따라서 Weapon.Fire()로 분리!
🧩 클래스 이름 설계 팁
단순 이름보다 책임이 보이는 이름이 좋음!
접미사 예시
- Manager: GameManager, QuestManager
- Handler: InputHandler, WeaponHandler
- Controller: PlayerController, UIController
- Spawner, Generator, Factory, Provider, Service 등
주의: Manager 클래스 남발 X, 세분화해 책임을 나누자
💬 결론
- 설계는 코드 이전의 해석 과정이다.
- 구조를 보면 흐름이 보이고, 협력이 드러나야 한다.
- 객체는 역할(책임), 메서드는 기능, 둘의 관계성이 구조 설계의 핵심이다.