🌟 SOLID 원칙이란?

SOLID라는 용어는 객체 설계에 필요한 5가지 원칙의 약자로, 유지보수가 쉽고, 유연하고, 확장이 쉬운 소프트웨어를 만드는것을 목적으로 한다.
Clean Agile, Clean Achitecture, Clean Code, Clean Software등의 클린코드에 대한 책을 많이 쓰신 로버트 C.마틴(aka. Uncle Bob)이 2000년에 논문 "Design Principles and Design Patterns"에서 발표한 내용이다.

앞서 설명한대로 SOLID는 약어인데, 각 S는 단일 책임 원칙(Single Responsibility Principle), O는 개방-폐쇄 원칙(Open-Closed Principle), L은 리스코프 치환 원칙(Liscov Substitution Principle), I는 인터페이스 분리 원칙(Interface Segregation Principle), D는 의존성 역전 원칙(Dependency Inversion Principle)을 의미한다.

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

단일 책임 원칙이란?

단일 책임 원칙은 "클래스를 변경해야 할 이유는 고유해야 한다. 즉, 클래스는 하나의 책임을 가져야 한다는 뜻이다." 라고 말한다. 여기서 말하는 책임이란 변경의 이유를 뜻한다. 하나의 클래스를 변경해야 하는 이유가 여러개 떠오른다면 이 클래스는 여러 책임을 가지고 있다는것과 같은 뜻이다. 또, 하나의 책임을 여러 클래스에 나눠 두는것도 안되며 이것들을 지키지 않으면 코드에 변화를 줘야 할 때 여러곳을 수정해야하는 상황이 발생하기 때문에 유지보수가 매우 비효율적이게 된다.

Example

/// Before
class Factory {
	public func excute() {
    	let responseData = self.requestData()
        let parsingData = self.parse(data: responseData)
        self.save(item: parsingData)
    }
    
    private func requestData() -> Data {
    	/// Request Data And Wait Response 
    }
    
    private func parse(data: Data) -> [String] {
    	/// Parsing Responsed Data
    }
    
   	private func save(item: [String]) {
    	/// Save Item at Local DataBase
    }
}
/**
	하나의 클래스가 여러개의 책임(private으로 접근제한 된 다양한 메소드들)을 가지고 있다.
*/



/// After
class Factory {
	let requester = Requester()
    let converter = Converter()
    let database = Database()
    
    public func excute() {
    	let responseData = self.requester.getData()
        let parsingData = self.converter.convert(to: responseData)
        self.database.save(item: parsingData)
    }
}

class Requester {
	internal func getData() -> Data {
    	/// Request Data And Wait Response 
    }
}
class Converter {
	private func convert(to data: Data) -> [String] {
    	/// Parsing Responsed Data
    }
}
class Database {
	private func save(item: [String]) {
    	/// Save Item at Local DataBase
    }
}
/**
	하나의 클래스가 책임을 하나씩만 가지고 있다.
*/

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

개방-폐쇄 원칙이란?

개방-폐쇄 원칙은 "소프트웨어 엔티티(클래스, 모듈, 기능 등)는 확장에는 열려 있어야 하지만 변경에는 닫혀있어야 한다" 고 말한다.

확장에 열려있다는 것은 엔티티를 확장할 때 쉽게 해야 한다는 것이며, 변경에 닫혀있다는 것은 엔티티를 확장할때 코드를 변경 하지 않고도 가능해야 한다는것을 의미한다. 즉, 기존의 코드를 변경하지 않고 기능을 수정하거나 추가할 수 있도록 설계해야 하는 원칙이다.

어떤 모듈이나 기능을 하나 수정 할 때, 그 엔티티를 이용하는 다른 엔티티 역시 줄줄이 고쳐야 한다면 유지보수가 복잡할 것이다. 따라서 개방-폐쇄 원칙을 잘 적용하여 기존 코드를 변경하지 않아도 기능을 새롭게 만들거나 변경할 수 있도록 해야 한다. 그렇지 않으면 객체지향 프로그래밍의 가장 큰 장점인 유연성, 재사용성, 유지보수성 등을 모두 잃어버리는 셈이고, OOP를 사용하는 의미가 사라지게 된다.

OCP 는 추상화 (인터페이스) 와 상속 (다형성) 등을 통해 구현해낼 수 있다. 자주 변화하는 부분을 추상화함으로써 기존 코드를 수정하지 않고도 기능을 확장할 수 있도록 함으로써 유연함을 높이는 것이 핵심이다.

Example

/**
캐릭터를 하나 추가한다고 할때, 각각의 캐릭터가 움직임이 다를 경우 움직임의 패턴 구현을 하위 클래스에 맡긴다면 
캐릭터 클래스의 수정은 필요가없고(Closed) 움직임의 패턴만 재정의 하면(Open) 된다.
*/

/// Before
enum Country {
	case korea
    case japan
    case usa
}

class Flag {
	let country: [Country]
    
    func name(_ country: Country) {
    	switch country {
        	case korea:
            	print("한국")
            case japan:
            	print("일본")
            case usa:
            	print("미국")
        }
    }
}

/**
Country 열거형에 case를 추가하면 name(_:) 함수도 수정해야 한다. 
결합도와 의존성이 높고, 유지보수가 힘들다.
*/


/// After
protocol Country {
	var name: String
}

struct Korea: Country {
	var name = "한국"
}
struct Japan: Country {
	var name = "일본"
}
struct USA: Country {
	var name = "미국"
}

class Flag {
	var country: [Country]
    
    func name(_ country: Country) {
    	print(country.name)
    }
}

/**
나라를 추가하고 싶다면 Country를 채택하는 구조체를 만들기만 하면 된다. 
결합도가 낮고, 응집도가 높아 유지보수에 용이하다
*/

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

리스코프 치환 원칙이란?

리스코프 치환 원칙은 "자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있어야 한다." 고 말한다. 예를 들어 C라는 클래스에서 A라는 부모 클래스를 사용하는데 B라는 A를 상속받은 자식 클래스로 대체해도 C라는 클래스에서는 아무런 영향없이 정상적으로 같은 동작을해야 한다는 것이다.

Example

/// Before
class Rectangle {
    var width: Int
    var height: Int
    
    var area: Int {
    	return width * height
    }

    init(width: Int, height: Int) {
        self.width = width
        self.height = height
    }
}

class Square: Rectangle {
    override var width: Int {
        didSet {
            super.height = width
        }
    }

    override var height: Int {
        didSet {
            super.width = height
        }
    }
}


let sqaure = Sqaure(width: 10, height: 10)
self.checkArea(of: sqaure)

func checkArea(of item: Rectangle) {
	item.width = 9
    item.height = 3
    
    print(item.area)
}

/**
	함수 내에서 직사각형의 면적이 9*3을 예상하겠지만, 실제로 3*3이 출력된다.
    이는 잘못된 동작을 실행한 것이고, 서브클래스가 슈퍼클래스 대신 사용되도 같은 동작을 한다고 보기 어렵다.
*/



/// After
protocol Geometrics {
    var area: Int
}

class Rectangle: Geometrics {
	var width: Int
    var height: Int
    var area: Int {
    	return width * height
    }
    
    init(width: Int, height: Int) {
    	self.width = width
        self.height = height
    }
}
class Square: Geometrics {
	var edge: Int
    var area: Int {
    	return edge * edge
    }
    
    init(edge: Int) {
    	self.edge = edge
    }
}


// print -> 50
let geometric1: Geometrics = Rectangle(width: 10, height: 5)
print(geometric1.area)

// print -> 25
let geometric2: Geometrics = Sqaure(edge: 5)
print(geometric2.area)

/**
	자식 클래스가 바뀌어도 같은 동작을 해낸다.
	두 클래스가 가져야 할 동일한 값을 프로토콜을 상속받는 것으로 보장했다.
    이렇게 하면 필요한 값이나 동작만 사용할 수 있도록 보장할 수 있기 때문에
    예상 가능한 시나리오를 만들 수 있다.
*/

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

인터페이스 분리 원칙이란?

인터페이스 분리 원칙은 "클라이언트는 불필요한 인터페이스에 의존하면 안된다. 즉, 사용하지 않는 인터페이스는 구현하지 말아야 한다." 고 말한다. Uncle Bob이 논문에서 자주 사용하는 용어로 Fat Interface가 있다. 이러한 인터페이스(Swift - Protocol)는 응집력이 없다고 간주된다. 쉽게 말해 클라이언트가 필요로 하는 것보다 더 많은 메서드/기능을 가질 수 있고 기본적으로 뚱뚱한 인터페이스는 ISP 원칙을 따르지 않는 인터페이스이다.

뚱뚱한 인터페이스를 변경해야 하는 경우가 생긴다면 해당 인터페이스를 상속하는 모든 클래스를 모두 변경하고 다시 테스트해야하는 일이 생겨 테스트가 더 어려워지고 불필요한 리펙터링이 생기는 문제들이 발생하게 된다.

Example

/// Before
protocol Animal {
	func run()
    func swim()
    func fly()
}

class Dolphin: Animal {
	func swim()
    
    /// NOT USED
    func run() { }
    func fly() { }
}
class Dog: Animal {
	func run() { }
    func swim() { }
    
    /// NOT USED
    func fly() { }
}
class Duck: Animal {
	func fly() { }
    func run() { }
    func swim() { }
}

/**
	Duck은 모두 사용하지만 Dog, Dolphin은 사용하지 않는 함수들이 존재한다.
*/


/// After
protocol Runable {
	func run()
}
protocol Swimable {
	func swim()
}
protocol Flyable {
	func fly()
}

class Dolphin: Swimable {
	func swim() { }
}
class Dog: Runable, Swimable {
	func run() { }
    func swim() { }
}
class Duck: Runable, Swimable, Flyable {
	func fly() { }
    func run() { }
    func swim() { } 
}
/**
	프로토콜을 분리함으로써 필요한 프로토콜만 상속받아 사용하지 않는 함수는 제거하도록 했다.
*/

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

의존 역전 원칙이란?

의존 역전 원칙은 "상위 레벨 모듈은 하위 레벨 모듈에 의존하면 안된다. 둘 다 추상화에 의존해야 한다." 라고 말한다. 즉, 구체화된 클래스에 의존하기 보단 추상적인 인터페이스나 추상클래스에 의존해야 한다는 말이다. 저수준의 모듈이 변경되어도 고수준의 모듈은 변경이 필요없는 형태가 가장 이상적이다.

불량 설계

DIP에 대해 조금 더 자세히 살펴보기 전에 개발자 세계에서 흔히 들을 수 있는 Bad Design에 대해 간단히 알아보도록 하자.
* Design Smells라고 불리기도 한다.

불량 설계란 소프트웨어나 프로젝트 전체가 올바르게 설계되지 않은 경우에 발생하는 상태를 뜻한다. 때로는 좋은 방식으로 설계가 되었지만 시간이 지나고 여러 사람을 거치면서 잘못 설계된 소프트웨어가 되는 일도 있다. 그렇다면 올바르게 설계된 소프트웨어인지 아닌지 구분은 어떻게 할까? 소프트웨어가 정상적으로 작동하더라도 다음 특성 중 일부를 포함하고 있다면 잘못 설계된 것으로 분류 될 수 있다.

1. 경직성: 시스템 변경이 어렵다. 하나를 바꾸려고 할 때마다, 다른 것들도 끝없이 바꾸어야 한다.
2. 취약성: 한 부분의 수정이 다른 많은 부분들, 연관이 없는 부분에 까지 영향을 준다.
3. 높은 결합도: 모듈간의 의존하는 정도가 크기 때문에 코드를 수정할 때 우리도 모르게 다른 모듈에 영향(Side Effect)을 끼칠 수 있다.
   또한, 오류가 발생 했을 때도 다른 모듈에도 영향을 끼칠 수 있고 다른 모듈의 영향을 받아 오류가 발생했을 수도 있게 된다.

그런데 읽다보니 왜 이것에 대해 이야기 하고 있는지 DIP와 무슨 관련이 있는지 의문이 들것이고 그게 당연하다. 답은 간단하다 DIP는 좋은 디자인에 정비례하기 때문이다. 즉, 이 원칙을 준수할 때 개발된 소프트웨어는 취약하지 않고, 경직되지 않았으며 결합도가 낮은 경향이 있다. DIP를 준수하면 불량설계를 하게될 확률이 줄어든다는 뜻이다.

불량 설계의 이유

우리는 방금 불량 설계의 특징들에 대해서 얘기했다. 이제는 각 원인들이 무엇인지 알아보자.

경직성이 올라가는 이유

• OCP 원칙을 무시하는 경우, 소프트웨어에서 확장이 필요할 때마다 수정을 요구하기 때문에 경직도가 올라가게 된다.
• 추상화에 의존하지 않고 다른 구조에 의존하게 되는 경우, 구조를 변경할 때마다 해당 구조에 의존하는 다른 모듈에 영향이 가기 때문에 경직도가 올라가게 된다.

취약성이 올라가는 이유

• 또, OCP 원칙을 무시하는 경우 소프트웨어에서 확장이 필요할 때 수정이 요구되는데 가끔 빌드 타이밍에는 이것을 알아채지 못하고 오류가 나는 경우가 있다. 즉, 필요한 수정이 이뤄지지 않게되면 오류가 발생할 위험이 있기 때문에 취약성이 올라간다.
• 마찬가지로 추상화에 의존하지 않고 다른 구조에 의존하게 되는 경우다. 구조를 변경할때 다른곳에 영향을 줄 수 있고 이것이 현재 기능을 중단시킬 가능성이 있기 때문에 취약성이 올라가게 된다.

결합도가 높아지는 이유

• 역시나 추상화에 의존하지 않고 다른 구조에 의존하게 되는 경우다. 이는 구조가 다른 구조에 의존하게 되면서 재사용이 매우 어려워지면서 코드가 결합되어 결합도가 높아지게 된다.

WA! 다시 DIP 정의로 돌아가보자. 지금까지 불량 설계에서 반복적으로 나타나는 이 문구는 DIP를 역으로 설명할 수 있는 문구이다.

추상화에 의존하지 않고 다른 구조에 의존하는 경우.

그렇기 때문에 이 원칙이 좋은 설계와 정비례한다는 것이고, 이 원칙을 따르지 않으면 경직성, 취약성이 올라가고 결합도가 높은 소프트웨어를 설계하게 된다. 이것은 매우 잘못 설계된 소프트웨어라고 할 수 있다.

다른 원칙들과의 관계

먼저 짧게 설명하자면 DIP는 OCP와 LSP의 결과이다. OCP와 LSP를 무시하는 과정에서 발생하는 문제들은 모두 추상화로 해결하기 때문이다. 위에서 OCP와 LSP를 해결하는 예시를 보면 모두 추상화로 해결했다. 클래스는 다른 클래스가 아닌 추상화(프로토콜)에 의존하게 했고, 이를 위해 세부화(클래스) 또한 추상화에 의존하게 했다. 기본적으로 OCP와 LSP를 따르기 위해 DIP를 따라야 한다.

Example

class Order {
	let menu = Menu(price: 5000)
}
class Menu {
	var price: Int
    init(price: Int) {
    	self.price = price
    }
}

let order = Order()
print(order.menu.price) // 5000

/**
	이렇게 클래스 내부에서 인스턴스를 생성하면 해당 클래스에 의존하게 되는 결과가 생긴다.
*/


/// 의존성 주입, Dependency Injection
class Order {
	let menu: Menu
    init(menu: Menu) {
    	self.menu = menu
    }
}
class Menu {
	var price: Int
    init(price: Int) {
    	self.price = price
    }
}

let menu = Menu(price: 7000)
let order = Order(menu: menu)
print(order.menu.price) // 7000

/**
	이렇게 외부에서 인스턴스를 생성 후 넣어주는것을 의존성 주입이라고 한다.
    하지만, 아직 추상화에 의존하지 않았기 때문에 결합도가 높아 유지보수를 하는데 불리하다.
*/



/// 의존성 역전 원칙, Dependency Iversion Principle
protocol Menu {
	var price: Int
}
class Order {
	let menu: Menu
    init(menu: Menu) {
    	self.menu = menu
    }
}
class Toast: Menu {
	var price: Int
    init(price: Int) {
    	self.price = price
    }
}

let toast = Toast(price: 3000)
let order = Order(menu: toast)
print(order.menu.price) // 3000

/**
	두 클래스 모두 추상화된 프로토콜에 의존하게 되면서 서로간의 의존성은 독립적이게 됐다.
    이렇게 되면 결합도가 낮아져 Toast의 코드를 변경해도 Order에는 영향이 없어 유지보수에 유리하다.
*/

🌟 글을 마치며

오늘 배운 내용들을 정리해보자.

SRP와 ISP는 객체가 커지는것을 방지해준다. SRP는 단일 책임을 부여해 객체가 나뉘도록 했고 ISP는 클라이언트마다 특화된 인터페이스를 구현하게 함으로써 한 기능의 변경이 다른곳에 미치는 영향을 최소화 하고, 이는 기능 추가 및 변경에 용이하도록 한다.

LSP와 DIP는 OCP를 서포트한다. OCP 는 자주 변화되는 부분을 추상화하고 다형성을 이용함으로써 기능 확장에는 용이하되 기존 코드의 변화에는 보수적이도록 만들어 준다. 여기서 변화되는 부분을 추상화할 수 있도록 도와주는 원칙이 DIP 이고, 다형성 구현을 도와주는 원칙이 LSP 인 것이다.

Clean Architecture에 이어서 SOLID 5원칙에 대해서도 공부를 하게 되었는데, 처음에는 Clean Architecture만으로도 머릿속에 정리하려니 앞이 깜깜했었다. 하지만 Clean Architecture를 배우니 더 깊게 공부하고 싶어졌고 그래서 SOLID 5원칙 까지 공부하게 됐다.

이것들을 머릿속에 정리하고 내 프로젝트에 직접 적용하게 되면 자연스레 좋은 품질의 코드를 작성할 수 있을거라 생각이 든다. 또, 좋은 품질의 코드를 꾸준히 작성하는것은 좋은 개발자로 거듭나기 위한 과정이라고 생각하기 때문에 더 많은 학습을 통해 좋은 품질의 코드를 유지할 수 있도록 해야겠다.

Reference

• Rodrigo Maximo
  • Single Responsibility Principle in Swift
  • Open-Closed Principle in Swift
  • Liskov Substitution Principle in Swift
  • Interface Segregation Principle in Swift
  • Dependency Inversion Principle in Swift
• SOLID 원칙, 객체지향 설계원칙
• SOLID 원칙, 어렵지 않다!
• Swift로 보는 SOLID 법칙
• 오늘의 Swift 상식 (객체와 SOLID 원칙)
• 1. SOLID - 객체 지향의 다섯가지 원칙