싱글톤 패턴, delegate패턴, 옵저버 패턴

임혜정·2024년 7월 31일
0
post-custom-banner

싱글톤

특정 클래스의 인스턴스가 앱 전체에서 단하나만 존재, 앱 전역에서 모두 접근할 할 수있음.
1. 개별적인 인스턴스를 생성할 필요가 없고
2. 단 하나의 인스턴스를 재활용하여 전역에서 활용

⭐️위치 서비스, 로깅 서비스, UserDefaults 전체 관리 클래스, 네트워크 중복 로직 관리 클래스 등을 생각하면 좋다.


import Foundation

//싱글톤으로 만든 클래스
class Adam {
    static let shared = Adam()
    //static키워드를 붙이면 최초 호출될 때에 메모리에 올라감
    // 불리고 나면 종료될때까지 메모리에 올라가있음
    // 싱글톤패턴을 사용할거면 메모리적으로 손해를 보지 않는지 점검해봐야함
    
    var mbti = "infp"
    var age = 20
    
    private init() {} // ❗️Adam에 대해서 인스턴스 생성을 할 수 없게 막아버리기
    
    func printInfo() {
        print("[Adam Info]")
        print("mbti =  \(mbti)")
        print("age = \(age)")
    }
}

Adam.shared.printInfo()// ❗️shared라는 공유 인스턴스를 통해서 접근할 수 있다


// shared라는 창구를 통해서만 접근하여 사용할 수 있음. 유일한 접근점 = shared
Adam.shared.mbti = "infj"
Adam.shared.age = 24

Adam.shared.printInfo()

그렇다면 구조체로 정의된 객체에 대해 싱글톤 패턴을 적용하는 것은 적절한가?

적절하지 않다. 구조체는 상속이 불가하고 불변성을 가지며 값 타입의 특성을 가지고 있다. 그래서 인스턴스 생성시 값이 '복사'되어 전달되는데 , 상태를 가지고 있고 이를 수정할 수 있어야하는 싱글톤 패턴 특성과 충돌하게 된다.
싱글톤 패턴은 private 이니셜라이저를 사용하여 외부 인스턴스 생성을 막아버리는데 구조체의 이 또한 구조체의 특성과 맞지 않고 , 상속이 불가한 점 때문에 확장이나 변형이 필요할 때 제약되므로 어울리지 않는다. + 메모리관리측면: 참조 카운팅이 되지 않아 싱글톤 생명주기관리도 복잡해짐



Delegate

대리자, 위임자, 대신 수행해줄 사람
어떤 객체 A에서 하고 싶은 일을 객체 B에게 대신 처리하게 하는 패턴
protocol로 대신 처리해줄 내용을 작성하여 넘기고, protocol로 위임받은 객체b는 대신 처리함.




빌더패턴, 팩토리 패턴

옵저버->
mvvm을 적용할때 필요

~~mvc적용에 있어서 뷰와 컨트롤러의 결합이 강하다는 것. 즉 분리가 어렵다는 것이
어떤 조건에 의해서 뷰의 상태가 바뀌어야할때에 조건문으로 들어가는 그런 점도 해당이 되는 것인지?
~~

패턴들을 잘 이해하고 있으면 그냥 텍스트로 주어지는 구현사항만 읽어도 어떤 구조로 데이터 모델링을 해야하는지 머리속으로 그리는 것이 가능하겠군.

profile
오늘 배운걸 까먹었을 미래의 나에게..⭐️
post-custom-banner

0개의 댓글