🐥 좋은 객체 지향 설계의 5가지 원칙 SOLID

👨‍💻 로버트 마틴이 정리한 좋은 객체 지향 설계의 5가지 원칙

🤔 들어가면서...

스프링이 나오기 전에 EJB(Enterprise java Beans)라는 컴포넌트 기술을 사용하였습니다.

많은 이용자수를 감당할 수 있다는 장점을 가지고 있지만, 매우 무겁기때문에 오타하나를 바꾸려고해도 소스를 찾기 어렵고, 서버를 한번 내렸다가 올리는데 10분이상이 걸리기 때문에 개발자가 많이 힘들었다고 합니다.😥

이런 EJB의 단점을 해결하기 위해 로더존슨은 EJB가 없어도 충분히 확장 가능한 웹 애플리케이션을 개발할 수 있음을 보여주는 예제 코드를 발표하게되고, 그의 책을 읽고 감명받아 유겐흴러와 얀카로프 주도로 오픈소스를 만들어보자!!한것이 Spring 입니다.🌼

그렇다면 spring을 왜쓸까? Spring framework는 좋은 객체지향설계의 5가지 원칙을 따르고 있어 객체지향 특징을 살릴수 있기 때문입니다. 오늘은 그 객체지향설계의 5가지 원칙이 무엇인지 알아보고자 합니다.

✔ SRP(Single Responsibility Principle): 단일 책임 원칙

클래스를 변경하는 이유는 단 한 가지여야 한다. ( 로버트 C. 마틴)

1. 한 클래스는 하나의 책임만 가져야 한다. 클래스에 많은 책임이 있는 경우 책임 중 하나를 변경하면 사용자가 모르는 사이에 다른 책임에 영향을 줄 수 있으므로 버그가 발생할 가능성이 높아지기 때문입니다.
2. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 따르고 있다는 것 입니다. 반면에 너무 종속적이라서 연쇄적으로 바뀌면 단일책임 원칙에 위배됬다고 할 수 있다.

✔ OCP: 개방-폐쇄 원칙 ⭐중요⭐

소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만 변경에 대해서는 닫혀 있어야 한다. ( 로버트 C. 마틴)

이렇게만 말하면 이해하기가 어려우니 예시를 한번 살펴봅니다.

• 변경전 코드입니다. MemberRepository라는 부모클래스를 통해 MemoryMemberRepository라는 메모리에 저장하는 구현된 객체가 있다고 가정합니다.

public class MemberService{
private MemberRepository memberreRepository = new MemoryMemberRepository();
//      ----------------                          -------------------------
// 부모클래스 or 인터페이스                           메모리에다 저장하는 구현체
}

시간이 흘러 이제부터는 DB에다가 저장하는 형태로 바꾸기로 했습니다. 이제 개발자가 수정하려고 하겠죠? 아래는 변경후 코드입니다

public class MemberService{
private MemberRepository memberRepository = new JdbcMemberRepository();
}

여기서 보면 딱 MemoryMemberRepository()를 JdbcMemberRepository()로 클래스이름이 바뀌었습니다.
다형성을 사용했는데 (= 확장은했지만) 코드에 변경이 일어난 상태에 라서 개방 폐쇄의 원칙 위배된다고 볼 수 있습니다.

이에 대해서는 객체를 생성하고, 연관관계를 맺어주는 별도의 설정자가 필요합니다. 스프링의 '의존성 주입'이라는 기능을 사용하는 것이 바람직하다고 합니다.

✔ LSP: 리스코프 치환 원칙

S가 T의 하위 유형이면 프로그램에서 자료형 T의 객체는 해당 프로그램의 원하는 속성을 변경하지 않고 자료형 S의 객체로 교체(치환)할 수 있어야 한다. - 바바라 리스코프(Babara Liskov)
자식 클래스는 부모 클래스를 대체할 수 있어야 한다. - 로버트 C마틴

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

2. 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원
   칙, 인터페이스를 구현한 구현체는 믿고 사용하려면 이 원칙이 필요합니다.

핵심은 부모 클래스를 사용하는 위치에 자식 클래스를 대신 사용했을 때 코드가 원래 의도대로 작동해야 한다는 것을 의미합니다.
모든 하위클래스가 상위 클래스와 동일한 방식으로 동작해야 합니다.
위반사례 예시) 직사각형을 상속한 정사각형 클래스 : Rectangle 객체를 Squear로 대체하면, 정사각형 특징때문에 넓이 결과가 다르게 나올 수 있습니다. 정사각형은 직사각형일 수 있지만 Squere 객체는 Rectangle 객체가 아닙니다. 이는 Square 객체의 동작이 Rectangle 객체의 동작과 일치하지 않기 때문입니다.

✔ ISP: 인터페이스 분리 원칙

클라이언트는 사용하지 않는 인터페이스에 강제로 의존해서는 안된다. -로버트 C. 마틴
1. 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
인터페이스하나를 바꾸려면 하위 클래스가 모두 바뀌여야하기 때문에 기능이 여러개면 인터페이스를 나누는게 좋다.

2. 여러개의 인터페이스로 나누면 인터페이스가 명확해지고, 대체 가능성이 높아짐

ISP는 인터페이스가 응집력 측면에서 작게 분할하여 클래스가 필요한 작업만 실행하도록 하는 것을 목표로 합니다.
ISP는 단일 책임 원칙(SRP)와 거의 비슷한 목표를 가지고 있습니다.
둘의 차이점은 SRP는 클래스와 관련된 반면 ISP는 인터페이스와 관련되어 있다는 것입니다.

✔ DIP: 의존관계 역전 원칙💖

1. 상위 모듈은 하위 모듈에 의존해서는 안 되고 둘 다 추상화에 의존해야 한다.
2. 추상화는 세부 사항에 의존해서는 안 되고 세부사항(구체적인 구현)은 추상화에 의존해야 한다. -로버트 C.마틴

1. 추상화에 의존해야하고, 구체화에 의존하면 안됨

2. 구현 클래스에 의존하지 말고, 인터페이스에 의존

예를 들면 실제 상황에서 회의할때
기획자:" 남자에게만 메일시스템으 보내볼까?"
개발자왈:"이거 하려면 다뜯어고쳐야해!"
이렇게 되면 안된다는 뜻입니다.

어떤기능을 바꿔서 해보자 라고할때 어떤 인터페이스와 클래스를 떼다 수정한걸 넣었을때 정상적으로 동작하도록 만들어야 합니다.
특정 클래스가 너무 의존적이라 다른 것을 수정해야한다면 의존성 역전 원칙에 위배됩니다.
DIP는 상위 모듈을 구체적인 구현이 아닌 추상화(인터페이스)에 종속적으로 만들어 하위 모듈에 대한 상위 모듈의 종속성을 줄이는 것을 목표로 합니다.
DIP를 지키면 종속성을 줄일 수 있기 때문에 유지관리 및 수정이 쉬운 코드를 작성할 수 있게 됩니다.

🥴 결론

✔ 다형성 만으로는 OCP, DIP를 지킬 수 없음
✔ 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경
✔ 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발 할 수 없음

🍪 좋은 객체지향 개발을 하기위해 여러가지 프로그램을 경험하면서(EJB) OCP, DIP를 지키면서개발을 했더니 결국엔 spring framework가 만들어 지더라!

reference

https://yoongrammer.tistory.com/97