개인 과제 피드백

클래스끼리 역참조 하는것이 나쁜건 아니지만 관리의 적인 측면에서 어려울수 있어 중관 관리자를 하나 만드는게 좋습니다.

역참조 : 서로가 서로를 참조 / 스크립트들이 서로를 다 알고 있음
=> 코드가 변경되거나 오류가 생길 때 어디서 나는지 알기 어려움.
그래서 중간관리자를 만들어서 걔만 감시하는 게 코드를 관리하기 좋다.

• 조금 더 객체별 기능 구분을 하시면 관리가 더 편하실것 같습니다.

• MonoBehaviour를 상속받은 클래스는 new키워드를 사용하시면 안됩니다.

아이템뿐만 아니라 정보의 처리는 중요한 역할입니다.
정보를 객체 개체의 개념과 함께 사용하시기 보다는 정보는 정보의 역할만으로 사용하고 객체가 정보를 포함하시는 방식을 사용하시면 좋습니다.
=> 데이터와 객체를 분리해서 사용하는 것이 좋다.
//아이템 정보는 고윳값이고, 그걸 활용하는 객체를 만들어서 사용해야 한다.
이번 프로젝트에서는 아이템 SO - 아이템 객체 - 슬롯 순으로 포함되어야했다.

• 프리팹에서의 참조 설정은 충분히 고민 하신것과 같이 프리팹 단위로 묶어서 처리 하시면 됩니다.
  find나 getchild를 사용하셔도 좋지만 그럴때는 충분한 네이밍규칙을 설정하시면 좋습니다.

팀 프로젝트 피드백 정리

• 폴더 정리를 잘 해야한다.
  Resources 폴더 자체를 뭔가 저장하는 폴더로 사용하면 나중에 빌드했을 때 용량이 커진다. 실제로 동적으로 불러와야할 애들만 넣어놓는 편이 좋다.
  => 스크립트는 애초에 같이 빌드되서 상관없음. 프리팹이나 스프라이트 이런 거(동적으로 로드해야할 데이터 집단들)

• 태그 검사를 해보는 것보다 내가 원하는 컴포넌트를 가지고 있는지 한번 검사해보는게 더 효율적이다.(TryGetComponent)

• 한 클래스 안일지라도 데이터를 처리하는 부분을 처리하는 부분을 따로 만들고, UI를 최신화 하는 부분을 따로 만드는게 좋다.

• 자주 사용되는 변수에 관해서는 캐싱을 진행하자.

• WayPoint로 이동하는 부분을 보면 캐릭터를 이동시키는 코드에서는 정지나 목적지에 도착하는 부분을 정확하게 해주어야함. 그런 부분에서 도착 좌표를 equal로 하는 것보다 일정 범위로 하는 것이 좋음.
  => 보통 거리를 검사하는게 많음.

• 사용하지 않는 유니티 메시지(Start Update)는 지워주는게 좋다.

• 무기한 대기하며 검출하는 것 보다는 특정한 시점에 동작할 수 있도록 작성하는 게 좋다.

디자인 패턴 특강

우리가 기본적으로 하는 패턴 - 캐릭터가 인터페이스를 상속 받는 구조
문제점 : 간단하고자 해서 한 작업인데 많이 추가되면 코드가 복잡해지고 추가될때마다 일이 늘어난다.

전략 패턴 - 캐릭터의 변수로 인터페이스를 가진다.

디자인 패턴 - 프로그램 구조를 만들 때 자주 발생하는 문제에 대한 해결 방법
장점
1. 작업 시 어떤 문제가 발생하는 지 체크
2. 이름을 가지고 있다. (정말 큰 장점 : 패턴의 이름만으로 어떤 기능인지 알 수 있다.)

옵저버 패턴 - 특정 객체의 상태를 체크, 변화가 있을 때 옵저버들에게 전달하는 패턴

상태패턴 - 객체의 상태가 변경될 떄 행동도 변하게 적용하는 패턴
씬 관리에 적용하기에도 괜찮음.

Factory : 부모 클래스에서 객체를 생성하지만, 어떤 객체를 생성할지는 자식 클래스에서 결정.

졸아서 후반에는 제대로 못 들었다...