스프링에서 사용하는 좋은 객체지향 원칙

◈ 좋은 객체지향 원칙 5가지 ◈

지금 소개할 것은 SOLID 라는 객체지향 원칙입니다.

이 원칙은 스프링에서 뿐만 아니라 객체지향 개발을 할때 알아두면은 도움이 될 것입니다.

①. SRP (Single Responsibility principle) 단일 책임 원칙

②. OCP (Open / Closed Principle) 개방-폐쇄 원칙

③. LSP (Liskov Substitution Principle) 리스코프 치환 원칙

④. ISP (Intterface Segregation Principle) 인터페이스 분리 원칙

⑤. DIP (Dependency Inversion Principle) 의존관계 역전 원칙

위 5가지에 원칙에 대해서 알아보도록 합니다.

 

▶ SRP (단일 책임 원칙) 이란? ◀

Single Responsibility Principle 의 약자인 SRP 단일책임 원칙이란 간단하게 말해서 1개의 Class는 하나의 책임만 가지고 있어야 한다.

그럼 여기서 책임이란 무엇을 뜻하는가? 라는것이 생각이 들것이다. 

책임은 그때 상황에 따라 책임이 클수도 있고 작을 수도 유동적일 것이다 그럼 어떠한 기준으로 SRP 원칙 을 잘 지켯다고 말할 수 있을까?

어떠한 작업이 UPDATE가 되엇을 시점에 판단을 할 수가 있다. 예로 들어 A라는 Class 파일을 수정해야 하는 상황이 오면은 그 수정한 A.Class 파일로 인해 다른 Class파일들까지 영향이 미치는 것 이 적으면은 단일 책임 원칙을 잘 수행 한 것이다.

그와 반대로 1개의 Class 파일을 고쳣을뿐인데 여러 파일에서도 문제가 생기면은 단일 책임 원칙을 위반 한것이다.

 

▶ OCP (개방-폐쇄 원칙) 이란? ◀

개방-폐쇄 원칙에는 다형성을 이용하는 것이다. 확장에는 OPEN 되어 있지만 수정에는 CLOSE 되어 있다 라고 생각하면 좋다. 

확장에는 열려있고 그게 아닌 변경되는 시점에는 닫혀있어야 한다? 이게 무슨 어이없는 말인가 예시로 간단하게 이해를 해보자

나(클라이언트) 는 명품브랜드에 옷을 입고 있다고 생각해보자. 여기서 다른 옷을 입고 싶어질때 다해져있는 품질을 옷입으라고 했을때 어느 누가 명품브랜드를 입다가 싸구려 옷을 입는것을 좋아 하겠는가? 이같은 경우에 다른 옷을 입을려고 하는 행위를 확장 이라고 할 수 있다. 그렇다면 확장 하는데에는 매우 문제가 될 것이다.

그와 반대로 

나(클라이언트) 는 추상적인 옷(Interface) 에만 의존하고 있다고 생각해보자.

그렇다면 나(클라이언트)는 명품옷을 입든 싸구려입을 입든 언제든지 다른 옷으로 대체 가능한 상황이 되는 것이다. 

즉 나(클라이언트) 는 옷(Interface) 라는 것에만 바라보고 있고 옷(Interface)은 다른 옷을 입히고 싶은 것(구현된 클래스) 만 만들면 언제든지 유연하게 확장이 가능한 것이다.

 

▶ LSP (리스코프 치환 원칙) 이란? ◀

리스코프 치환 원칙은 간단하게 생각해볼 수 있다.

위의 OCP(개방-폐쇄 원칙) 원칙은 Interface를 바라보고 있고 해당 Interface는 특정 기능을 구현된 Class파일들이 있을 것이다.

여기서 LSP(리스코프 치환 원칙)을 잘 지켯을때와 원칙을 위반 했을때의 차이점을 알아보자.

※ LSP(리스코프 치환 원칙)을 잘 시켯을 경우 ※

축구선수 라는 인터페이스가 있다고 생각했을때 발로 공을 차다 라는 기능을 선언하고 구현된 기능 Class파일은 축구공을 차는 기능을 만들었을 것이다.

이경우에는 리스코프 치환 원칙을 잘 짙켯다고 할 수 있다.

※ LSP(리스코프 치환 원칙) 위반 ※

리스코프 치환 원칙을 위반 하는경우는 간단하다. 축구선수 인터페이스에서 발로 축구공을 차는 기능을 선언 후 

구현하는 Class파일에서 축구공을 손으로 던지는 기능을 만들 경우에 리스코프 치환 원칙을 위반 하는 것이다.

해당 목적을대로 기능을 만들어야 한다.

 

▶ ISP (인터페이스 분리 원칙) 이란? ◀

인터페이스를 분리시킨다는 것이 무엇을 말하는건가? 여기서 객체지향이라는 개념도 생각하면 좋다.

인터페이스란 간단히 말해 기능들의 집합소 라고 생각해보자. 지하철이라는 인터페이스안에는

교통카드 라는것이 있을 수 도 있고 지하철운행 이라는 것도 있을 수도 있고 수없이 많을 것이다.

여기서 인터페이스를 분리를 시켜보자. 교통카드라는 인터페이스는 이에 관련된 요금,벌금 등같은것만

관련된 기능들이 있을 것이고,

지하철 운행이라는 인터페이스는 지하철 운전, 기사관리, 급행, 같은 지하철운행에 관한 수많은 기능들이 있을

것이다. 여기서 이러한 모든 기능들을 1개의 인터페이스에서 관리한다고 했을때 무척 골치가 아플 것이다.

이러한 골치아픔을 피하기 위해 각각의 인터페이스를 분리를 시켜놓으면은 어떠한 수정이 일어낫을때 해당 인터페이스만 수정하면 되니깐 관리하기에 아주 편리 해질 것이다.

 

▶ DIP (의존관계 역전 원칙) 이란? ◀

위에서 말한 OCP(개방-폐쇄 원칙)을 다시 생각해보자.

간단하게 설명해자면 클라이언트는 인터페이스의 구현객체를 알면 안된다는 뜻이다.

클라이언트는 오로직 인터페이스에만 의존 하도록 잘 설계하여 만들어야 하는 것이다.

 

☞ 부족한 설명이나 잘못된 부분은 댓글로 언제나 환영입니다. ☜