SOLID 원칙 중 OCP(개방-폐쇄 원칙)
SOLID 원칙 중 하나인 OCP(개방-폐쇄 원칙)에 대하여
OCP란?
SOLID 원칙 중 OCP(Open-Close-Principle) 개방 폐쇄 원칙은 기존 코드를 수정하지 않고 확장할 수 있도록 설계해야 한다는 설계의 원칙 중 하나입니다.
소프트웨어의 구성요소(클래스, 함수, 모듈 등)의 확장에는 열려있어야 하며, 수정에는 닫혀 있어야 한다는 것인데요
이렇게만 이야기하면 너무나도 어렵습니다. 확 다가오지도 않구요.
간단하게 말해서 어떠한 클래스에 새로운 기능이 추가될 때, 기존 코드를 수정하는 일이 발생하다면
OCP 원칙을 위반하는 것입니다.
저는 처음에 이 말을 들었을 때
어떻게? 라는 생각밖에 들지 않았습니다.
매번 초기에 스프린트하게 진행되는 프로젝트들만 즐비하게 진행해왔는데
빠르게 진행되는 것이 초기 자본없는 스타트업의 비극(?)이기에 이러한 경험을 하지 못했는데요.
새로운 취업을 진행하다가 한 회사에 과제를 진행하다가 해당 원칙에 대해서 공부하게 되면서
앞으로 코딩을 어떠한 방향으로 진행해야되겠다라는 방향을 세울 수 있었습니다.
아래의 내용은 OCP에 대해서 공부한 내용입니다 :)
피드백은 언제나 환영합니다!
abtract class PaymentProcessor {
abstract fun processPayment(amount: Double)
}
위의 추상 클래스는 결재의 방식을 확장 가능하도록 구조를 정의하는 클래스입니다.
이렇게 추상 클래스를 생성해서 상속받아서 기본 구조를 생성한 후,
class CreditCardPayment: PaymentProcessor() {
override fun processPayment(amout: Double) {
//TODO 신용카드 결제 방식 프로그래밍
}
}
class KakaoPayment: PaymentProcessor() {
override fun processPayment(amout: Double) {
//TODO 카카오페이 결제 방식 프로그래밍
}
}
class CryptoPayment : PaymentProcessor() {
override fun processPayment(amount: Double) {
//TODO 암호화폐 결제 방식 프로그래밍
}
}
위와 같이 결재 방식별로 컴포넌트 클래스를 생성한 후,
@Service
class PaymentService {
fun payment(processor: PaymentProcessor, amount: Double) {
processor.processPayment(amount)
}
}
위와 같이 결졔 서비스를 담당하고 있는 서비스 클래스를 생성해 줍니다.
@Service
class anyService(
private val paymentService: PaymentService
) {
fun main(method: PaymentMethod, amount: Double) {
val processor = when(method) {
CREDIT_CARD -> CreditCardPayment()
BITCOIN -> CryptPayment()
}
paymentService.makePayment(processor, amount)
}
}
위와 같이 OCP를 준수하여 프로그래밍을 한다면, 기존 구조의 코드를 수정하지 않고 새로운 기능을 추가할 수 있습니다.
예를 들어 페이팔로 결재하는 기능이 추가되야 된다면, 새로운 클래스인 PaypalPayment 클래스를 생성한 후,
기본 결재 구조체인 ProcessorPayment를 상속 받아 기능을 구현하면 됩니다.
이렇게 유연한 설계로 유지보수성이 향상되고, 추상 클래스를 활용하여 확장에 대한 가능성을 제공해줍니다.
또한, 기존 코드에 대한 수정이 불필요하게 될거구요!
실제 현장에서는 조금 다를 수 있겠지만, 이러한 코드를 바탕으로 프로그래밍을 해야할 것 같습니다!
물론 이렇게 작성하려면 기획에 대한 충분한 이해가 기반되어야 할 것 같습니다!