좋은 객체지향이란 무엇일까? (SOLID 원칙)

지난번 포스트를 통해 우리는 객체지향을 이루는 4가지 특징에 대해 알아보았습니다.

좋은 객체지향이란 무엇일까? - 1

오늘은 로버트 마틴에 의해 명명된 SOLID 설계 원칙에 대해 알아보도록 하겠습니다.

SOLID는 유지 보수와 확장에 용이하며 객체지향을 좀더 객체지향스럽게 하기 위한 5가지 설계 원칙입니다.

• Single Responsibility Principle (단일 책임 원칙)

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

SRP 적용 전 Car 클래스는 여러 책임을 가집니다.

SRP 적용 후 Car 클래스를 단일 책임에 분리

이는 흔히 하나의 함수는 하나의 기능만을 가지고 있어야한다로 오해하는데 사실 해당 클래스를 변경하는 이유는 단 한 가지 여야 한다가 맞습니다.

하나의 클래스가 2가지의 메서드를 가진다고 해서 단일 책임 원칙을 위반하는것은 아닙니다.

단일 책임 원칙이 잘 적용된 클래스는 코드 변경(수정)의 이유가 단 한가지입니다.

즉 특정 기능을 수정할 때 하나의 클래스만 수정하면 되기 때문에 유지보수가 편리해지고 사이드 이팩트에 대한 위험을 최소화합니다.

과도한 단일 책임 원칙 고려는 너무나 세분화된 클래스로 인해 설계가 힘들 수 있습니다.

• Open/Closed Principle (개방-폐쇄 원칙)

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

OCP 적용 전 FileStorage 클래스는 MongoDB를 추가하려면 클래스가 수정되어야 합니다.

OCP 적용 후 MongoDB를 추가하고 싶다면 FileStorage를 상속받은 후 save 메서드를 재정의하면 됩니다.

프로그램의 모듈에 수정을 가할 때 그 모듈을 사용하는 다른 모듈을 모두 고쳐야 한다면 이와 같은 프로그램은 수정하기가 어렵습니다.

개방-폐쇄 원칙이 잘 적용된 클래스는 기능을 추가하거나 변경해야 할 때 기존의 코드를 변경하지 않고 새로운 코드에 새로운 코드를 추가함으로써 추가와 변경이 가능해야 합니다.

이는 주로 추상화와 다형성을 활용하여 설계가 되며 과도한 개방-폐쇄 원칙은 불필요한 복잡성을 유발할 수 있습니다.

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

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

LSP가 잘 지켜졌다면 FileStorage 클래스 MySQL 클래스로 변경해도 잘 동작해야합니다.

상위 타입의 객체를 하위 타입의 객체로 변경해도 기능에 이상이 없어야 합니다.

리스코프 치환 원칙가 지켜지지 않는다면 다형성에 기반한 개방-폐쇄 원칙 역시 위반하는 것이기 때문에, 해당 원칙을 지키는 것이 중요합니다.

그렇기 때문에 상위 클래스를 상속한 하위 클래스는 상위 클래스와 같은 방식으로 동작해야 합니다.

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

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

ISP가 잘 안지켜진 설계로 인해 Car 클래스는 fly라는 불필요한 메서드를 구현해야 합니다.

ISP 적용 후 각 클래스는 구현 가능한 메서드만을 가지게 되었습니다.

인터페이스 분리 원칙은 많은 기능을 가진 인터페이스는 작은 단위로 분리시킴으로써 클라이언트에 필요한 인터페이스만 구현하도록 해야 합니다.

이렇게 분리된 인터페이스는 응집력이 높으며 단일 책임 원칙과 비슷한 목표를 가집니다.

다만 단일 책임 원칙은 클래스에 해당되지만 인터페이스 분리 원칙은 인터페이스와 관련이 있습니다.

인터페이스 분리 원칙 또한 과도한 설계는 클라이언트에게 혼동을 줄 수 있습니다.

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

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

DIP 적용 전 뺄셈을 추가하고 싶다면 Calculator 클래스를 수정해야 합니다.

DIP 적용 후 CurrentOperation이라는 클래스에 의존하기 때문에 Calculator는 구현체에 의존적이지 않습니다.

의존 관계에서는 변경 가능성이 낮은 곳에 의존해야 합니다.

의존관계 역전 법칙을 지킴으로써 상위 클래스의 구체적인 구현이 아닌 추상화(인터페이스)에 종속적으로 만들어 하위 모듈에 대한 상위 모듈의 종속성을 줄일 수 있습니다.

 

 

결론적으로 SOLID 원칙은 High conhesion, Low coupling 즉 높은 응집도와 낮은 결합도를 바탕으로 유지보수에 용이한 코드를 설계하는것이 목적입니다. 

 

 

구독과 좋아요 그리고 생산적인 댓글은 언제나 환영입니다.