[Spring] Spring 핵심원리 5가지 원칙 ( SOLID )

참조출처 : 김영환님의 스프링 핵심 원리 - 기본편

 

1. 5가지( SOLID ) 원칙은 무엇인가

S ( Single Responsibilty Principle / SRP ) : 단일 책임의 원칙

O ( Open-Close Principle / OCP ) : 개방 - 폐쇄 원칙

L ( Liskov Subsitution Principle / LSP ) : 리스코프 치환 원칙

I ( Interface Segretation Principle / ISP ) : 인터페이스 분리 원칙

D ( Dependency Inversion Principle / DIP ) : 의존관계 역전 원칙

 

2. 항목별 설명

1) Single Responsibilty Principle / SRP : 단일 책임의 원칙

- 간단 요약 :

하나의 클래스는 하나의 책임을 가져야 한다.

 

- 설명 :

하나의 클래스, 메서드는 각자 하나의 책임을 가져야 한다.

새로운 기능이 추가되거나 수정되어야 할 때 변경, 추가 사항(파급효과)이 적다면 하나의 책임을 갖는다고 본다.

 

- 나의 생각 :

느슨한 결합을 목적으로 클래스, 메서드를 설계해야 한다.

하지만 이 책임(역할)의 의미가 모호하다

혹 여러 기능이 클래스, 메서드 내에 존재하게 되면 해당 기능에 엮인 다른 클래스와 메서드를 찾아 모두 수정해야 하고

그럴 경우 해당 클래스, 메서드를 사용하는 다른 곳의 동작을 예측하기 쉽지 않다.

그리하여 어떠한 기능( 계산기 클래스의 plus메서드 와 같은 ) 별도의 기능별 클래스, 메서드로 분리하는 것이 좋다.

plus기능의 수정이 발생하면 계산기 클래스의 plus메서드만 수정하면 되기에 수정으로 인한 파급효과가 적다고 본다.

 

2) Open-Close Principle / OCP : 개방 - 폐쇄 원칙

- 간단 요약 :

확장에는 열려있고 변경에는 닫혀있어야 한다.

 

- 설명 :

하나의 기능을 추가할 때 기존 코드의 변경 없이 수정 및 추가가 가능해야 한다.

interface 등을 이용하여 추상화하고 구현체를 직접 사용하는 것이 아닌 interface와 같이 추상화된 클래스를 사용하여 요구 사항에 따라 구현체를 선택하여 사용할 수 있다.

 

- 나의 생각 :

추상화와 다형성에 관한 이야기로 해석된다. 

예를 들어 같은 기능이지만 필요에 의해 분리, 혹은 기능에 추가가 이루어져야 할 때 if문 등으로 하나의 클래스, 메서드에서 분리하거나 호출하지 않고 interface를 구현한 구현체를 변경 호출하여 기존 코드의 변경을 없이 새로운 기능으로 필요에 의해 바꿀 수 있다.

기존 구현체에는 변경 사항이 없음으로 해당 구현체를 사용하던 코드들에 영향은 없으며 새로운 기능이 필요한 곳에서만 변경된 기능을 적용할 수 있다.

 

3) Liskov Subsitution Principl / LSP : 리스코프 치환 원칙

- 간단 요약 :

interface를 상속하는 자식(구현체)은 규약을 지켜야 한다.

 

- 설명 :

객체 지향 프로그래밍에서 interface의 구현체를 치환하여도 문제가 없어야 한다.

단순히 컴파일 과정에서의 오류를 이야기하는 것이 아닌 기능의 신뢰와 일관성에 관한 이야기이다.

 

- 나의 생각 :

interface를 사용하여 추상화하면 다형성을 가져갈 수 있지만 구현체들은 interface의 규약을 지키며 개발해야 한다.

interface를 사용한다는 건 해당 구현체의 상세한 코드를 모르더라도 interface에 정의된 메서드는 어떠한 결과를 반환한다는 규약이 있다.

해당 규약을 지키지 않게 되면 interface를 신뢰할 수 없으며 구현체 간의 전혀 다른 결과 ( A를 원했지만 Z를 반환하거나 실행될 때 )는 일관성을 잃게 된다.

 

4) Interface Sergegation Principle / ISP : 인터페이스 분리 원칙

- 간단 요약 :

구현체는 자신이 구현하지 않는 interface는 사용하지 말아야 한다.

 

- 설명 :

interface는 여러 기능을 포함하여 범용 interface를 보단 단일 기능을 갖는 interface를 여러 개 생성하고 각 기능에 맞는 구현체를 생성해야 한다. 

기능별로 분리된 interface는 역할이 명확해지고 의존성이 낮아져 수정 및 추가로 인한 파급효과를 줄인다.

 

- 나의 생각 :

3번 LSP에서도 interface를 상속한다면 규약을 지켜야 한다.

허나 자신이 구현하지 않는 ( 규약을 지키지 않는 ) interface를 상속받는다면 일관성이 깨지게 된다.

또한 해당 클래스는 여러 역할(책임)을 갖게 될 확률이 높다.

추상화의 신뢰와 다형성의 자유(?, 표현할 적절한 단어를 못 찾겠다)를 가져올 수 있다.

 

5) Dependency Inversion Principle / DIP : 의존관게 역전 원칙

- 간단 요약 :

구현체에 의존하지 말고 추상화에 의존해야 한다.

 

- 설명 :

구현체에 의존하게 되면 해당 구현체에 존속적이게 되며 수정 및 추가가 어려워진다.

구현체보다 규약을 지킨 interface에 의존해야 변경 및 추가에서 자유롭고 결합도가 낮아진다.

즉, 변경에 유연해진다.

 

- 나의 생각 :

추상화와 다형성에 관한 이야기

객체, 메서드 간 결합도는 느슨해야 하며 느슨하다는 건 유연하다는 것이고 유연하다는 건 변경 및 추가에 비용이 적게 든다는 것이다.

 

3. 종합적인 생각 

1~5번까지의 내용이 말하는 결론은 서로에게 연결되어있고 연관된 내용들이라고 본다.

객체지향은 객체, 메서드가 각자 명확한 하고 특정 역할만을 가져야 하며 해당 객체, 메소들의 조합을 통해 원하는 큰 기능이 완성된다.

또한 이 기능은 언제든 변할 수 있으며 그 변화를 용이하게 하기 위해 규약을 지킨 인터페이스 등으로 추상화하며

이렇게 추상화된 설계는 유연하고 그 유연함은 다형성을 사용함에 자유를 가져다준다.