Swift) SOLID 원칙 in Swift

SOLID 원칙이란 ? 

 

SOLID 원칙이란 객체지향 설계에 더 좋은 아키텍쳐를 설계하기 위해

지켜야하는 원칙들의 5가지를 앞의 약어만 따서 정리한 단어입니다. 

 

 

SOLID 원칙을 왜 알아야하죠 ? 

 

개발을 할 때 당장 기능을 구현하는 것도 중요하지만,

새롭게 어떤 기능이 추가되거나 유지보수가 필요할 때

더욱 생산성 있고 유연하게 대처가 가능해야 좋겠죠.?

 

이러한 좋은 설계를 위한 최소한의 원칙들을 정리한게 SOLID 원칙이라고 

할 수 있는데요.  VIPER나 MVVM도 모두 이런 원칙에 입각해서 만들어졌다고 합니다.

 

 

SOLID 원칙을 적용하여 설계하면 !

 

1. 재사용과 유지관리가 쉬운, 변경에 유연한 코드를 가지게 됩니다.

이는 튼튼한 소프트웨어를 만들 수 있게 하며 높은 확장성을 가지게 합니다.

2. 높은 응집력과 낮은 결합도 ( High Cohesion, Low coupling ) 을
전공 책에서 보는게 아니고 내 코드에서 볼 수 있다 ! 

 

 

 

추가적으로, Swift 에서도 SOLID 원칙을 알고 적용해야되는 이유 ? 

 

Swift는 멀티패러다임 언어이지만 Foundation , UIKit 등 

코코아터치 프레임워크들은 기본적으로 OOP에 근간을 두고 있다고 합니다. 

SOLID 원칙을 제대로 알고 있다면 평소에 쓰고 있는 클래스들이

왜 이런식으로 만들어졌는지 알수있고 앞으로 우리가 작성할 코드에

어떻게 녹여낼수 있을지 파악할 수 있겠죠 ! 

 

처음부터 코드를 잘 짤수는 없겠지만,

최소한 잘못된 코드가 어떤건지를 알고 피해가자 ^^_ 라는 컨셉 

 

그러면 5가지 약어에는 어떤 것들이 있고,

Swift 언어에는 어떻게 적용이 될까요 ?

 

 

알아보러 가봅시당.

 

---

1. SRP(Single Responsibility Principle) - 단일 책임 원칙

 

클래스나 함수를 설계할 때, 각 단위들은 단 하나의 책임만을 가져야한다는 원칙 !

 

하나의 클래스가 많은 메서드 및 역할을 가지게 된다면 ? 

클래스 내부 함수끼리 강한 결합이 발생할 수 있습니다.

 

클래스 내에서 수정 및 추가를 진행할 때,

가독성 저하 및 유지보수 비용 증가 등의 문제가 발생하겠죠.. 

 

각 클래스 별로 책임을 적절하게 나눠서

응집도는 높고 결합도는 낮은 프로그램을 설계하는게 단일 책임 원칙 !

 

SRP의 가장 대표적인 위반 사례는 Massive View Controller 현상입니다.

요거 많이 들어봤죠..? 이런 MVC의 문제를 해결하기 위해

MVVM, MVP, VIPER 등 여러 다른 패턴들이 생겨나고 시도되고 있는데,

그것들의 공통점은 너무 많은 역할을 하고 있는 뷰컨트롤러를 쪼개서

단일 책임만을 가지는 여러 클래스를 만들려고 하는 것입니다 ! 

 

SRP를 지키기 위해 당장 시도해볼 수 있는 것 ? 

클래스를 작게 만들자 ! 

사실 클래스가 작다는 것이 SRP의 충분조건은 아니지만, 필요조건입니다 !

 

갑자기 스쳐지나가는 앱잼 프로젝트...

스위프트 린트에 10-200룰을 적용해놨던... 

10-200룰이란 함수는 10줄 이내, 클래스는 200줄 이내로 만드는 것입니다.. 

 

앱잼 정도의 프로젝트는 큰 무리없이 가능했지만

가끔 기능이 많았던 뷰컨은 .. 커밋이 안되가지구 끙끙 리팩토링 했었는데 

이런 큰 그림이 있었다니.. 

 

함수는 10줄 룰을 지키려면 함수는 하나의 작업만 해야된다 !!

라는 원칙을 지킬 수 밖에 없고 추상화 레벨에 대해 고민을 하게 됩니다.

작업(함수)을 어느 수준까지 쪼개서

설명(추상화)할 것인지에 대해 고민을 하게 만들어 줍니다.

 

‘클래스는 200줄’ 룰을 지키려면 프로퍼티나 함수, 메서드를

그냥 손이 가는 곳 아무데나 만들어서 쓸 수 없습니다.

꼭 얘가 이 곳에 있어야 하는 이유를 찾아야 하고,

해당 클래스에 있을 이유가 없으면 SRP 위반이다.

 

가장 쉽게 판단할 수 있는 방법 하나는, 함수나 메서드 내부에서

self의 프로퍼티나 메서드를 얼마나 쓰고 있는지 보는 것이라고 합니다.

 

만약 하나도 쓰고 있지 않다면 그 클래스 안에 있을 이유가 전혀 없는 것이라고 

생각해도 되겠죠..? 아무래도..? 

 

또는 self의 호출 빈도가 적을수록 클래스와 연관성이 떨어지는 것이니

나중에 클래스를 리팩토링 하거나 다이어트 시켜야 할 상황이 오면 우선적으로 내쫓을 후보로 

점찍어두는 그런... 것이죠 ! 

 

SRP는 모든 패턴의 시작이라고 합니다. 

SRP를 제대로 지키지 못한 채로 코딩을 하면

그 어떤 패턴을 도입해보려고 해도 잘 안될 가능성이 높다고 합니다.

어메메 SRP라도.. 일단.. 아좌좌

 

클래스는 하나의 역할만 해야한다는 것,

객체지향을 배우면서 가장 먼저 배우는 원칙임에도 정말 지키기 쉽지 않은 것 같네요 !

 

 

예시 코드 

 

나쁜 예시 

class LoginService {
    func login(id: String, pw: String) {
        let userData = requestLogin()
        let user = decodeUserInform(data: userData)
        saveUserOnDatabase(user: user)
    }
    
    private func requestLogin() -> Data {
        // Call API
        return Data()
    }
    
    private func decodeUserInform(data: Data) -> User {
        // Decoding User Inform from Data
        return User(name: "", age: 10)
    }
    
    private func saveUserOnDatabase(user: User) {
        // Save User
    }
}

위의 LoginService라는 클래스 내부에서 

API 호출, 디코딩, 유저 데이터 저장 등 여러가지 역할을 하고 있네요 ! 

즉, 클래스 내부에서 하나의 책임이 아닌 여러책임을 동시에 지고 있다고 할 수 있습니다 

 

좋은 예시

protocol APIHandlerProtocol {
    func requestLogin() -> Data
}

protocol DecodingHandlerProtocol {
    func decode<T>(from data: Data) -> T
}

protocol DBhandlerProtocol {
    func saveOnDatabase<T>(inform: T)
}

class LoginService {
    let apiHandler: APIHandlerProtocol
    let decodingHandler: DecodingHandlerProtocol
    let dbHandler: DBhandlerProtocol
    
    init(apiHandler: APIHandlerProtocol,
         decodingHandler: DecodingHandlerProtocol,
         dbHandler: DBhandlerProtocol) {
        self.apiHandler = apiHandler
        self.decodingHandler = decodingHandler
        self.dbHandler = dbHandler
    }
    
    func login() {
        let loginData = apiHandler.requestLogin()
        let user: User = decodingHandler.decode(from: loginData)
        dbHandler.saveOnDatabase(inform: user)
    }
}

위의 나쁜 에시와 비교해서 각각 DB, Decoder, APIHandler 역할을 하는

프로토콜을 만들어주고 각자의 역할만하는 메소드만을 구현하게 하였습니다.

그리고 LoginService에서는 단지 이 프로토콜들을 활용해서 상호작용만을 하고 있습니다.

 

이전과 비교해서 확실히 LoginService는 로그인에 관련된 로직만을 다루는데

각각의 모듈들을 활용해서 로그인에 관한 책임만을 가지고 있다는 것을 알 수 있습니다.

 

 

---

 

 

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

 

확장에는 열려있으나 변경에는 닫혀있어야한다는 원칙 

 

확장에 열려있다 ? 클래스의 기능을 확장하는 것이 쉬워야된다.

변경에는 닫혀있다 ? 기존에 구현되어 있는 것들을 바꾸지 않고 클래스를 확장할 수 있어야한다.

 

즉, 어떤 기능을 추가할 때 기존의 코드는 만지지 않고 새로 동작하는 기능에 대해서만

코드가 작성이 되어야합니다.

요구사항의 변경이나 추가사항이 생기더라도 기존 구성요소는 수정하지 않고,

필요한 기능만 확장을 통해서 재사용 할수 있게 !! 

 

이러한 특성들은 추상화를 통해서 이루어질 수 있습니다 !

스위프트에서 추상화는 주로 Protocol을 통해 이루어집니다 !!

 

 위의 SRP 예제처럼 프로토콜을 이용해서

구현한다면 로직에서 변경사항이 있을 때 각각의 프로토콜을 구현하고 있는 객체를 외부에서 주입하면

되기 때문에 새로운 기능에도 변화없이 대응이 가능하게 됩니다.!

 

OCP를 잘하기 위해서는 변하지 않을 본질적인 특징 (인터페이스) 와 

다른 요소로부터 식별될 수 있는 객체의 본질적인 특징 (추상화)를 잘 구분하는 것이 중요 !

 

OCP 위반의 대표적인 예는 어떤 타입에 대한 반복적인 분기문이다. 

즉, 하나의 enum에 대해 여러 군데에서 반복적으로 if/switch 문을 쓰고 있다면

고민을 해봐야한다. 왜냐하면, 이런경우에 기능 추가는 case를 한줄 추가하면 되니까 쉽지만

그렇게 하는 순간 해당 enum을 스위칭 하고 있는 모든 코드를 찾아서 수정해줘야한다.

 

OCP는 if/switch를 최대한 안 쓰는 방법을 통해 연습할 수 있다.

모든 분기문을 없애는 것은 불가능하고.. enum같이 타입을 분기하는 지점에 대해서 !

 

근데 이 얘기를 듣고 말도 안된다고 생각하는게 당연하다.. 

어떻게 if/switch 없이 분기를 하냐고 .. 

 

앞서 언급한 10-200룰과도 상호보완적이라는데 분기문을 없애는 것만으로도 

함수 및 클래스의 길이를 많이 줄일 수 있다.

 

if/switch 문을 대체할 수 있는 방법 2가지 

1. protocol을 만들고 상속받아 쓰는 방법 - 직접적으로 OCP를 지키는 구조

2. 간단하게 딕셔너리를 활용하는 방법 - OCP를 지키는 구조는 아니지만, 분기문을 없애고 싶을떄 

제한적으로 사용하면 좋다. 

 

예시코드 

1번 프로토콜 활용 !

 

첫번째 예시 - 동물

기존코드 

class Dog {
    func makeSound() {
        print("멍멍")
    }
}

class Cat {
    func makeSound() {
        print("야옹")
    }
}

class Zoo {
    var dogs: [Dog] = [Dog(), Dog(), Dog()]
    var cats: [Cat] = [Cat(), Cat(), Cat()]
    
    func makeAllSounds() {
        dogs.forEach {
            $0.makeSound()
        }
        
        cats.forEach {
            $0.makeSound()
        }
    }
}

이렇게 된다면 새로운 동물이 생겼을 때 Class로 새롭게 정의하고 

Zoo에 또 기존 코드를 수정하게 됩니다. 새로운 동물에 맞는 메서드를 추가해줘야겠죠.. ! 

이렇게 불필요한 메서드들이 늘어나게 됩니다.

 

또, 여기서 dog 클래스의 makeSound() 라는 메서드를 변경하게 되면,

이제는 dog 클래스에 없는 메서드이기 때문에 Zoo class에서

dogs.makeSound() 부분은 에러가 나게 됩니다.

 

문제 : 클래스를 수정하면 메서드를 계속 수정해야되고, 비슷한 형태의 메서드가 계속 추가되기도 합니다.

그렇다면 클래스의 본질적인 특징 + 확장되는 부분을 어떻게 구분하는게 좋을까요?

 

protocol Animal {
    func makeSound()
}

class Dog: Animal {
    func makeSound() {
        print("멍멍")
    }
}

class Cat: Animal {
    func makeSound() {
        print("야옹")
    }
}

class Zoo {
    var animals: [Animal] = []
    
    func makeAllSounds() {
        animals.forEach {
            $0.makeSound()
        }
    }
}

스위프트에서는 변하지 않는 부분을 프로토콜을 사용하여 

인터페이스화 합니다. 변하는 부분은 각 클래스별로 프로토콜을 채택해 구현해주면 되겠죠.

 

이렇게 프로토콜을 활용해서 설계를 진행하게 되면 새롭게 동물이 추가되어도

기존의 코드는 만지지 않고 그저 class 새로운동물: Animal으로 선언하여

구현만하면 될 것 같습니다. 그렇게 되면 Zoo 클래스에서는 기존의 메서드를 수정할 필요 없이

새로운 동물들을 추가하여 함수를 동작할 수 있게 될 것입니다.

 

결론적으로 프로토콜은 변경에 닫혀있기 때문에 makeSound() 라는 메서드를 수정할 필요가 없고

새로운 동물이 추가되는 상황에서는 확장에 열려있다고 할 수 있습니다 ! 

 

 

2번 딕셔너리 활용 ! 

앞서 설명에서 분기문을 없애고 싶을때가 있다면 , 요렇게 딕셔너리를 사용해보면 좋을 것 같네요 ! 

switch reason {
  case .initializing:
    self.instructionMessage = "Move your phone".localized
  case .excessiveMotion:
    self.instructionMessage = "Slow down".localized
  case .insufficientFeatures:
    self.instructionMessage = "Keep moving your phone".localized
  case .relocalizing:
    self.instructionMessage = "Move your phone".localized
}

//적절한 곳에 딕셔너리 생성
let trackingStateMessages: [TrackingState.Reason : String] 
                         = [.initializing.        : "Move your phone".localized,
                            .excessiveMotion      : "Slow down".localized,
                            .insufficientFeatures : "Keep moving your phone".localized,
                            .relocalizing         : "Move your phone".localized]

//switch문 대체
self.instructionMessage = trackingStateMessages[reason]

 

3번 추가 예시 

 

1번 예시에 OCP를 적용해보면, 이렇게 변하지 않는 부분은 프로토콜로 선언해주고,

각 종류별 핸들러에서 프로토콜을 채택하여 구현해줄 수 있습니다. 그리고

LoginService에서 필요한 타입의 apihandler를 사용할 수 있습니다 ! 

protocol APIHandlerProtocol {
    func requestAPI()
}

class getHandler: APIHandlerProtocol {
    func requestAPI() {
        print("getHandler")
    }
}

class postHandler: APIHandlerProtocol {
    func requestAPI() {
        print("postHandler")
    }
}

class putHandler: APIHandlerProtocol {
    func requestAPI() {
        print("putHandler")
    }
}

class APIService {
    var apiHandler: APIHandlerProtocol

    init(handlerType: APIHandlerProtocol) {
        apiHandler = handlerType
    }
    
    func requestAPIByHandler() {
        apiHandler.requestAPI()
    }
}

import UIKit

class ViewController: UIViewController {


    override func viewDidLoad() {
        super.viewDidLoad()
        let someService = APIService(handlerType: getHandler())
        someService.requestAPIByHandler()
        
        someService.apiHandler = putHandler()
        someService.requestAPIByHandler()
    }
}

 

 

---

 

 

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

 

부모클래스로 동작하는 곳에서 자식클래스 인스턴스를 넣어주어도 대체가 가능해야한다는 원칙

자식 클래스를 구현할떄, 기본적으로 부모 클래스의 기능이나 능력들을 물려받습니다.

여기서 자식 클래스는 동작을 할때 부모 클래스의 기능들을 제한하면 안된다는 뜻 ! 

 

즉, 부모 클래스의 타입에 자식 클래스의 인스턴스를 넣어도 똑같이 동작하여야 합니다.

 

자식클래스가 부모클래스의 기능을 오버라이딩해서 기능을 변경하거나 제한하는 경우에 

결과값이 다르게 나오므로, LSP 원칙을 위반한 것입니다. 

 

 

전형적인 위반 사례로는 직사각형을 상속받아서 만든 정사각형 클래스를 생각하면 됩니다! 

정사각형은 너비와 높이가 같아야 하기 때문에 너비와 높이를 자유롭게 바꿀 수 있는

직사각형 부모 클래스의 동작을 제한해야만 원하는 동작을 만들 수 있습니다. 이런 경우가 LSP의 위반이다.

LSP를 지키기 위해서는 직사각형이 정사각형을 상속받거나, 아니면 너비와 높이를 아예 let으로 만들어버립시다 !! 

 

나쁜 예시

class Rectangle {
    var width: Float = 0
    var height: Float = 0
    
    var area: Float {
        return width * height
    }
}

class Square: Rectangle {
    override var width: Float {
        didSet {
            height = width
        }
    }
}

func printArea(of rectangle: Rectangle) {
	rectangle.height = 3
	rectangle.width = 6
	print(rectangle.area)
}

let rectangle = Rectangle()
printArea(of: rectangle)
// 18

let square = Square()
printArea(of: square)
// 36

실제로 정사각형은 직사각형이라고 할 수 있습니다.

이 원리에 따라 프로그램을 다음과 같이 설계하게 되면 문제가 생기게 됩니다.

didset 부분에서 부모의 프로퍼티를 오버라이딩을 통해 

변경하고 있기 때문에, 자식 인스턴스를 생성해서 

똑같은 메서드에 넣어도 다른 결과값이 나오게 됩니다 !

 

이 경우 부모의 역할을 자식 인스턴스에서 동일하게 수행하고 있지

못하기 때문에 LSP 원칙을 위반한 사례라고 할 수 있슴다 !

 

좋은 예시 

protocol Shape {
    var area: Float { get }
}

class Rectangle: Shape {
    let width: Float
    let height: Float
    
    var area: Float {
        return width * height
    }
    
    init(width: Float,
         height: Float) {
        self.width = width
        self.height = height
    }
}

class Square: Shape {
    let length: Float
    
    var area: Float {
        return length * length
    }
    
    init(length: Float) {
        self.length = length
    }
}

위와 같이 Rectangle, Square 둘다 Shape라는 프로토콜을 채택한 후, 

실제 구현부(area)를 클래스에게 넘기는 형태로 설계하면 LSP에 어긋나지 않고 프로그램을 설계할 수 있겠죠 !

Shape의 자리를 Square, Rectangle 둘 다 모두 대체가 가능하기 때문에 

LSP를 위반하지 않습니다. !

 

하지만, LSP를 절대 어기지 않고 프로그래밍을 하는건 어려운 일이라고 합니다..

하지만 너무 많은 곳에서 LSP를 어긴다면 문제가 생긴다.

 

다른 티스토리 참고... 

 

상위 클래스를 기준으로 코딩할 수 없어지고, 그렇게되면 상속 자체가 의미가 없어지고 OCP조차 지킬수 없게 된다.

예를 들어 UITableView는 UITableViewCell을 기준으로 만들어져 있기 때문에

우리가 만든 커스텀 셀이 LSP를 지키지 않는다면 테이블뷰도 제대로 동작하지 않을 것이다.

또한 protocol를 만드는 이유도 추상화된 인터페이스를 기준으로 코드를 작성하기 위해서인데

상속받은 타입이 protocol의 메서드를 퇴화시켜버리면

프로토콜을 기준으로 작성된 코드들이 줄줄이 망가질 수 밖에 없다.

 

상속은 객체 지향 프로그래밍의 중요한 부분이고 잘 쓰면 유용하지만 잘못된 상속을 만들면 문제가 발생할 수 있다.

반면 때에 따라서는 LSP를 위반함으로써 편리함과 단순함을 얻게 될 수도 있다.

 

결론적으로, LSP를 모든 곳에서 지키려고만 하면 비효율적이고

너무 자주 위반하면 예상하지 못한 결과들 때문에 안정성을 해치게 된다.

그러므로 상속을 만들때는 LSP 위반인지 아닌지를 숙지하고 사용하는 것이 좋겠다.

 

결론 : 지나친 LSP 는 비효율적이고, 지나친 LSP 위반은 안정성을 해치기 때문에

둘 사이에서 어느정도 추구할 것인지에 대한 판단이 중요할 것 같습니다 ! 

 

 

---

 

 

 

 

4. ISP(Interface Segregation Principle) - 인터페이스 분리 원칙

 

인터페이스를 일반화하여 구현하지 않는 인터페이스를 채택하는 것보다

구체적인 인터페이스를 채택하는 것이 더 좋다는 원칙

 

인터페이스를 설계할 때, 굳이 사용하지 않는 인터페이스는 채택하여 구현하지 말고

오히려 한 가지의 기능만을 가지더라도 정말 사용하는 기능만을 가지는 인터페이스로 분리하라는 것 ! 

 

뭔소리냐.. 

사용하지 않는 인터페이스는 구현하지마라 !

스위프트에서는 인터페이스를 프로토콜을 활용하여 처리하죠 ! 

 

프로토콜을 설계하다보면, 다양한 메서드가 들어가는 경우가 있습니다.

모든 객체에서 그 메서드들을 다 활용하면 상관이 없지만

몇몇개의 메서드가 필요하지 않은 경우가 있습니다.

 

이런경우에 ISP원칙을 위반했다고 보는 것입니다.

이러한 경우에는, 프로토콜 뭉치를 더욱 상세하게 분리할 필요가 있습니다 !

프로토콜을 경우에 맞게 분리한다면, 낭비하는 메서드가 없게 되겠죠 !

 

나쁜 예시 

protocol Shape {
    var area: Float { get }
    var length: Float { get }
}

class Square: Shape {
    var width: Float
    var height: Float
    
    var area: Float {
        return width * height
    }
    
    var length: Float {
        return 0
    }
    
    init(width: Float,
         height: Float) {
        self.width = width
        self.height = height
    }
}

class Line: Shape {
    var pointA: Float
    var pointB: Float
    
    var area: Float {
        return 0
    }
    
    var length: Float {
        return pointA - pointB
    }
    
    init(pointA: Float,
         pointB: Float) {
        self.pointA = pointA
        self.pointB = pointB
    }
}

Line, Square 모두 Shape을 상속받는 객체이지만

실제로 Square는 length라는 변수가 필요가 없고

Line은 area라는 변수가 필요없게 됩니다.

그럼에도 단지 Shape이라는 프로토콜을 채택한다는 이유만으로 필요없는 기능을 구현하고 있습니다.

 

이런 경우에 ISP의 원칙을 지키지 않고 있다고 할 수 있을 것 같습니다.

불필요한 메서드를 구현하지 않으려면 프로토콜을 더 상세히 분리하는게 좋겠죠 !

 

좋은 예시 

protocol AreaCalculatableShape {
    var area: Float { get }
}

protocol LenghtCalculatableShape {
    var length: Float { get }
}

class Square: AreaCalculatableShape {
    var width: Float
    var height: Float
    
    var area: Float {
        return width * height
    }
    
    init(width: Float,
         height: Float) {
        self.width = width
        self.height = height
    }
}

class Line: LenghtCalculatableShape {
    var pointA: Float
    var pointB: Float
    
    var length: Float {
        return pointA - pointB
    }
    
    init(pointA: Float,
         pointB: Float) {
        self.pointA = pointA
        self.pointB = pointB
    }
}

기존에 필요없는 기능들을 구현하고 있던 인터페이스들을 더욱 세분화하여 나누어주었습니다.

 

AreaCalculatableShape, LenghtCalculatableShape으로 각각 인터페이스를 세분화시켜

넓이를 구해야하는 Shape에만 AreaCalculatableShape 채택하여 구현하고

길이를 구해야하는 Shape에만 LenghtCalculatableShape 채택하였습니다.

각각 클래스에서 구현하지 않는 메서드가 없게 되죠 !

 

각각을 ISP의 원칙을 지키는 프로그램의 설계가 되었습니다.

이렇게 ISP의 핵심은 프로토콜의 분리라는 것을 확인할 수 있습니다 !

 

 

 

---

 

 

 

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

 

상위 모듈이 하위 모듈에 의존하면 안되고 두 모듈 모두 추상화에 의존하게 만들어야 한다는 원칙

 

클래스 사이에는 의존관계가 존재할 수 밖에 없습니다! 

의존 관계가 존재하되, 직접적으로 구체적인 클래스끼리 의존하지 말고

그 사이에 최대한 추상화된 인터페이스를 활용해 의존하라는 것이 DIP 원칙입니다 !

 

상위 모듈이 하위모듈에 의존하면 안된다는 말이 직접적으로 의존하지 말라는 말 ! 

 

추상화를 진행하여 각각의 모듈에 더 추상화된 것에 의존하게 만들어야한다는 뜻입니다. 

이렇게 코드를 설계해야 재사용에도 유용하고 하나를 수정하더라도 다른 수정사항이 

많이 없는 좋은 프로그램을 설계할 수 있게 됩니다.

 

DIP 원칙은 나중에 Unit Test를 진행할 때 더욱 중요하게 될 원칙인데 

의존성 주입이라는 개념이 나옵니다 !.

 

상위 모듈에 어떤 하위 모듈을 사용할 때, 상위모듈에서 직접적으로 

하위모듈을 초기화하지 않고 외부에서 하위모듈을 초기화 할 수 있게 하라는 뜻입니다 !

그리고 이 상위 모듈, 하위모듈을 모두 추상화된 객체에 의존할 수 있게 해야합니다.

 

나쁜예시 

class APIHandler {
    func request() -> Data {
        return Data(base64Encoded: "This Data")!
    }
}

class LoginService {
    let apiHandler: APIHandler = APIHandler()
    
    func login() {
        let loginData = apiHandler.request()
        print(loginData)
    }
}

현재 상위모듈인 LoginService가 하위 모듈인 APIHandler에 의존하고 있는 관계로

만약  APIHandler의 구현 방법이 변화하게 되면 프로그램에 영향을 미치게 되고

새롭게 LoginService라는 상위모듈을 수정해야하는 상황이 일어날 수 있습니다.

직접 APIHandler 클래스를 가져와서 의존을 하고 있기 때문에 다른 Handler가 들어오는 경우? 

직접 코드를 수정하거나 추가할 일이 많기 때문 ! 

변화에 매우 취약한 구조라고 할 수 있습니다.. 

 

이러한 상황이 DIP의 원칙을 어긴 프로그램의 설계라고 할 수 있습니다.

 

이를 수정하기 위해 의존성 주입이라는 것을 사용해서 수정해보겠습니다 

(DIP를 유지하기 위해 의존성을 역전시키기.)

 

좋은 예시 

 

protocol APIHandlerProtocol {
    func requestAPI() -> Data
}

class LoginService {
    let apiHandler: APIHandlerProtocol
    
    init(apiHandler: APIHandlerProtocol) {
        self.apiHandler = apiHandler
    }
    
    func login() {
        let loginData = apiHandler.requestAPI()
        print(loginData)
    }
}

class LoginAPI: APIHandlerProtocol {
    func requestAPI() -> Data {
        return Data(base64Encoded: "User")!
    }
}

let loginAPI = LoginAPI()
let loginService = LoginService(apiHandler: loginAPI)
loginService.login()

이렇게 작성하게 되면 LoginService는 기존에 APIHandler에 의존하지 않고

추상화 시킨 객체인 APIHandlerProtocol에 의존하게 됩니다.

 

그렇기 때문에 APIHandlerProtocol의 구현부는 외부에서 변화에 따라 지정해서 지정해주면 되기 때문에 

LoginService는 구현부에 상관없이 좀 더 변화에 민감하지 않은 

DIP의 원칙을 지킨 프로그램을 설계할 수 있게 됩니다.

 

( 프로토콜 구현부는 외부에서 처리해준 다음, 로그인 서비스라는 인스턴스를 만들 때

의존성 주입을 처리해 주기 때문에 보다 유연한 구조로 코드 작성을 할 수 있다. )

 

이렇게 외부에서 내부의 변수를 초기화해서 의존관계를 가지는 경우를 의존성 주입이라고 하게 됩니다.

이 때, 의존성 주입을 추상화시켜 진행하게 되면 더욱 변화에는 안전한 프로그램을 설계할 수 있게 됩니다.

 

protocol APIHandlerProtocol {
    func requestAPI()
}

class getHandler: APIHandlerProtocol {
    func requestAPI() {
        print("getHandler")
    }
}

class postHandler: APIHandlerProtocol {
    func requestAPI() {
        print("postHandler")
    }
}

class putHandler: APIHandlerProtocol {
    func requestAPI() {
        print("putHandler")
    }
}

class APIService {
    var apiHandler: APIHandlerProtocol

    init(handlerType: APIHandlerProtocol) {
        apiHandler = handlerType
    }
    
    func requestAPIByHandler() {
        apiHandler.requestAPI()
    }
}

import UIKit

class ViewController: UIViewController {


    override func viewDidLoad() {
        super.viewDidLoad()
        let someService = APIService(handlerType: getHandler())
        someService.requestAPIByHandler()
        
        someService.apiHandler = putHandler()
        someService.requestAPIByHandler()
    }
}

앞서 보여드린 코드에서도 의존성 주입을 해주는 부분이 있었습니다 !

이처럼 5가지의 원칙이 서로 관계를 갖고 있는 것도 있다.

ISP를 지키기 위해 결국 SRP를 지키게 된다던가.. 

 

그러나 이 원칙을 모두 지키면서 프로그램을 설계하기는 힘들다고 생각한다

다들 그렇다고 말하기도 하고,, 하지만 이걸 공부하면서, 어떤게 나쁜 코드이고 어떤게 좋은 코드인지

파악할 수 있었던 것 같다 넘 좋았다 !! 

 

 

 

 

 

 

 

예시 코드 참고 

[SWIFT] Swift SOLID 원칙

스위프트로 다시보는 객체지향 프로그래밍: 피해야할 코딩 습관 · Soojin Ro

[Design-Pattern-In-Swift] 1. SOLID 원칙을 Swift 코드에 적용해보기