[Java] SOLID - 객체 지향 설계 원칙

SOLID

객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙

 

 

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

모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 한다

 

책임은 변경하려는 이유이다. 어떤 클래스나 모듈은 변경하려는 단 하나의 이유만을 가져야 한다.

 

문서를 작성하고 출력하는 모듈의 경우, 문서를 변경하는 경우와 문서를 흑백이나 출력하는 경우 이렇게 변경될 수 있다. 단일 책임 원칙에 의하면 이 경우는 두 책임이 있기 때문에 문서를 작성하는 모듈과 출력하는 모듈로 나눠야 한다.

 

클래스를 한 관심사에 집중하게 하면, 편집 과정에 변경이 일어나도 같은 클래스에 있는 출력 코드에 영향을 미칠 영향이 감소한다.

 

 

OCP (개방-폐쇄 원칙, Open Closed Principle)

소프트웨어 개체(클래스, 모듈 함수 등)는 확장에 대해 열려 있어야 하고 수정에 대해서는 닫혀 있어야 한다

 

한 모듈을 수정할 때, 그 모듈과 연관된 다른 모듈도 수정해야 한다면 소프트웨어를 수정하기 어렵다. 개방-폐쇄 원칙이 잘 지켜졌다면 기능을 추가하거나 변경할 때 이미 있던 원래의 코드를 변경하지 않아도 새로운 코드를 추가함으로써 기능의 추가와 변경이 가능하다.

 

개방-폐쇄 원칙을 적용함으로써 객체 지향 프로그래밍의 장점인 유연성, 재사용성, 유지보수성 등의 이점을 얻을 수 있다.

 

확장에 대해 열려 있다

모듈의 동작을 확장할 수 있다는 것을 뜻한다. 요구사항의 변경이 있다면, 변경에 맞춰 새로운 동작을 추가하여 모듈을 확장하여 모듈을 변경할 수 있다.

 

수정에 대해 닫혀 있다

모듈의 소스 코드나 바이너리 코드를 수정하지 않아도 모듈의 기능을 확장하거나 변경할 수 있다. 모듈의 실행 가능한 바이너리 형태나 라이브러리(.jar과 같은)를 건드릴 필요 없다.

 

 

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

프로그램의 객체는 프로그램의 속성(정확성, 수행하는 업무)을 깨뜨리지 않으면서 하위 타입의 인스턴스로 교체할 수 있어야 한다

 

하위 클래스는 인터페이스의 규약을 지켜야한다. 숫자를 더해야 하는 규약이 하위 클래스에서 숫자를 빼는 방식으로 정의되어서는 안 된다. 더하거나 빼도 컴파일이 가능하지만, 수행하는 업무를 지키지 않았다.

 

 

ISP (인터페이스 분리 원칙, Interface Segregation Principle)

클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다

 

큰 덩어리의 인터페이스들을 구체적이고 작은 단위들도 분리시켜 클라이언트들이 필요한 메서드들만 이용할 수 있게 한다. 이런 작은 단위들을 'Role Interface'라고도 한다.

인터페이스 분리 원칙을 통해 내부 의존성을 약화시킬 수 있다. 이렇게 함으로써 리팩토링, 수정, 재배포이 쉬워지는 장점이 있다.

 

 

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

프로그래머는 추상화에 의존해야지 구체화에 의존하면 안 된다

 

클래스에 의존하지 말고 인터페이스에 의존해야 한다. 상위 모듈은 하위 모듈에 의존해서는 안 된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다. 추상화는 세부 사항에 의존해서는 안 되고, 세부사항이 추상화에 의존해야 한다.

 

의존성 주입은 이 원칙을 따르는 방법 중 하나이다.

 

<출처>

• 위키백과 - SOLID
• 위키백과 - 개방 폐쇄 원칙
• 위키백과 - 리스코프 치환 원칙
• 위키백과 - 의존관계 역전 원칙
• 위키백과 - 인터페이스 분리 원칙
• 위키백과 - 단일 책임 원칙