Solid 원칙
1. SRP (단일책임의 원칙) -> 클래스는 자신의 이름이 나타내는 일을 할것
2. OCP (개방폐쇄의 원칙) -> 확장에는 개방, 수정에는 폐쇄
3. LSP (리스코브 치환의 원칙) -> 부모와 자식관계는 서로 치환가능해야한다(base.~~을 사용가능해야함)
4. ISP (인터페이스 분리의 원칙) -> 두개 이상의 인터페이스가 공유하는 부분의 재사용 극대화, 서로다른 인터페이스는 명백히 분리
5. DIP (의존성역전의 원칙) -> 추상화에 의존하도록 해야한다.
위의 solid원칙은 좋은 초기 설계에서부터 매우 중요하다. 개발 도중 또는 후에 기획자로부터 내용 수정을 요구받는다면 이를 쉽고 간단하게 수정할 수 있어야 한다. 하지만 초기부터 위 solid원칙을 지키지 않는다면 무척 괴로운 시간을 보내게 될 것이다.
결국은 코드 확장과 유지보수 관리를 위해 단순/추상적인 코드를 짜기 위한 원칙이라고 봐야한다.
개발에 중요한 것은 객체에 생성, 연결, 동작이 필요하다는 것이다 객체가 만들어지고 각각이 연결되며 그에 따른 동작도 시켜야한다. 거의 모든 기능들은 위에 세가지가 들어가있다
이건 생성패턴, 구조패턴, 행위패턴으로 명칭을 붙일 수 있다.
여기에 디자인 패턴이 적용되어야 한다. 프로그램의 의존성을 낮추고 응집도롤 높여야 더욱 효율적이기 때문이다. 이런 디자인패턴은 위에 작성한 solid원칙에 입각하여 만들어진 것이다.
컴포지션 패턴
등등.....
오늘 실습때 사용했던 코드 일부를 첨부하겠다.
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public enum ItemRef
{
HP,
MP,
SP,
WEAPON
}
public interface IUse
{
public void UseItem(Player player);
}
public interface IWeapon
{
public void SetItem(Player player);
}
public class Item : MonoBehaviour
{
public int value = 1;
public string _name = "포션";
public virtual void Sound()
{
Debug.Log("효과음");
}
}
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class HpItem : Item, IUse, IWeapon
{
public void SetItem(Player player)
{
player.hp += value;
}
public void UseItem(Player player)
{
player.weapon = this.gameObject;
}
public override void Sound()
{
base.Sound();
Debug.Log("특수효과");
}
}
public class Player : MonoBehaviour
{
(중략)
private void OnTriggerEnter2D(Collider2D collision)
{
if (collision.TryGetComponent(out Interaction interaction))
{
interaction.ShowInteraction();
if (collision.TryGetComponent(out IUse component))
{
useItem = component;
}
}
if (collision.TryGetComponent(out IWeapon weapon))
{
weapon.SetItem(this);
}
SetUI();
}
}
아이템과 mp아이템, 플레이어의 스크립트이다
각각의 스크립트는 서로 분리되고, 내부에서 자기가 할 일만을 하고있다.
동시에 상속관계를 가진 item과 mpitem은 solid 원칙을 매우 잘 준수하고있다.
이건 확장성 증가에 큰 도움이 될 수 있다고 생각한다.
sound()메서드를 보면 단순한 기능 구현을 간단히 할 수 있다는 것을 볼 수 있다.