[S/E] 좋은 객체 지향 설계의 5가지 원칙 : SOLID 원칙

SOLID

이 밤의 끝을 잡고 ~

클린 코드로 유명하신 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리 한 것

---

SRP : Single Reponsibility Principle - 단일 책임 원칙

하나의 클래스는 하나의 책임만 가져야한다 -> 하나의 책임이라는 것은 모호하다 -> 클 수도 있고 작을 수도 있다

중요한 기준은 변경 -> 변경이 있을 때 전체 프로젝트에 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것

ex) UI 변경, 객체의 생성과 사용 분리

---

OCP : Open/Closed Principle - 개방 - 폐쇄 원칙

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

기능을 확장하려면 코드가 변경해야하지 않을까? 

다형성으로 해결 -> 인터페이스를 구현한 새로운 구현체를 만들어 새로운 기능을 구현하자 -> 기존 코드변경 없이 구현체 갈아끼우기만 하면 된다.

즉, 역할과 구현의 분리를 명확히 하여 설계하는 것이 중요하다

public interface Database{
	void method();
}

public class MemoryDb implements Database{
	void method(){
    	System.out.println("이것은 메모리 데이터베이스입니다");
	}
}

public class FileDb implements Database{
	void method(){
    	System.out.println("이것은 파일 데이터베이스입니다");
	}
}

public static void main(String[] args){
	//Database currentDb = new MemoryDb; // 구현체를 추가하여 다형성으로 확장 -> 데이터베이스 변경
    Database currentDb = new FileDb;
}

근데 사실 위 예제를 보면 기존 MemoryDb를 주석 처리하고 FileDb로 갈아끼움으로써 클라이언트 코드를 수정해버렸다. -> 요게 문제점

이 문제를 해결하기 위해선, 객체를 생성하고 관리하고 연관 관계를 맺어주는 별도의 조립자 혹은 설정자가 필요하다 -> 이게 스프링 컨테이너!

---

LSP : Liskov Substituion Principle - 리스코프 치환 원칙

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위타입의 인스턴스로 바꿀 수 있어야한다.

-> 다형성에서는 하위 클래스는 인터페이스 규약을 필히 지켜야한다.

예를들어 자동차 인터페이스가 있고, 앞으로 가라는 엑셀 메서드가 있을 때, 그 메서드를 뒤로 가게끔 구현하면 컴파일 오류는 없지만 LSP를 위반하게 된다.

즉, 인터페이스를 구현한 구현체를 믿고 사용하려면 LSP원칙이 반드시 필요하다.

---

ISP : Interface Segregation Principle - 인터페이스 분리 원칙

특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다

예를 들어 자동자 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리 / 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리

하여 관리하면 인터페이스가 명확해지고, 특정부분 변경이 필요할 때 적은 변경으로 기능을 수정할 수 있게 된다.

---

DIP : Dependency Inversion Principle - 의존 관계 역전 원칙

개발자는 추상화에 의존하고, 구체화에 의존하면 안된다

쉽게 얘기 해서, 클라이언트 코드가 구현체를 바라보지 말고, 그 인터페이스를 바라보도록 하라 ! -> 의존성 주입

위 모든 내용과 비슷한 맥락으로, 인터페이스를 의존 하게끔 설계가 되어야 추후 구현체를 유연하게 변경이 가능하다. (ex. 자동차에 의존해야지, 정확한 모델에 의존하면 안된다)