컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위
.war, .jar, .dll, .exe 등을 컴포넌트라 할 수 있다.
어떤 클래스를 어느 컴포넌트에 포함시켜야 할까?
컴포넌트 응집도와 관련된 세 가지 원칙이 있다.
REP: 재사용/릴리스 등가 원칙
재사용 단위는 릴리스 단위와 같다.
컴포넌트 버전 관리도 제대로 하고,
구성 요소도 목적이 같은 것들만 넣으라는 뜻.
CCP: 공통 폐쇄 원칙
동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라.
서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라.
SRP에서 단일 클래스에 변경의 이유가 여러 개 있어서는 안 된다고 하듯이,
CCP에서도 단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안된다고 하는 것.
CRP: 공통 재사용 원칙
컴포넌트 사용자들을 필요하지 않은 것에 의존하게 강요하지 말라.
강하게 결합되지 않은 클래스들을 동일한 컴포넌트에 위치시키지 말라는 뜻.
ISP에서 사용하지 않은 메서드가 있는 클래스에 의존하지 말라고 하듯이,
CRP에서도 사용하지 않은 클래스를 가진 컴포넌트에 의존하지 말라고 하는 것.
원칙들 사이의 균형
REP와 CCP는 컴포넌트를 크게 만들고, CRP는 작게 만든다.
크게 만들수록 사소한 변경에 너무 많은 컴포넌트가 영향을 받는다.
작게 만들수록 불필요한 릴리스가 너무 빈번해진다.
프로젝트 초기에는 CCP가 REP보다 훨씬 중요하다.
개발 가능성이 재사용성보다 더욱 중요하기 때문.
프로젝트가 성숙하고, 그 프로젝트로부터 파생된 또 다른 프로젝트가 시작되면,
REP가 점점 더 중요해진다.
아이템과 인벤토리 구현 방법 탐색
아이템과 인벤토리 구현
무난하게 마인크래프트식 인벤토리 구현하는 것으로 결정
아이템 클래스 선언
// 아이템 종류 등록
// Inventory List에 저장되는 Item class에 할당됨
// 각 아이템 프리팹의 ItemObject 스크립트에 할당됨
public class ItemTypeSO : ScriptableObject
{
public string title;
public bool stackable;
public Sprite sprite;
}
public class ItemHoldInfo
{
ItemTypeSO type;
public int quantity = 0;
public bool isInToolbar = true;
public int invenIndex = 0;
}
// 데이터 : ItemHoldInfo List를 EasySave로 저장
// 런타임 : Inventory 스크립트의 ItemHoldInfo List
// UI : List 업데이트 시 함께 업데이트
// 습득, 폐기 이벤트 >> 런타임 업뎃 후 UI 업뎃
// 저장 >> 런타임에 있던 걸 데이터에 저장
대충 이런 느낌. 매뉴얼 서술이 애매해서
Easy Save가 SO Reference를 잘 저장해줄지 걱정이긴 한데
문제되면 바꿔도 될듯.