[Programming] SOLID 원칙이란? (feat.iOS 개발자)

 

 

안녕하세요 Foma 입니다!

 

오늘 다뤄볼 주제는 객체지향 프로그래밍 (OOP) 에서 꼭 지켜야 하는 원칙인 SOLID 입니다.

 

SOLID를 알아보는 이유는 Swift로 개발을 하면서 클래스나 객체를 만드는 것, 캡슐화, 메서드 오버로딩 등

 

많은 OOP 개념을 사용해야 했습니다.

 

하지만 개발을 하다보면 어떤 것이 효율적인지 어떤 것이 올바르게 OOP를 지키면서 사용하는 것인지는 알지 못한채

 

그냥 코딩만 했었죠... 그러다가 우연히

 

"OOP에서 반드시 지켜야 하는 원칙이 5가지가 있는데 그것이 SOLID 원칙이라 불린다."

 

라는 것을 듣고 이게 무엇인지 그리고 왜 지켜야 하는지에 대해서 정리해보려고 합니다.

 

바로 시작 할게요~

---

SOLID 원칙은 무엇일까요?🧐

 

컴퓨터 프로그래밍에서 SOLID란 

 

로버트 마틴이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을

 

마이클 페더스가 두문자어 기억술로 소개한 것이다.

 

프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다.

 

SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지

 

소프트웨어 소스 코드를 리팩터링하여 코드 냄새를 제거하기 위해 적용할 수 있는 지침이다.

 

이 원칙들은 애자일 소프트웨어 개발과 적응적 소프트웨어 개발의 전반적 전략의 일부다. - 위키 백과 - 

 

 

즉, 한마디로 정리하면 

 

"소스 코드를 읽고 확장하기 쉽게 정리하는데 좋은 지침이다."

---

그렇다면 SOLID 란 무엇의 약자일까요?🤔

 

S

Single Responsibility Principle

단일 책임 원칙

 

O

Open Closed Principle

개방 폐쇄 원칙

 

L

Liskov Substitution Principle

리스코프 치환 원칙

 

I

Interface Segregation Principle

인터페이스 분리 원칙

D

Dependency Inversion Principle

의존관계 역전 원칙

 

이렇게 5가지 원칙이 구성되어 있고 이 원칙들의 앞글자를 따 SOLID 원칙이라고 합니다.

 

저같은 경우에는 한글로 되어있는 것도 이해하기가 힘들더라구요... 의존..관계..역전...원칙..?

 

그래서 제가 이해한 방식으로 쉽게 하나하나 풀이해보려고 합니다.

 

S - O - L - I - D 순서로 진행하겠습니다~

---

1. 각자의 책임은 각자가 지자! (SRP) 👍🏻

 

아래처럼 사장님 클래스가 있고 해야할 일들이 있습니다.

 

만약 한 사장님이 운영하고 기획하고 개발하고 디자인을 한다면 어떻게 될까요?

 

사장님이 너무 힘들어지겠죠.....

 

class 사장님 {
    
    func 운영하기() {
        
    }
    
    func 기획하기() -> 기획서 {
        
        return 기획서()
    }
    
    func 개발하기() -> 어플리케이션 {
        let 기획서 = 기획하기()
        let 디자인 = 디자인하기(기획서:기획서)
        let 앱 = 어플리케이션(기획서: 기획서, 디자인: 디자인)
        return 앱
    }
    
    func 디자인하기(기획서:기획서) -> 디자인 {
        return 디자인()
    }
    
}

만약 아래와 같이 기획하는 단계에서 플랫폼에 따라서 다른 기획서를 쓴다면

 

플랫폼이 추가될 때마다 모든 기능이 별도로 추가가 되어야 할 것입니다.

 

이렇게 하나의 기능이 바뀌었는데 모든 기능이 바뀌여야 되고 이것은 사장님 한 클래스가 한다는 것이 문제입니다.

    func 기획하기(플랫폼:플랫폼) -> 기획서 {
        if 플랫폼 == .ios {
            return iOS기획서()
        }else if 플랫폼 == .android{
            return 안드로이드기획서()
        }else{
            return 웹기획서()
        }
        
    }

 

그러니깐 기획은 기획자가 디자인은 디자이너가 개발은 개발자가 운영은 사장님이 할 수 있도록 하고

 

"각자의 책임은 각자가 지는걸로 하자" 가 바로 단일 책임 원칙이 되는거죠.

class 사장님 {
    
    let 기획자:기획자
    let 개발자:개발자
    let 디자이너:디자이너
    
    func 운영하기() -> 훌륭한 운영? {
        let 기획서 = 기획자.기획하기
        let 디자인 = 디자이너.디자인하기(기획서:기획서)
        let 어플리케이션 = 개발자.개발하기(디자인:디자인,기획서:기획서)
        let 운영 = 운영(앱:어플리케이션)
        return 운영
    }
}

class 기획자 {
    
    func 기획하기(플랫폼:플랫폼) -> 기획서 {
        if 플랫폼 == .ios {
            return iOS기획서()
        }else if 플랫폼 == .android{
            return 안드로이드기획서()
        }else{
            return 웹기획서()
        }
    }
    
}

class 디자이너 {
    
    func 디자인하기(기획서:기획서) -> 디자인 {
    	let 디자인 = 디자인(기획서:기획서)
        return 디자인
    }
    
}

class 개발자 {
    
    func 개발하기(디자인:디자인,기획서:기획서) -> 어플리케이션 {
        let 앱 = 어플리케이션(기획서: 기획서, 디자인: 디자인)
        return 앱
    }
    
}

 

---

2. 확장은 오케이. 근데 수정은 안돼!(OCP) ❌

 

아래처럼 만약 개발자가 있고 이 개발자는 iOS앱을 만들수 있는 개발자입니다.

 

struct iOS {
    var 프로젝트이름:String
}

struct 개발자 {
    func 앱만들기(플랫폼:iOS) -> 앱 {
        프로젝트만들기(이름: 플랫폼.프로젝트이름)
        return 앱()
    }
}

func 프로젝트만들기(이름:String){
    
}

struct 앱 {

}

 

여기서 이 개발자가 안드로이드를 공부해서 앱을 만드려고 하면 어떻게 될까요?

 

아래와 같이 개발자 구조체 안에 앱만들기 메소드는 파라미터가 iOS 타입만 허용되어서 안드로이드를 넣을 수가 없게 되죠...

 

이렇게 되면 각 플랫폼마다 함수가 추가 되어야할 것이고 이것은 곧 수정이 많이 된다는 걸 뜻하게 됩니다.

 

struct iOS {
    var 프로젝트이름:String
}

struct 안드로이드 {
    var 프로젝트이름:String
}

struct 개발자 {
    func 앱만들기(플랫폼:iOS) -> 앱 {
        프로젝트만들기(이름: 플랫폼.프로젝트이름)
        return 앱()
    }
}

func 프로젝트만들기(이름:String){
    
}

struct 앱 {

}

 

그렇다면 이것을 해결하기 위해서 어떻게 해야할까요?

 

플랫폼이라는 타입을 만들어버려서 개발자는 플랫폼에 따른 앱을 만들게끔 하자

 

이렇게 되면 어떤 플랫폼이 생기든 해당 플랫폼만 확장이 되고 개발자는 수정해야할 부분이 없어질 것입니다.

 

확장은 언제든지 가능하지만 수정은 할 필요가 없는 구조가 되고 이것이 바로 개방 폐쇄 원칙이 되는 것이죠.

 

protocol 플랫폼 {
    func 앱만들기() -> 앱
    var 프로젝트이름:String { get }
}

struct iOS:플랫폼 {
    func 앱만들기() -> 앱 {
        return 앱()
    }
    
    var 프로젝트이름:String

}

struct 안드로이드:플랫폼 {
    func 앱만들기() -> 앱 {
        return 앱()
    }
    
    var 프로젝트이름:String
}

struct 개발자 {
    func 앱만들기(플랫폼:플랫폼) -> 앱 {
        프로젝트만들기(이름: 플랫폼.프로젝트이름)
        return 플랫폼.앱만들기()
    }
}

func 프로젝트만들기(이름:String){
    
}

struct 앱 {

}

---

728x90

3. 부모가 가진건 모든 자식에게 문제 없어야 해!(LSP) 👌🏻

아래처럼 빼야될 물이 이미 정해져 있고 부모가 짜장라면이고 자식이 라면인 경우입니다.

 

이렇게 된다면 라면은 물을 뺄 필요가 없는데 부모가 자동으로 남은 물을 물에서 빼야될 물을 빼버려서

 

라면도 남은 물이 50이 되어버렸습니다.... 이렇게 되면 라면이 엄청 짜게 만들어질텐데요.. 이것은 잘못된 부모의 경우입니다.

 

var 빼야될물 = 450

class 짜장라면 {
    var 물:Int = 500
    var 남은물:Int {
        return 물 - 빼야될물
    }

}

class 라면:짜장라면{
    override var 물:Int {
        didSet {
            물 = 500
        }
    }
}

func 요리완성(짜장라면:짜장라면) {
    print("남은물:\(짜장라면.남은물)")
}

let 짜파게티 = 짜장라면()
요리완성(짜장라면: 짜파게티)

let 진라면 = 라면()
요리완성(짜장라면: 진라면)

 

아래처럼 면요리라는 타입을 만들어서 물을 빼야하는 여부와 남은 물을 가지고 있으면

 

어떤 면요리든지 문제없이 요리가 완성될 수 있겠죠?

 

부모가 가진 것이 어떤 자식이라도 가졌을 때 아무런 문제가 없어야 한다는 것이 바로 즉 ,리스코프 치환 원칙이 되는것입니다.

 

var 빼야될물 = 450

protocol 면요리 {
    var 물빼야해:Bool{get}
    var 남은물:Int{get}
}

class 짜장라면:면요리 {
    var 물빼야해: Bool
    
    var 물:Int
    
    init(물:Int,물빼:Bool) {
        self.물 = 물
        self.물빼야해 = 물빼
    }
    
    var 남은물:Int {
        if 물빼야해 {
            return 물 - 빼야될물
        }
    }
}

class 라면:면요리{
    var 물빼야해: Bool
    
    var 물:Int
    
    init(물:Int,물빼:Bool) {
        self.물 = 물
        self.물빼야해 = 물빼
    }
    
    var 남은물:Int {
        if 물빼야해 {
            return 물 - 빼야될물
        }
    }
}

func 요리완성(면요리:면요리) {
    print("남은물:\(면요리.남은물)")
}

let 짜파게티 = 짜장라면(물: 500, 물빼: true)
요리완성(면요리: 짜파게티)

let 진라면 = 라면(물: 500, 물빼: false)
요리완성(면요리: 진라면)

---

4. 진짜 필요한 것들로 분리하자!(ISP)👬

 

여기 요리라는 프로토콜이 있고 기능은 면만들기,밥짓기,스시만들기가 있습니다.

 

그리고 짜장면,비빔밥,바게트 음식이 있는데 여기서 문제가 생깁니다...

 

짜장면은 면삶기만, 비빔밥은 밥짓기만 , 바게트는 빵굽기만 있으면 되는데

 

요리 프로토콜을 채택해 모든 요리기능을 각 요리가 가지고 있는 것이죠.

protocol 요리 {
  func 면삶기()
  func 밥짓기()
  func 빵굽기()
}

struct 짜장면:요리 {
    
    func 면삶기(){}
    func 밥짓기(){}
    func 빵굽기(){}
    
}

struct 비빔밥:요리 {
    
    func 면삶기(){}
    func 밥짓기(){}
    func 빵굽기(){}
    
    
}

struct 바게트:요리{
    
    func 면삶기(){}
    func 밥짓기(){}
    func 빵굽기(){}
    
}

 

아래와 같이 각 면,밥,빵에 맞게 요리 프로토콜을 만들어버려서 각 요리에 맞게 프로토콜을 채택해서 

 

진짜 필요한 기능들만 분리해서 사용하는 것이 바로 인터페이스 분리 원칙이 되는 것이죠!

protocol 면요리 {
    
  func 면삶기()
    
}

protocol 밥요리 {
    
  func 밥짓기()
    
}

protocol 빵요리 {
    
  func 빵굽기()
    
}

struct 짜장면:면요리 {
    
    func 면삶기(){}
    
}

struct 비빔밥:밥요리{
    
    func 밥짓기(){}
    
}

struct 바게트:빵요리{
    
    func 빵굽기(){}
    
}

---

5. 구체적인 것에 의존하지 말자!(DIP) 🙅🏼

아래처럼 목마른 사람이 있고 목 마른 사람은 음료를 마셔야 하는데 음료는 구체적인 콜라로 되어있습니다.

 

이 때 목마른 사람이 탄산은 너무 목이 따가워서 쥬스로 바꾸고 싶다면 어떻게 해야할까요?

 

목마른 사람에게 있는 음료의 종류를 바꿔줘야 할 것입니다.

 

이것은 구체적인 것에 의존해서 생기는 문제점인데요.

struct 콜라 {
    
    func 마시기() {}
}

struct 목마른사람 {
    
    let 음료:콜라
    
    init(음료:콜라) {
        self.음료 = 음료
    }
    
    func 갈증해소하기() {
        음료.마시기()
    }
    
}

문제점을 해소하기 위해서 음료라는 추상적인 것이 있고

 

목마른 사람은 이 추상적인 것에 의존하게 만들면 

 

음료가 어떤 것이 됐건 목마른 사람을 수정할 일은 없어질 것입니다.

 

구체적인 것에 의존하지 말자 즉, 이것이 의존 관계 역전 원칙이 되는 것이죠!

protocol 음료 {
    func 마시기()
}

struct 콜라:음료 {
    
    func 마시기() {}
}

struct 쥬스:음료 {
    func 마시기() {}
}

struct 목마른사람 {
    
    let 음료:음료
    
    init(음료:음료) {
        self.음료 = 음료
    }
    
    func 갈증해소하기() {
        음료.마시기()
    }
    
}

let 코카콜라 = 콜라()
let 오렌지쥬스 = 쥬스()

let foma = 목마른사람(음료: 코카콜라)
let gran = 목마른사람(음료: 오렌지쥬스)

---

Reference 😍

• 오늘의 Swift 상식(객체와 SOLID 원칙)
• SOLID 원칙에 따라 객체 설계하기
• Swift OOP) SOLID원칙 소개

---

 

이렇게 오늘은 객체 지향 설계에 꼭 필요한 5가지 원칙인 SOLID 원칙에 대해서 알아보았는데요.

 

5가지 원칙으로 나눠서 글을 쓰다보니 너무 길어졌네요....

 

정리하면서 원칙에 대해서 다시 한번 보니 정말 꼭 필요한 원칙들인거 같아요!

 

혹시라도 틀린 부분이 있거나 지적하실 부분이 있으면 언제든 댓글 달아주세요 ㅎㅎ