[기록] Repository Pattern을 사용한 것에 대하여

[SH0123]

배경

• 팀 프로젝트를 진행하면서 CoreData를 이용하여 데이터를 가져왔음.
• 팀원들이 각자 역할을 맡은 화면의 파일에서 Data CRUD 코드를 제각기 구현하여 사용하였고, 이로인하여 코드의 중복성과 복잡성이 증가함
• 추후 CoreData를 Realm으로 변경하거나, 서버를 이용하여 DB를 바꿔야하는 경우 변경해야하는 코드가 많을 것으로 예상됨. (변경에 취약)

과정

• 변경에 용이한 코드 작성에 관심을 갖게되어, Repository Pattern이라는 디자인 패턴에 대해 알게됨
• 오브젝트 책을 공부하며 기록해놓은 내용을 읽어보며 객체가 본인만의 역할을 수행하고, 확장에 용이한 유지보수에 좋은 코드를 작성해보기로 결정

고민사항

• Usecase와 DataSource에 대해서 class와 struct중 어느것을 사용할 것인지
• CoreData의 객체와 domain에서 사용하는 객체의 구분 필요성. 이에 대해 어떻게 구현할 것인지
• DB 접근 객체를 사용할 때 Singleton에 대한 사용

내 생각 및 여전한 고민 사항들

DataSource

• DB에 접근하는 객체이기 때문에 여러개의 객체를 개별로 생성하고 여러 장소에서 접근한다면 concurrency 문제가 발생할 수 있을 것 같다는 생각이 들었다
• 그렇기에 Class로 객체를 만들고 static으로 만들어 프로그램 시작되고 끝날 때 까지 heap 영역에 존재하도록 하고 singleton으로 만들어야겠다는 판단을 했다.

Singleton vs 공유 인스턴스

• Singleton Pattern을 사용하는 것에 대하여 ... 기록

Usecase

• Struct 객체로 만들기로 결정했다.

• [WWDC 2016 Swift Performance(https://developer.apple.com/wwdc16/416) 영상을 보면 Struct가 메모리 생성 및 할당 측면에서 Class보다 오버헤드가 덜 발생한다고 한다.

• 하지만 Struct가 갖고 있는 property에 heap 영역에 할당되어 참조해야하는 레퍼런스가 2개 이상이면 Class보다 성능이 좋지 않을 수 있다고 한다. reference count 연산에 있어서 오버헤드가 있기 때문에!! 이에 대한 실험

• 나의 경우 Usecase에서는 DB를 연결할 Repository(Datasource) 객체가 heap 영역에 할당되지만, static으로 프로그램 생성과 동시에 할당되어 종료될 때 까지 존재하며 단 하나의 레퍼런스만 property로 갖고있기 때문에 아직까지는 큰 문제가 되지 않는다는 판단하에 속도가 조금 더 빠를 수 있는 Struct를 사용하기로 판단했다

• 이와 같은 고민의 경우 현직자분과 이야기할 기회가 있다면 이야기를 나눠보고싶다

[SH0123]

Reference

오브젝트

• 객체, 설계
• 상속과 다형성, 추상화와 유연성
• 역할, 책임, 협력

Repository Pattern

• Repository Pattern에 대한 고찰
• Usecase 활용기

Struct vs Class

• WWDC 2016 Swift Performance
• class와 struct의 사용

[SH0123]

Reference Counting으로 인한 오버헤드 간단 테스트

WWDC 영상에서 Struct와 Class를 사용하는데 있어서 Reference Count로 인해 오버헤드가 발생하고 성능에서 차이가 발생함을 알 수 있었다.
그 중에서도 heap 영역에 할당되는 property를 가지고 있는 객체의 경우 Struct와 Class중 어떤 것으로 객체를 생성하면 좋을지에 대한 내용이 있었고 이에 대해 직접 확인하고 싶었다.

아래가 WWDC 영상 내용이다.

Struct로 구현할 경우 Label 객체가 복사되기 때문에 heap 영역에 할당되는 Property인 font에 대해서 reference counting 연산을 Class로 구현하는 경우보다 두배는 더 해줘야해서 오버헤드가 발생한다는 것이다.

class InnerClass {
    var id: Int
    var name: String
}

class OuterClassPropertyOne {
    let classInsatnce: InnerClass

    deinit {
        print("deinit outer class")
}

struct OuterStructPropertyOne {
    let classInstacne: InnerClass
}

레퍼런스 카운트가 실제로 어떻게 변하는지 아래의 코드를 통해 살펴보자

Struct 객체

var innerClass = InnerClass(id: 1, name: "class")
print(CFGetRetainCount(innerClass))
var instance1: OuterStructPropertyOne? = OuterStructPropertyOne(classInstacne: innerClass) // struct 객체 생성
print(CFGetRetainCount(innerClass))
var instance2: OuterStructPropertyOne? = instance1 // struct copy
print(CFGetRetainCount(innerClass))
instance1 = nil // deinit
print(CFGetRetainCount(innerClass))
instance2 = nil // deinit
print(CFGetRetainCount(innerClass))

2
3 // instance1
4 // instance2
3 // instance1 deinit
2 // instance2 deinit

Class 객체

var innerClass = InnerClass(id: 1, name: "class")
print(CFGetRetainCount(innerClass))
var instance3: OuterClassPropertyOne? = OuterClassPropertyOne(classInsatnce: innerClass) // class 객체 생성
print(CFGetRetainCount(innerClass))
var instance4: OuterClassPropertyOne? = instance3 // class reference copy
print(CFGetRetainCount(innerClass))
instance3 = nil // deinit
print(CFGetRetainCount(innerClass))
instance4 = nil // deinit
print(CFGetRetainCount(innerClass))

2
3 // instance3
3 // instance4 copy reference : retain count overhead 없음
3 // instance 3 deinit
deinit outer class 
2 // instance 4 deinit

위의 코드와 실행결과를 reference count 중심으로 비교해보자.

struct : 2->3->4->3->2
class : 2->3->3->3->2

struct에서 reference count가 1만큼씩 더 증가했다가 감소한다.
이 만큼 retain, release 작업이 일어났을 것이고 이 작업의 동기화를 위해서 lock과 같은 작업들이 발생했을 것이다.
즉 이로인한 overhead가 발생했을것으로 보인다.

property가 static let으로 선언된 경우, Struct 객체

struct OuterStructPropertyOne {
    static let classInstacne: InnerClass = .init(id: 3, name: "three")
}

var instance1: OuterStructPropertyOne? = OuterStructPropertyOne()
print(CFGetRetainCount(OuterStructPropertyOne.classInstacne))
var instance2: OuterStructPropertyOne? = instance1
print(CFGetRetainCount(OuterStructPropertyOne.classInstacne))
instance1 = nil
print(CFGetRetainCount(OuterStructPropertyOne.classInstacne))
instance2 = nil
print(CFGetRetainCount(OuterStructPropertyOne.classInstacne))

2
2
2
2

property가 static let으로 선언된 경우, Class 객체

class OuterClassPropertyOne {
    static let classInstacne: InnerClass = .init(id: 3, name: "three")
    
    deinit {
        print("deinit outer class")
    }
}

var instance3: OuterClassPropertyOne? = OuterClassPropertyOne()
print(CFGetRetainCount(OuterStructPropertyOne.classInstacne))
var instance4: OuterClassPropertyOne? = instance3
print(CFGetRetainCount(OuterStructPropertyOne.classInstacne))
instance3 = nil
print(CFGetRetainCount(OuterStructPropertyOne.classInstacne))
instance4 = nil
print(CFGetRetainCount(OuterStructPropertyOne.classInstacne))

2
2
2
deinit outer class
2

이번에는 이전에 했던 실험과 다른 결과를 보인다.
static으로 선언한 레퍼런스 변수가 프로그램이 종료될 때 까지 할당 해제되지 않고 heap 영역에 존재하기 때문에 위와같이 struct나 class나 같은 결과를 보인다
근데 static으로 선언한 레퍼런스 변수는 reference counting을 하지 않는것인가? 라는 궁금증이 생기는 결과였다.

결론

instance의 property로 heap 영역에 할당하는 인자가 많아질수록
struct로 구현한 instance에는 class로 구현한 instance보다 reference count retain, release 작업으로 인한 overhead가 훨씬 많이 발생한다.
하지만 property가 static let으로 선언되어 프로그램의 생명 주기와 함께 생성과 소멸을 함께하는 객체라면 struct나 class나 동일하다.

즉, 무작정 struct가 class보다 낫다는 판단 보다는 상황에 따라 비교해보며 성능을 향상시킬 수 있는 코드를 작성하면 좋다