절차지향?
코드가 길어질 수록 가독성이 저하된다.
데이터를 배열로 저장할 시, 데이터 추가에 불리
코드를 유지 보수하는 데 불리하다.
객체 지향
객체? -> 연관된 데이터를 묶는다.
플레이어, 몬스터를 클래스로 만들어 따로 관리하면
코드가 간결해지고 가독성이 증가한다.
몬스터 1, 2를 만든다고 할 때, 새로운 몬스터 클래스를 새로 생성하면 된다. -> 재활용하기 좋다.
코드 분리:
목적에 맞게 기능을 분리하여 코드를 관리.
협업 시 팀원간 작업 영역을 분리 가능하다.
객체 지향 5 원칙!
추상화
다형성
상속
캡슐화
단일 책임의 원칙
개방 폐쇄의 원칙
리스코프 치환 원칙
인터페이스 분리 원칙
의존관계 역전 원칙
단일 책임의 원칙 :
아이템 장착 기능은 어디에 넣을까?
플레이어? 아이템? 인벤토리?
아이템의 경우, 아직 플레이어가 얻지 못한 아이템도 있을 수 있다! 때문에 여기서 장착 관리를 하는 것은 바람직하지 못함!
플레이어의 경우, 가능할 수 있으나, 플레이어의 다른 기능들까지 합쳐지면 코드가 너무 길어질 가능성이 있다.
때문에 인벤토리에서 장착 관리를 하는 것이 바람직하다. -> 소지중인 아이템에 대한 관리 기능을 인벤토리에 넣자. -> 단일 책임!
개방 폐쇄의 원칙 :
확장은 개방, 수정은 폐쇄!
