🍀 소개
👨‍💻 팀원
⏱️ 타임라인
👀 시각화된 프로젝트 구조
💻 실행 화면
🧨 트러블 슈팅
📚 참고 링크
👥 팀 회고

한 명의 직원을 가진 은행이 10 ~ 30명의 고객을 받아 응대하는 프로그램입니다.

🐬Whales🐬	🍎Zion🍎
Github Profile	Github Profile

┌── ios-bank-manager
│   ├── BankManagerConsoleApp
│   │   ├── Model
│   │   │   ├── Client
│   │   │   ├── BankManger
│   │   │   ├── Bank
│   │   │   ├── Node
│   │   │   ├── LinkedList
│   │   │   └── Queue
│   └── Tests
└── README.md

다음 Step 진행 후 작성 예정

🚨 문제점
Bank Type을 struct로 설정하여 Closure 내부에서 Capture시 Closure내부의 Bank와 클로저 외부의 Bank가 동일하지 않아 경고 문구가 노출 되었습니다.

💡 해결방법

DispatchQueue.global().async(group: group) {
                self.bankManger.work(client: client)
                semaphore.signal()
            }

현재 Bank Type의 startTask 로직 내부에서는 Bank Type의 내부 변수에 접근하는 async로직이 존재합니다. 따라서 Bank Type을 struct로 설정하게 된다면 async가 등록될 때의 Bank와 async block 내에서 capture 될 때에의 Bank가 서로 다른 Bank 일 수 있습니다.

그 이유는 일반적으로 클로저 내에서 값을 캡쳐했을 때에는 값 타입이든 참조 타입이든 Strong Reference 형태로 값을 참조하지만 값 타입의 경우에는 복사된 값에 대한 주소 값을 참조하기 때문에 async로 등록할 때의 Bank와 실질적으로 async block이 실행될 때의 Bank가 같은 Bank임을 보장할 수 없기 때문입니다.

따라서 Bank를 Class 참조 타입으로 설정하여 참조할 수 있도록 변경했습니다. 또한 Strong Reference 참조를 하게된다면 순환참조의 가능성에대해 고민해봤지만 위와 같은 경우에서는 async block에서는 Bank를 참조하고 있지만 Bank에서는 해당 async block을 직접적으로 참조하고 있지않으므로 순환참조가 발생하지않기 때문에 [weak self]의 캡쳐키워드는 생략했습니다.

🚨 문제점
DispatchQueue와 OpeartionQueue 중 어떤 방식으로 문제를 해결할지 고민했습니다.

💡 해결방법
조금 더 객체지향적인 프로그램의 동작을 위해 DispatchQueue를 사용하여 구현했습니다.

DispatchQueue을 활용해 해당 요구사항을 구현하는 방법으로는 DispatchGroup 및 DispatchSemaphore를 활용하는 방법이 있었고 OperationQueue를 활용한다면 maxConcurrentOperationCount property 및 waitUntilAllOperationsAreFinished 메서드의 활용으로 과제를 해결할 수 있었습니다.

하지만 Bank, BankManager, Client가 코드를 읽는 입장에서 조금 더 자연스럽게 객체지향적으로 의사소통할 수 있는 설계에 대해 고민했고 Operation을 상속받는 Type을 만들어서 OperationQueue에 넣어주는 방법보다는 DispatchQueue async 로직 내부에서 BankManager가 직접적으로 업무를 실행하고 그 업무를 실행하는 데 있어서 customer를 주입 받는 방식을 사용했습니다.

물론 같은 결과물을 나타냈겠지만 조금 더 객체지향에 대해서 고민해볼 수 있어서 좋았습니다.

• 야곰닷넷: 동시성프로그래밍
• blog: Strong Reference Cycle