개발자 소들이

iOS) 유닛테스트(Unit Test) 테스트 코드를 작성해보자 (2/2)

소들이 — Mon, 30 Jun 2025 19:14:17 +0900

안녕하세요! 소들입니다 :)

저 퇴사 했습니다 ~~~~~ (뜬금)

백수입니다만? 이제 월급이 안 들어옵니다만?

나스닥아,,!! 힘내,,!!

6월 1달 간은 저에게 휴식을 주는 시간을 가졌구요

7, 8월은 제 스스로 느꼈던 기술 부채와 한계를

조금 메우는 시간을 가져보려고 해요 :D

백수가 되었지만 .. 블로그 글은 잘 못쓸 것 같네요ㅠㅠ

글 쓰는 게 사실 너무 오래 걸려서,,

이 글을 마지막으로 언제 올진 모르겠습니다

3분기 이후에 재취업하면 아마?도?

쨌든 마무리는 짓자는 마인드로

사실 이미 오래 전에 끝냈어야 할,,

유닛 테스트와의 마지막 시간을 보내보려고 합니다

그 테스트,, 좋은 테스트였ㅇㅓ,,

1. Testing System이 뭔가요?

여러분 프로젝트를 만들 때 말이죠

이렇게 이렇게 Testing System 영역에 총 세가지가 있잖음?

말그대로 테스트 시스템을 고르는 건데,

None은 말 그대로 Test 파일 자체가 생성이 안 됨!

근데 나머지

XCTest for Unit and UI tests

Swift Testing with XCTest UI Tests

이 두개 같은 경우 암거나 체크하고 프로젝트를 만들면

이렇게 Tests 파일과 UITests란 파일이 생김

(저번 포스팅에서 테스트는 단순 유닛도 있지만 최종적으로 UI 테스트까지 간다 했져?)

그럼 두 개의 차이가 뭐냐하고 묻는다면,

Swift Testing이 좀 더 신생아임

XCTest for Unit and UI tests가 기존에 사용하던 방법으로

클래스와 메서드 기반으로 작성한다면,

Swift Testing with XCTest는 XCode 15부터 도입된

함수와 매크로 기반으로 작성을 함

(불현듯 떠오르는,,, 매크로 부수고 부서지기,,)

이번 포스팅에선 그럼 둘 중에 뭐를 공부하겠냐 한다면

좀 더 오래 전부터 사용해오던

XCTest for Unit and UI tests

에 대해서 공부 할 것임다

2. 테스트 코드 살펴보기

XCTest for Unit and UI tests를 체크하고

프로젝트를 만들면

네 대충 이런 코드가 나오는데요

먼저 첫 줄에 import 된 것들을 먼저 보겠음

import XCTest
@testable import SodeulTest

XCTest는 테스트에 필요한 메서드들을 사용하기 위해 import 해야함

근데 밑에 @testable이 붙고 내 프로젝트가 임포트 되어 있잖음?

사실

XCTest for Unit and UI tests

로 만들 경우, 테스트가 테스트 전용 모듈로 분리가 되어버림

따라서 내 프로젝트를 무조건 import를 해야만 접근이 가능함!

(테스트 자체가 내 프로젝트의 기능을 테스트 하는 것이기 때문)

근데 모듈 간에 접근이 가능하려면

Public 접근 제어자부터 가능하잖음??

근데 그렇다고 내가 테스트를 위해 모든 접근 제어자를 public으로 바꿀 수도 없는 노릇이거,,

때문에 이것 때문에 붙은 것이 @testable임!

@testable을 붙여줄 경우,

테스트를 할 때만 private이 아닌 접근 제어자는 모두 접근 할 수 있음

실제로 보면

이렇게 내 프로젝트에 SodeulViewController를 만들고

접근제어자를 public으로 해주지 않았지만

이렇게 별도의 모듈인 테스트에서 SodeulViewController에 접근할 수 있음!

이것이 가능한 게 바로 @testable이란 것 때문임

만약 프로젝트 import 시에 @testable이란 것을 삭제할 경우,

이렇게 SodeulViewController를 찾을 수 없다고 뜸!

이해 가셨져?(물론 SodeulViewController를 public으로 하면 접근 가넝)

근데 그렇게 테스트를 위해 은닉성 개나 주지 말구

얌전히 @testable을 사용합시당 ㅎㅁㅎ

3. XCTestCase는 뭘까?

그 다음으로 살펴볼 것은 XCTestCase라는 것인데

Unit Test / UI Test를 작성할 경우, 반드시 이 XCTestCase라는 것을 상속 받아야 함!

상속,,? 저아이,, 클래스인가요,,?

@interface XCTestCase: XCTest

옵젝씨 어서오고

넵 클래스임 그리고 얘는 또 XCTest를 상속받는데,

얘는 documentation을 보면 말이져

이런 메서드들이 있는데,

테스트 코드를 체크하고 프로젝트를 생성하면,

자동으로 들어 있던

이 setupWithError, tearDownWithError 등이 이 XCTest의 멤버인 것을 볼 수 있음

다시 위에 올라가서 이름이 살짝씩만 다른

setup, tearDown 메서드들을 살펴보면

에러와 함께 사용할 경우 (WithError)

비동기로 구현해야 할 경우(compoletion 또는 async)

그외의 경우

이렇게 세 가지 버전으로 있는 것

때에 따라서 알아서 쓰면 됨

만약 동시에 여러 개의 setup / tearDown 메서드를 쓸 경우,

불리는 순서가 다르니 이것만 유의 하셈

그래서 도당체 setup이랑 tearDown이 뭔데?

먼저 setup은 테스트가 실행되기 전에 자동으로 불림

따라서 테스트에 필요한 초기화 셋업하는 코드를 구현

tearDown은 테스트가 실행된 후 자동으로 불림

따라서 테스트에서 사용한 리소스가 있다면 정리하는 코드를 구현

자, 여기서 주의해야 할 점이

먼가 요거,, 우리가 기존에 알던 init,,, deinit 같은 느낌이거덩여?,, 할 수 있는데

TDD의 법칙 중 "테스트는 독립적이어야 하며, 다른 테스트에 영향을 주면 안됨"

이라는 법칙 기억 남?

따라서 이 SodeulTestTests 클래스가 생성될때 setup이 불리고,

사라질 때 tearDown이 불리는 게 아님!

테스트 한개 당 한번씩 setup, tearDown이 불리게 되어 있음

보여주자면,

이렇게 testA, testB, testC가 만약 있다 할 때

(테스트 만드는 법은 바로 뒤에 설명할 거)

SodeulTestTests 전체 테스트를 실행시키면

참고로 맨 왼쪽의 요 ▶️ 버튼을 누르면

SodeulTestTests에 작성된 전체 테스트가 진행 됨

쨌든 그러면 말이져

이렇게 테스트가 실행된 만큼 setup, tearDown이 불리는 것을 알 수 있음!

+ 아 그리구

func testPerformanceExample() throws

이 메서드도 자동으로 생성되어 있는데,

얘도 테스트 코드인데, 코드가 얼마나 빠르게 실행되는지를 테스트 해주는 것임!

4. 테스트 코드 작성 방법

테스트 코드라고 막... 이름 막.. 지으시면 안 되구여,,

나름대로 규약이 있음

먼저 필수 조건이라 함은

func testA() { }

이런 식으로 테스트 함수는 무조건 test로 시작해야함!

이건 필수 조건임

아니면 테스트로 인식 안함

그리고 보통 네이밍을 지을 때는

test대상_작업_예상되는결과

이런 패턴으로 작성함!

따라서

func testAddOperator_WhenAdded_returnsCorrectSum()

이런 식으로 테스트 이름만으로도

어떤걸 테스트하고, 어떤 결과를 예상하는지를 알 수 있게 작성해야 함!

만약 난 영어 싫어! 척화비 좋아! 하면

func test더하기연산자_더하기_올바른합리턴()

이렇게 한글로 작성해도 됨!

다만 앞에 test는 무조건 붙여주기로!!

이제 테스트 코드 함수의 이름을 작성 했으면,

테스트 코드 내부를 작성해야 하잖음??

이때 쓰는 패턴이 gwt 패턴이라고 해서,

given - when - then

세 가지 패턴으로 테스트 코드를 작성하는 것을 말함

given은 준비 단계,

when은 실행 단계,

then은 검증 단계

이렇게 세가지로 진행되는데,

막 세 단계를 무조건 지켜야돼!!! 이런 건 아님

필요에 따라 준비 단계가 생략되거나,

특정 단계를 반복해도 됨!

비슷하게 tripleA 패턴으로

arrange 준비단계,

act 실행 단계,

assert 검증 단계

로도 쓰긴 함! 패턴은 알아서 쓰셈

따라서 gwt 패턴 나오니까 갑자기

디자인 패턴 생각나면서 이게 모야 싶으시져?

진짜 별거 없음ㅎ

func testAddOperator_WhenAdded_returnsCorrectSum() {
    // Given (준비 단계)
    let a = 1
    let b = 2
    
    // When (실행 단계
    let result = a + b
    
    // Then (검증 단계)
    XCTAssertEqual(result, 3)
}
 

그냥 요렇게 주석으로 구분 해주시면 됨니다

진짜 별거 없져?

근데 test에서 검증 단계에 쓰이는 건

막,, 머 if result == 3 이런거 아니구영,,;;

XCTAssertEqual 같이 XCTest에 내장된 Assert 메서드를 사용함니당

따라서

이렇게 보면 값이 nil인지, true인지, false인지 등등

검증할 수 있는 메서드가 많이 존재하니 여기서 골라 쓰심 됨

5. 테스트 코드를 작성했으니 테스트를 돌려보자!

테스트 클래스 자체에 있는 Test Diamond를 눌러서 테스트를 진행 시킬 수도 있고,

이 경우 클래스 안에 작성된 모든 테스트가 실행됨

(참고로 테스트가 성공되면 초록색으로 변함,

테스트가 진행되지 않았을 경우, 회색 ▶️ 이 마크임)

혹은 이렇게 테스트 메서드마다 붙어있는 Test Diamond로

개별 테스트를 진행할 수도 있음

func testAddOperator_WhenAdded_returnsCorrectSum() {
    // Given (준비 단계)
    let a = 1
    let b = 2
    
    // When (실행 단계
    let result = a + b
    
    // Then (검증 단계)
    XCTAssertEqual(result, 100000)
}
 

만약 이렇게 검증 단계에서 잘못된 결론이 도출된 경우,

이렇게 테스트가 실패했다는 다이아몬드로 바뀌면서,

빨간 오류가 뜸!

6. 코드가 얼마나 테스트 되었나?

이렇게 리포트 네비게이터를 누르면 Tests 항목을 볼 수 있는데,

여기는 내가 테스트를 실행할 때마다 결과를 리포트로 제공해줌!

따라서 전체 테스트의 결과를 확인할 수 있음

코드 커버리지가 44%로 되어 있는 건,

전체 코드에서 얼마큼 테스트를 진행했는지를 나타내는 것인데

(전체 코드에서 테스트를 44프로 했단 거겠져?)

100%로 만드는것은 사실 불가능이고 ㅋㅅㅋ

보통 60~80%를 목표로 한다고 함

근데 수치보다 제대로 기능 테스트 했는가가 더 중요함

그리거 마지막으로

이렇게 Editor에서 Code Coverage를 켜면

이렇게 옆에 바가 생기면서 숫자가 있음!

이 숫자는 이 테스트를 몇 번 진행했는지를 나타내는 것이고,

테스트를 한 곳은 이렇게 초록색으로 표시해줌!
(테스트를 하지 않은 경우 숫자는 0으로 뜨고 빨간색으로 표시 해줌)

후.. 오랜만에 글쓰니까 힘드네용,,

그래도 Unit Test에 대해 공부할 시간이 없으셨던 분들은 참고가 되셨길 바라고!!!

그럼 이만~~~~~~~ 나 화이팅

Swift Testing에 대해선 나중에~~~ 다루겠슴니다

iOS) 유닛테스트(Unit Test) 맛보기 이론 (1/2)

소들이 — Tue, 11 Mar 2025 20:10:20 +0900

안녕하세요 :) 소들입니다

진짜 너무 오랜만이죠.. 네..

어떻게 지냈냐구요 ..? 어떻게 지냈어요.. ^.^..;;ㅋㅋㅋㅋ

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

작년은 큰 프로젝트를 맡게 돼서 너무 바빴구...

너무 바빴구.. 너무 바빴구.. (??) ..

그래도 담백한 인사 이후 1년 안지나서 왔자나요~!~!!

조회수 100만 달은 기념으로 왔심다

네 이번에 공부할 내용은

테스트 코드 중 Unit Test에 관한 것입니당 :)

다 아는 개념이라구여?

제가 원래 좀 뒷북 잘 치잖아여

간단한 개념(이번 편) > Xcode에서 맛보기 > 테스트코드 짜기

이렇게 총 3편이 될 것 같은데 오늘은 간단한 개념으로 가볍게 봅시당

모든 포스팅은 편의 말투로 합니다~!

1. 테스트 코드가 왜 필요 한가요?

자, 만약 우리가 다음과 같이

func add(a: Int, b: Int) -> Int {
    return a + b
}
 

위와 같이 매개변수 a와 b를 더해주는 함수를 짰다고 해보셈

물론 간단한 로직의 함수고 내용만 봐도 문제 없이 잘 짰짢아용

할 수 있겠지만,

add라는 함수는

매개변수 a + b를 더한 값이, 결과로 리턴 된다는 것이 검증이 "안" 되어있는 함수이기 때문에

우리는 그저 이 add 함수가 잘 짜여져 있을 거라 전적으로 믿고 사용하는 것밖에 되지 않음

만약 개발자가 실수로

func add(a: Int, b: Int) -> Int {
    return a + b + 1
}
 

이렇게 엉뚱한 코드를 짰다면,

이 함수는 분명 개발자 의도와 다르게 잘못된 결과를 return 할 거잖음??

따라서 우리가 이렇게 어떤 함수, 메서드를 짤 때

내부 구현을 문제 없이 했는지

1 + 1을 했을 때 원하는 2라는 결과값을 리턴하는지

애가 헤까닥 해서 1 + 1을 3으로 잘못 리턴하진 않는지

이런 "검증"의 결과가 필요하단 것임

따라서 함수나 메서드(Unit)가

제대로된 놈인지를 확인하는 과정이 필요하고,

그것을 검증하는 것이 바로

Unit Test라는 것임

이제 왜 테스트 코드가 필요한지 알겠음?

내 실수 줄이려고 하는거임 하하하

다들 졸릴 때 메서드 이상하게 구현 해본 적 있잖아~~~

이러면 안 되는 거잖아

코드가 나한테 이러면 안 되는 거잖아!!!

정리하자면

유닛 테스트에서 유닛(Unit)이라는 것은,

함수나 메서드 정로도 생각하면 될 것이고

이 함수나 메서드가

문제 없이 의도대로 잘 동작 하는지,

원하는 결과 값을 리턴 하는지,

얼마나 빠르게 실행하는지

를 테스트 하는 것이 바로 유닛 테스트(Unit Test)

라고 보면 됨!!

2. Unit Tests / Integration Tests / UI Tests

사실 테스트 코드를 짠단 것에

유닛 테스트만 존재하는 것은 아님

위 그림처럼 테스트는 피라미드 형태를 띄고 있는데!!

가장 맨 밑단에 존재하는 영역이 바로 유닛 테스트임

"유닛 테스트"는,

위에서 함수나 메서드들이

제대로 동작하는지, 얼마나 빠르게 동작하는지를

테스트하는거라 했잖음??

"통합 테스트"는

한단계 더 업그레이드 되어서,

두 가지 이상 기능들이 유기적으로 잘 동작하는지를 테스트 하는 것임

내 앱과 서버가 잘 통신하고 있는지, 데이터베이스에 정상적으로 연동은 되는지 등

다른 프로그램과의 연동을 테스트 함!

물론 유닛 하나하나를 봐야하는 유닛테스트보다 테스트 갯수는 적겠지만,

다른 기능과의 유기적 동작성을 보는 것이기 때문에, 테스트가 기능적으로 훨씬 더 복잡함!!

"UI 테스트"는

사용자의 입장에서 기능과 동작을 테스트 하는 것으로

로그아웃 버튼 눌렀는데 로그아웃이 제대로 되는지,

넌씨눈 회원가입 창이 뜨진 않는지 등

이런 UI적인 기능성을 테스트 하는 것임

이또한 피라미드 구조상 테스트 갯수는 통합 테스트보다 적을 테지만,

테스트를 작성하고 유지보수 하는 것에 시간이 갱장히 많이 들어감

(디자인 바뀌면 UI 테스트도 바뀌어야함 ..;ㅁ;)

+ 테스트 시간도 훨 많이 들음

쨌든 이런 식으로 테스트 코드를 짜는 것엔

위와 같이 피라미드 형태의 테스트들이 있다~ 정도만 알면 될 것 같음

3. 유닛 테스트의 5가지 규칙

깨끗하고 맑고 자신있는

유닛 테스트를 작성하기 위해서는

FIRST라는 5가지 규칙을 따르라고.. 하는데

F(ast) :

테스트는 빠르게 동작하여야 하며,

자주 돌릴 수 있어야 한다

I(ndependent) :

각 테스트는 서로 의존하면 안 되며,

독립적이어야 한다

(너네 둘 떨어져 )

R(Repeatable) :

테스트는 어떤 환경에서도 반복 가능해야 한다

테스트가 돌아가지 않는 환경이 있으면 안된다

(테스트 실패 변명거리만 됨 )

S(Self-Validating) :
테스트가 성공 했는지, 실패 했는지는 Bool 값으로 결과를 내야 한다

(테스트 결과는 통과 아님 죽음뿐 )

T(Timely) :

테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다

(사실 제일 어렵다 )

네 대충 별 거 없져??

사실 마지막이 젤 어려운듯 ㅋ

테스트 코드를 밀린 과제하듯이 마지막에 작성하면 안되는데 말이쟈..

이상과 현실의 괴리야

4. 유닛 테스트 코드를 작성해서 얻는 이점이 그래서 뭔데?

일반적으로 테스트 코드를 작성한다고 하면,

유닛 테스트를 의미하긴 함

따라서 유닛 테스트의 장단점을 봐보겠음

장점

"코드의 안정성 향상"

- 반복되는 테스트를 통해 이 과정에서 버그를 빨리 찾아낼 수 있음!

"모듈성 증가"

- 코드(메서드, 함수) 등이 기능별로 독립적으로 분리됨!

"새로운 기능 추가 시 빠른 테스트 가능"

- 유닛 테스트는 해당 부분만 독립적으로 테스트 하기 때문에

시간을 많이 잡아먹는 통합 / UI 테스트와 달리

새로 기능이 추가되거나 코드를 리팩토링 하여도

빠른 테스팅 및 문제 여부를 확인할 수 있음!

단점

기획자 : "빠르게 개발 안 돼요ㅠ?"

- 테스트 코드를 짠다는 것

테스트를 진행 한다는 것

그것은 곧 개발 시간이 증가한다는 것,,

"유지보수는 조상님이 해주시나"

- 기능이 바뀔 경우
테스트 코드 유지 보수에 대한 부담도 증가

"다른 객체와 미팅? 어림도 없어"

- 객체 자체가 독립적으로 모두 일을 처리하면 문제가 없지만,

다른 객체와 소통이 필요한 객체가 있을 수 있잖음?

근데 유닛 테스트는 독립적이어야 하기에 다른 객체와 메세지를 주고 받으면 안 됨 (테스트 코드 모솔이슈)

따라서 다른 객체 가면을 쓴 가짜 객체 (Mock Object)를 주입해서

어떤 결과를 반환해라! 하고 정해진 답변을 준비시켜야 하는데(Stub)

어쨌거나? 이것도 다 일이다

오늘은 테스트 코드의 간단한 이론에 대해 알아봤습니다

다음 포스팅에선 Xcode에서 테스트코드 어떻게 사용하는지에 대해 알아볼게용

조만간 봬요 ^^

RxSwift) Subject (3/3) - PublishSubject / BehaviorSubject / ReplaySubject / AsyncSubject

소들이 — Thu, 12 Oct 2023 20:56:00 +0900

안녕하세요! 소들입니당 :D

드디어.. Subject의 마지막 포스팅이네요

Subject 종류에는 어떤 게 있는지, 실제로 어떻게 사용하는지에 대해

알아볼 건데여!!!

이전 Subject의 개념 포스팅들이 너무 어려웠져....?ㅠㅠㅠㅠ

아마 이 포스팅 이해한 사람은.. 많이.. 없을거야.. 후엥ㅠㅠㅠ

이번 포스팅은 개념이 아니라 사용법이니 조금 마음 편하게 공부하시길 바랍니다 ㅎㅎ

모든 포스팅은 편의 말투로 합니다~!

1. Subject의 종류 4가지

복습을 짧게 하고 가자면,

Subject라는 것은 Observer이자 Observable의 역할을 하는 친구고

Observer가 구독할 경우 모든 이벤트를 다 방출 받는 Cold Obsevable과 달리,

구독을 하는 시점 이후부터 발행되는 이벤트만 받는 Hot Observable로 동작한다 했음

또한 자신을 구독하고 있는 여러 Observer들에게

이벤트가 발행됐을 때 그 값을 전달하는 Observer 역할도 한다고 공부해씀

때문에 당연히 Multicast로 동작하구요?

아이 쉽다 쉬워!

근데 지금껏 우리가 Subject를 공부할 때 종류를 공부하지 않았기 때문에

대충 이런 Subject가 있다!!! 하면서 했었단 말임?

그게 바로 PublishSubject라는 것이었음

근데 사실.. PublishSubject가 뭐하는 놈인지는 1도 모르고요 ㅎㅎ;;

그냥 Subject는 다 요놈으로 때려 바긍면 되나요? 싶겠지만,

Subject의 종류는 총 4가지나 된답니다.

PublishSubject

BehaviorSubject

ReplaySubject

AsyncSubject

아 뭔 종류가 4가지나 돼 ...!!!!!! 하겠지만..

Subject를 제대로 이해 했다면... 정말정말 쉬움...!!!

하나씩 보겠음다!

1-1. PublishSubject

PublishSubject는 구독 이후에 방출된 항목들만 옵저버에게 전달합니다

우리가 앞서 Subject를 공부할 때 배운 내용 그대로임..!

Cold Observable과 달리 Hot Observable은

구독 이후에 방출된 항목만 옵저버에게 전달된다고 했음!

따라서 예로 보자면,

let subject = PublishSubject<String>()

이렇게 String의 항목을 방출하는 PublishSubject를 생성하고,

subject.subscribe(onNext: {
    print("첫번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)
 
subject.onNext("1")
subject.onNext("2")
 
subject.subscribe(onNext: {
    print("두번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)
 
subject.onNext("3")

이 PublishSubject를 구독할 경우,

"구독한 이후부터 방출되는 이벤트를 Observer가 받을 수 있다"

를 이해해짜늠

따라서 위와 같은 결과가 나온 걸 알 수 있었움

아항.. ㅇㅋㅇㅋ!!!! 알앗서!

근데 .. 그럼 다른 녀석들은 구독 전 녀석들도 받는 건가?

그럼 Cold Observable 아녀?? 하고 생각이 들 지 않나여???

의문을 갖고 다음으로 넘어가봅시당

1-2. BehaviorSubject

BehaviorSubject는 구독할 경우,

Observable이 가장 최근에 발행한 항목(아무것도 발행하지 않았다면 초기값)을 한번 방출하며

그 이후부터 Observable에 의해 방출된 항목들을 Observer에게 전달합니다

정의로 보니 말이 쪼꼼 어려울 수 있는데,

말 그대로 가장 최근에 방출된 값을 얘는 가지고 있음!!!!

그래서 어떤 Observer가 자신을 구독했다고 하면,

그 Observer가 구독하기 이전에 가장 최근 값을 이 Observer에게 방출해주는데,

만약 Observer가 구독하기 전에 이벤트가 한번도 방출이 안 됐으면 어케요!? 하잖음??

따라서 한번도 방출이 안 됐을 때를 대비해 전달 할 "초기값"이라는 것을

BehaviorSubject를 선언할 때 같이 정의를 해주어야 함

let subject = BehaviorSubject<Int>(value: 1)

이런 식으로!!

value 파라미터를 통해 초기값을 지정 해주고 나면,

이제 이벤트가 방출이 한 번도 안 된 따끈따근한 이 subject를 구독할 경우,

subject.subscribe(onNext: {
    print("첫번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)

이때는 아직 방출된 이벤트가 없기 때문에,

우리가 BehaviorSubject를 초기화 할 때 지정한 초기값이 바로 방출됨

근데 이제 이 Subject에 만약 onNext를 통해 여러 이벤트가 방출되고 나면 어케 대냐

subject.subscribe(onNext: {
    print("첫번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)
 
subject.onNext(2)
subject.onNext(3)
 
subject.subscribe(onNext: {
    print("두번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)

이렇게 onNext를 통해 2와 3이라는 값을 방출하고 난 후,

두번 째 Observer가 이 subject를 구독할 시 받게 되는 항목은

가장 최근에 방출된 이벤트인 "3"이 되는 것임

어렵지 않죠!?!?!

자, 여기서 절대 헷갈리면 안 되는 것이,

구독했을 때 가장 최신에 방출된 값을 "한번" 방출해주는 것이 BehaviorSubject이지

한번 방출 받은 이후부턴 그냥 우리가 알던 Observable처럼 방출되는 값을 계속 받게 되는 것임

아항 정리해보자면,

❄️Cold Observable❄️은

구독 시점과 상관 없이

방출하는 모~~든 값을 다 Observer에게 온전히 전달하는 게 목적이라면,

Hot Observable(Subject) 는

구독 시점에 따라 방출 받을 수 있는 값이 달라질 수 있구나!

➡️ 근데 내가 구독 전에 이미 방출되어 날라가버린 이벤트들? 응 필요없어~

싶으면 PublishSubject를 쓰면 되고,

➡️ 에헤이 조졌네 제가 구독하기 전 가장 최근에 방출된 값이라도 "한번"만 받게 해주쇼잉...

할 때 쓸 수 있는 게 BehaviorSubject구나!

별거 없져?

근데 만약 나는 아 ... 가장 최근에 방출된 값 한번으로는 부족한데 ...

거.. 서비스 차원에서.. 가장 최근에 방출된 값 4-5개 정도 주면 안 될까..?

할 때 쓸 수 있는 게 바로

1-3. ReplaySubject

최신 이벤트를 버퍼 사이즈에 맞게 저장하고,

Observer가 구독할 시 버퍼에 있는 이벤트를 모두 전달합니다

BehaviorSubject의 역할에서 "두 개 이상"의 이벤트를 저장하고 싶을 때 사용합니다

BehaviorSubject가 가장 최근에 방출된 값을 딱 1번 방출해줬다면

얘는 말그대로 내가 받고싶은 만큼 버퍼의 사이즈를 지정해서 구독 시 받을 수 있음ㅎㅎ

따라서 선언할 때

let subject = ReplaySubject<Int>.create(bufferSize: 3)

요롷게 create 메서드를 이용해 버퍼 사이즈를 지정해주면 되는데,

BehaviorSubject와 달리 초기값을 설정해주지 않기 때문에,

subject.subscribe(onNext: {
    print("첫번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)

아무 항목도 방출하지 않았을 때는

해당 Subject를 구독해도 아무런 값도 방출하지 않음!!!!

만약, 다음과 같이 1,2,3,4라는 항목이 순서대로 방출되었을 경우

subject.subscribe(onNext: {
    print("첫번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)
 
subject.onNext(1)
subject.onNext(2)
subject.onNext(3)
subject.onNext(4)
 
subject.subscribe(onNext: {
    print("두번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)

이때는 버퍼의 size가 3이기 때문에

가장 최근에 방출된 값 3개만 저장을 할 수 있어서,

이 이후에 두 번째 Observer가 구독을 할 경우,

이렇게 가장 최근에 발행된 2,3,4라는 항목을 고대로 받을 수 있음!!!

다만, 버퍼의 크기를 우리가 지정해주는 만큼

버퍼의 크기는 딱 필요한 만큼만 지정해주는 것이 메모리 관리상 중요함!!

1-4. AsyncSubject

AsyncSubject는 completed 이벤트가 전달되기 전까지 어떠한 이벤트도 방출하지 않습니다

completed 이벤트가 전달되면, 가장 최근에 전달된 값을 방출합니다

지금까지 위에서 본 3가지의 Subject는

Observer가 Subject을 구독하는 즉시 바로 이벤트를 전달 받을 수 있었음!!

하지만 AsyncSubject는 이름에서도 느낌 오듯이

completed 이벤트가 전달되기 전까진 어떠한 이벤트도 방출을 하지 않다가,

completed이란 이벤트가 전달되면, 가장 최근에 전달된 값을 방출 함!!!

충분히 이해가 될 거 같으나 예제로 보면,

let subject = AsyncSubject<Int>()

이렇게 AsyncSubject를 생성하고

subject.subscribe(onNext: {
    print("첫번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)
 
subject.onNext(1)
subject.onNext(2)
subject.onNext(3)
subject.onNext(4)

구독해서 아무리 값을 전달해도 아무런 Observer는 이를 받을 수 업..서...

DJDOC의 부치지 못한 편지 ... 노래 죠은뎅..

뭐 여튼 다음과 같이 해당 subject에 대고 onCompleted을 호출하면

subject.onCompleted()

요러케 호출 해야만,

이제서야 가장 마지막에 전달된 값을 Observer에게 방출하고 정상종료 되는 것임!!!

(물론 초기값이 없ㄱ ㅣ때문에 Observable이 값을 전달하지 않으면 아무것도 방출도지ㅣ 않고 끝남)

Subject 사용법 개쉽네 하하 ㅋ

2. 정리

	PublishSubject	BehaviorSubject	ReplaySubject	AsyncSubject
구독 시 방출되는 최근 값	X	가장 최근 값 (없을 시 초기값)	버퍼 크기만큼의 최근 값들 (없을 시 X)	X
특징	구독 이후로 방출되는 이벤트만 받음	가장 최근 값 1번 받을 수 있음	가장 최근 값을 여러 번 받고 싶을 때 사용	onCompleted이 불릴 때 가장 최근 값 한번 받음

훔 ....... 이전 포스팅들에 비해 매우 쉽군요 ..

근데.. 재밌는 게 뭔지 아세요 ....

저는 사이코 개발자인 걸까요.. 아니면 사이코 글쟁이인 걸까요..

어려운 개념 포스팅이 훨씬 재밌고,,, 이런 사용성 포스팅이 너무 재미가 엄습니다 .. 후

진짜 BJ 이상호 아님

오늘의 마무리는 아푸리카의 아무말 대잔치

틀린 내용이나 오타는 언제든 지적 환영입니다 :>

RxSwift) Subject (2/3) - Subject의 Observer 역할

소들이 — Sun, 24 Sep 2023 19:39:53 +0900

안녕하세요! 소들입니다 :)

최근에 제 RxSwift 포스팅과 관련해, "포스팅 내용이 너무 어렵다!" 라는 말을 들었습니다

네.. 사실 맞아요! 제 블로그 글 중에 RxSwift..!?

특히 개념 쪽 부분은 상당히 어려운 편에 속합니다

쉽게 쉽게 설명해주려고 해도 내용 자체가 심오해서 어쩔 수가 없네요 .. ㅠㅠ

누군가는 Third Party Library를 왜 이렇게 심오하게 다루냐 할 수도 있지만,

저는 원리도 모른 채 문법을 외워서 기계처럼 쓰는 것을 매우 기피하는 사람이라..

그리고 어차피 님들 Swift Combine 쓸 거 아님...??? 비슷한 기능 까본다 생각하면 되자나!!!

만약 원리 필요 없어! 사용법만 원해! 하시는 분이라면 다음 포스팅으로 가버렷!!

서론이 왤케 장황 하냐면,

오늘 내용도 (많이?) 어려워서 ㅎㅎ.. 네.. 열심히 공부하란 말입니다

저 평일에 퇴근하고도 진짜 열심히 공부하고 포스팅 썼는데..

내용이 어려워서 그른가,, 포스팅까지 꽤 걸렸네여??

만약 제가 틀린 내용이 있다면 바로바로 피드백 주시길 바랍니다!!

모든 포스팅은 편의 말투로 합니다~!

1. Subject의 Observer 역할이 뭔데요?

앞서 우리가

Observable은 항목(이벤트)를 방출!

Observer는 Observable을 구독하여 이벤트를 받음!

이라고 했잖음??

근데 사실 우리가 직접 Observer를 만들어 쓸 일이 없었기 때문에,

Observable에 비해서 Observer가 조금 생소할 수 있음...

꽤나 여러 번 말했지만,

우리가 Observable을 구독할 때 사용하는 subscribe(onNext:...)라는 메서드는

Observer 자체가 가진 게 아니었음!!!

extension ObservableType {
    public func subscribe(
        onNext: ((Element) -> Void)? = nil,
        onError: ((Swift.Error) -> Void)? = nil,
        onCompleted: (() -> Void)? = nil,
        onDisposed: (() -> Void)? = nil
    ) -> Disposable {
        ...
    }
}
 

Observable 클래스가 채택하고 있는

ObservableType이란 프로토콜 extension에 정의되어 있고,

이 subscribe(onNext...) 메서드를 잘 까보면

AnonymousObserver라는 observer를 자체적으로 생성해서

해당 Observable에 대고 이 observer를 subscribe 해주었단 것을 알았잖음??

때문에, 우리가 직접 Observer를 생성할 일이 없었던 것임!

근데..

Subject도 subscribe(onNext:...)로 구독해서 받을 수 있었단 말임..?

그렇게 받고 있었고요?

subject.subscribe(onNext: {
    print("첫번째 Observer가 받는 항목 : \($0)")
}.disposed(by: disposeBag)
 
subject.subscribe(onNext: {
    print("두번째 Observer가 받는 항목 : \($0)")
}.disposed(by: disposeBag)
 
subject.onNext(Int.random(in: 0..<100))

이런 식으루!!!

물론 이벤트를 방출하는 방법은 달랐지만!!

근디.. 어차피 subscribe(onNext:...) 메서드를 쓰는 거라면,

해당 메서드 내부에서 AnonymousObserver를 자체적으로 생성해서 구독해줄거잖음..

그럼 그냥 Observable과 다른점이 뭐임..?

Subject는 분명 Observable + Observer라구 했는데..

이렇게만 보면 Observer의 역할은 보이지 않구,

Subject는 Observable이

Hot 인지 / Cold❄️인지

unicast인지 / multicast인지

에 대해서만 관여하는 "Observable" 역할로만 동작하는 거 아닌가요!?!

싶지 않음?? 난 매우 그랬는데!!!!!

이 의문을 해결하기 위해,

우린 Observer에 대해서 좀 더 까봐야 합니당

2. Observer를 좀 더 까봅시당

자, 먼저!

Observer라는 것을 좀 더 자세하게 볼 건데여

어떤 객체가 Observer의 역할을 하기 위해선

이렇게 ObserverType이란 프로토콜을 채택하고 있어야 함!!!

그리구, 이 ObserverType이란 프로토콜은

on(_ event: Event<Element>)이라는 메서드를 필수적으로 요구하는데,

이때 on이라는 메서드의 파라미터 타입인 Event 타입은

next, error, completed이 정의된 열거형 인스턴스인 것을 알 수 있음!!!

이잉? 저게 머하는 건데요? 싶을 수 있으나,

우리가 Observable을 볼 때 다 공부한 것임!

항목 방출(next), 에러(error), 정상종료(completed)!!!

좀 더 쉽게 이해해보기 위해 예를 봅시당!!

이 observer의 on이라는 메서드가 언제 불리는지를 보면 되는데,

우리가 Cold Observable 만드는 방법 중 가장 간단한 just 클래스를 보면,

init할 때 받았던 element(항목)을 저장하고 있다가,

subscribe가 불릴 경우 그와 동시에 파라미터로 받은 observer에 대고

on(.next(self.element)) 하면서 항목을 방출하고,

또 observer에 대고 on(.completed)을 하는 것을 볼 수 있음

아항!

observer의 on이라는 메서드는,

Observable이 어떤 Event를 방출할 때,

이를 Observer에게 전달할 때 사용하기 위한 메서드이구나!

정리하자면,

Observable에서 일어나는 이벤트를 이 on이라는 메서드를 통해 Observer가 알 수 있는구나!

따라서 Observer가 필수적으로 구현해야 하는 메서드구나!를 알면 됨

그럼 이제,

이걸 우리가 알고 있는 AnonymousObserver와 Subject는 이 on이라는 메서드를

각각 어떻게 구현하고 있나 나눠서 보겠음!!

어려울 수 있고... 함수가 잘 안 보일 수 있으니 확대해서 보길 바람

2-1. AnonymousObserver의 Observer 구현

기존에 우리가 subscribe(onNext:...)를 썼을 때

자체적으로 생성한 AnonymousObserver 또한 당연히 Observer 역할이기 때문에

AnonymousObserver의 부모 클래스인 ObserverBase에

ObserverType이란 프로토콜을 채택하고 있음!!

또한, ObserverType 프로토콜에서 요구하는 on 메서드는

(부모 클래스) ObserverBase 안에 정의되어 있음!!!

그러면 이 on 메서드는 Observable이 항목을 방출(.next) 했을 때의 예로 보자면

부모 클래스가 아닌,

AnonymousObserver 자체에서 오버라이딩 한 onCore라는 메서드를 호출함!

그럼 이 onCore 메서드는 내부에 정의된 eventHandler라는 클로저를 호출하는데,

이 eventHandler라는 것은,

subscribe(onNext:...)메서드가 AnonymousObserver를 만들 때 등록해둔 클로저이고

즉,

우리가 subsribe(onNext:...)메서드를 호출하며 정의한 클로저가 실행이 된단 것임!!

자, 여기까지 이해를 했으면

우리가 subscribe(onNext:...) 메서드를 통해 Observable이 항목을 방출 했을 때

어떤 어떤 작업을 하겠따! 하고 작성해둔 클로저가,

어떤 플로우를 통해 실행이 됐는지를 알 수 있었을 거임!!

정리하자면,

Observer라는 것은

"Obsevable이 Event를 방출 했을 때 누군가에게 알리는 역할"

이라는 것을 이해하면 됨

지금은

Observer를 통해 Observable을 구독한 우리(해당 subscribe메서드를 작성한 인스턴스)가

Observer가 알려야 하는 "누군가"가 될 것임!!!

Observer가 없으면, Observable이 항목을 방출했든, 에러를 방출했든

아무도 모를 거 아님!! ㅎㅎㅎ

이 관점으로 이해를 한 상태로,

Subject가 on 메서드를 어떻게 구현하고 있는지를 보자ㅏㅏ

2-2. Subject의 Observer 구현

subject 또한 Observer의 역할을 한다고 했기 때문에,

이렇게 ObserverType을 채택하고 있음!!!

그럼 Subject의 on 메서드는 어떻게 구현되어 있을까!?

갑자기 집중력이 흐려지져? 눈 앞이 뿌옇져? 나가고싶져?

나는 어렵다 했어 몰라!

뭐 쨌든 Subject의 on 메서드는 대충 이렇게 구현되어 있는데,

AnonymousObserver처럼 바로 등록된 클로저를 실행시키는 게 아니라

if DEBUG 조건문을 빼고 본다면 dispatch 메서드의 첫 번째 파라미터로

self.synchronized_on(event)라는 메서드의 반환값을 넘겨주고 있음..

그럼 self.synchronized_on(event) 얘가 뭘 반환하는데..?

대충 .next라는 메서드가 들어왔을 때를 보면,

self.observer"s"라는 옵저버 뭉탱이를 반환하고 잉네

흐헝 observers까지 까보면 진짜 머리 빠개지니까

그냥 observers는 이름 그대로 observer"들"을 담는 객체라고 생각을 하겠음

그럼 Subject가 갖고있는 이 observers가 뭔데..? 할 수 있잖음??

이는.. 말야...!!! 다시 돌아가봐야 하눈데..!!!

우리가 subject에 대고 subscribe(onNext:...)메서드를 호출했을 때

지겹도록 봤던 AnonymousObserver를 만들고,

이 observer를 observable에 대고 subscribe(_ observer: Observer) 메서드를 호출 하잖음??

근데 Subject는!!!

이 subscribe(_ observer:Observer) 메서드를 자체적으로 오버라이딩 하고 있는데,

Subject에서 오버라이딩 한 subscribe가 불리면 어떤 일이 일어나냐면,

대충 하이라이팅 친 부분만 보면, 해당 observer를 observers에 insert 하는 것을 볼 수 있음

만약,

우리가 subscribe를 여러 번 하면

이렇게 각각의 observer가 생성되어,

Subject의 subscribe(_ observer: Observer) 메서드에 의해

Suject 인스턴스가 가지고 있는 observers라는 객체에 insert 되는 것까지 알았음!!!

않이,, Observable에 대고 subscribe를 호출 했을 땐,

단순히 클로저를 등록하고 Observable이 이벤트를 방출 했을 때

그 클로저를 실행하느 게 끝이었자나여!!

Subject는 왜 observers라는 것도 만들고

여기에 각각의 observer를 등록하는 과정이 들어가는 거져!?!?!? 싶잖음

이것이 바로, subject의

multicast 방식 때문임...!!!

subject는 unicast로 동작하는 Observable과 달리,

multicast로 동작한다 했잖음??

따라서, Observable이 어떤 이벤트를 방출 했을 때,

동일한 결과를 해당 Subject를 구독하고 있는 Observer"들"에게 모두 알려야 하기 때문임!!!

아까 Subject는 on이라는 Observer의 메서드를 실행하면,

이렇게 synchronized_on이라는 메서드를 통해

자신을 구독한 observer들의 모임인 "observers"를 반환받고,

이를 dispatch라는 메서드를 통해 발생한 event랑 함께 넘기는데,

이 disptach라는 메서드에서는

매개변수로 받은 observers순회하며

observable에서 event가 방출됐음을 알려주는 것임!!!!!

때문에 Subject에서

자신을 구독한 Observer들에게 모두 동일한 이벤트를 줄 수 있었던 것임

아까 내가 Observer를 어떤 관점으로 이해해야 한다 했냐면,

"Obsevable이 Event를 방출 했을 때 누군가에게 알리는 역할"

이라 했짢음

따라서!!! 이번 포스팅의 주제인

⭐️Subject의 Observer 역할⭐️은

"Obsevable이 Event를 방출 했을 때 나를 구독한 Observer들에게 알리는 역할"

이라고 이해를 하셔야 함!!!

Subject가 나를 구독한 observer에게 해당 이벤트가 발생했음에 대해 각각 알리고 나면

➡️ 여기까지가 Subject의 Observer로서 역할

각각의 observer는 subscribe(onNext:...)를 통해 받은 클로저를 실행하여

이벤트를 우리(해당 subscribe를 실행한 인스턴스)에게 알려주는 것임

➡️ 여기서부턴 Anonymous의 Observer로서 역할

실제 Subject의 Observer 역할인 on 메서드를 보면,

Notifies all subscribed observers about next event
구독한 모든 observers에게 next event에 대해 알립니다

라고 쓰여있는 것을 볼 수 있음 ㅎㅎ

+ 사실 우리가 Subject에서 이벤트를 보낼 때 쓰던 onNext(_ element) 메서드 있잖음 ?ㅎㅁㅎ

이는 사실 Observable이 직접 항목을 방출할 수 있게 하는 메서드가 아니라,

ObserverType에 정의된 메서드임!!!

우리가 공부한 Observer의 on 메서드의 파라미터로

해당 Event를 만들어서 호출하는 것을 볼 수 있음!!

이만하면 의문이 다 풀렸길 ㅎㅁㅎ

3. 정리

Observer의 역할을 하기 위해선 ObserverType이란 프로토콜을 채택해야 한다

ObserverType이란 프로토콜은 on(_ event: Event)라는 메서드를 필수적으로 구현해야 하는데,

Subject에서 이 메서드를 나를 구독한 observer"들"에게 각각 이벤트가 왔음을 실행시켜주게 구현되어 있다

따라서, Observer 역할이라는 것은

Observable이 이벤트를 방출 했을 때 그것을 "누군가"에게 알리는 역할이고,

Subject에서는 나를 구독한 모든 Observer들에게 이벤트 방출을 알리는 것으로써

Observer 역할을 수행하고 있따

넹... 길고 길었네요...

뭔 거의 2주가량 포스팅을 한 건지 ... 알 쑤가 업써...

나눈 왜 주말에도 왜 공부를 하고 있는지 알 쑤가 업써...

에헤이 조졌네 이거

이 글의 포스팅 후기입니다..ㅋㅋㅎㅋㅎㅋㅎㅋㅎㅋㅎ

잘못된 내용이나 피드백거리 있으면 꼭 댓글 주세요!!!!

모두 이해 하셨길 바라며 20,000ㅎㅎㅎㅁㅎㅎㅎㅎ

RxSwift) Subject (1/3) - Subject의 Observable 역할

소들이 — Sat, 9 Sep 2023 20:00:06 +0900

안녕하세요! 소들입니다 :)

저는 이제 망아지들을 완전히 탈출하여 매일 오공완! 오운완! 오롤완!을

외치는 삶을 살고 있땁니다!! (하루의 마지막으로 칼바람 뜰 사람!!??)

오늘도 주말이지만 친한 동료들과 카페 와서 공부하고 있구요!?ㅋ

PT도 받고 있어서 조만간 근육몬도 될 거구요?ㅋ

그나저나.. 오늘은 Subject에 대해서 알아보려고 해요!

RxSwift 포스팅이 꽤 시기 늦은 감이 있지만.. 굉장히 많은 분들이 봐주셔서.. =-=..

이번 포스팅은 Observable, Observer를 배울 때처럼 깊고 어렵진 않으나..

해당 포스팅에 대한 이해가 없으면 이해가 힘들 수 있어 먼저 읽고오시길 추천하겠습니다!

모든 포스팅은 편의 말투로 합니다~!!

1. Subject가 뭔가요?

Subject의.. Observable..역할 어쩌고.. 하기 전에..

우리가 오늘 공부할 Subject라는 것이 도대체 뭔지!개념부터 보겠음 :D

Subject는 Observer이자 Observable입니다

Observer이기 때문에 하나 이상의 Observable을 구독할 수 있으며,

동시에 Observable이기 때문에 새로운 항목(item)들을 방출하거나 재방출 합니다

히히.. 뭐라능겨 .. ..

이를 이해하기 위해서 지금까지 앞서 공부한

Observable과 Observer란 것을 개념부터 짧게 정리하고 가보겠음

Observable이란,

비동기 이벤트를 관찰이 가능한 형태로 만든 것으로,

해당 이벤트가 발생했을 때 "항목(item)"이란 것을 "방출(emit)"함니다

Observer란,

내가 원하는 비동기 이벤트를 방출하는 Observable이 있을 경우,

해당 Observable을 "구독(Subscribe)"하여

항목이 방출되었을 때 그 항목을 받아 처리할 수 있슴니다

자 여기까진 기본 개념이잖음?

그렇다면 Observable이란 놈은 어떻게 구현 되어있다고 했음??

ObservableType이란 프로토콜을 채택하는 제네릭 클래스로 구현이 되어있다!

따라서 Observable을 만들기 위해선 이 Observable이란 클래스를 사용해야 했음!

그렇다면 Observable까진 오케이!

이제 Observer로 넘어가서,

우리는 사실 이전 포스팅에서 Observer를 직접 생성하거나 살펴보진 않았음

왜냐?? ObservableType에서 제공하는 구독 메서드, 즉 subscribe를 사용하면

자체적으로 AnonymousObserver란 Observer를 생성해서,

해당 Observable에 subscribe를 해줬기 때문임

근데 이제 이 AnonymousObserver라는 것도 자세히 까보면,

ObserverBase란 클래스를 상속받고 있는 것을 볼 수 있고,

이 ObserverBase란 클래스는 ObserverType이란 프로토콜을 채택하고 있는 것을 볼 수 있음

무슨말이냐, Observer 역할을 하기 위해선,

ObserverType이라는 프로토콜을 준수해야 함!

(이는 다음 포스팅에서 더 자세히 다룰 거니 일단 여기까지만)

최종적으로 정리하자면!

Observable의 역할을 하기 위해선 Observable이란 제네릭 클래스를 상속받아야 하고,

Observer의 역할을 하기 위해선 ObserverType이란 프로토콜 채택이 필요함

근데 Subject는 말이야 ..

Observable과 Observer의 역할을.. 동시에 한다며..

그러면 Subject라는 놈은

Observable 클래스를 상속받는 동시에, ObserverType도 채택하고 있어야 하겠네여!?!?

당장 PublishSubject가 뭐하는지는 울 집 강아지도 몰라

호옹이.. 정말이자너!?

PublishSubject가 뭔진 모르겠지만 이 Subejct란 놈은

Observable 역할을 위한 Observable이란 클래스를 상속받는 동시에,

Observer 역할을 위한 ObserverType을 채택하고 있는 것을 알 수 있음!!!

아, 그래서 Subject는 Observer이자 Observable의 역할을 한다는구나!를

아주 살짝만 이해를 하고 가면 됨

2. 그럼 Subject는 언제, 왜 쓰는데요?

Subject의 개념을 이해 하긴 했으나, 여러분은 의문이 드셔야 함

아 구랭구랭 Subject가 Observable과 Observer의 역할 둘다 하는거? 대충 느낌 알았어

근데 그럼 Subject는 언제 왜 쓰는데!?!??!?

이를 이해하기 위해선 Observable과 Subject의 차이를 보면서 해야함

그전에 먼저 Observable도 마치 아메리카노 처럼

뜨거운 Observable과 차가운 Observable이 있단 것을 앎?!

저는 아옵으로.. 주세요 ☕️

2-1. Hot Observable vs Cold Observable

사실 Observable의 종류는 총 두 가지가 있답니다..!??!?

먼저,

❄️ Cold Observable ❄️

구독이 되어야만 비로소 항목(이벤트)을 방출하는 Observable

어느 시점에 구독하든 같은 결과를 받습니다

Hot Observable

구독 여부와 상관 없이 항목(이벤트)을 방출하는 Observable

구독하는 시점에 따라 방출되는 결과가 다릅니다

처음부터 방출되는 결과를 받지 못할 수 있습니다

이보시오 소들양반..

Subject를 공부하는데 웬 갑자기 뜨아 아아 논쟁이요.. 싶겠지만 ..

우리가 지금껏 공부했던 Observable 연산자 뭐가 있음..?

just, of, create... 등등이 있잖음??

이 Observable들을 공부할 때 특징이 뭐였음?

let observable = Observable.just(1)

이렇게 Observable을 생성한다 해서 바로 항목인 "1"을 방출하지 않음!

그럼 언제 방출함??

observable.subscribe(onNext: { (data) in
    print(data) // 1
})

이렇게 이 Observable에 대고 "구독"을 했을 때,

그때야 1이란 항목이 방출되었었음!!!

뭘 말하고 싶은 거냐면,

우리가 지금껏 공부했던 Observable 연산자들은 모두

Observer가 Observable을 구독 되어야만 비로소 해당 이벤트가 방출되는

❄️ Cold Observable ❄️이었던 것임!!

근데 마리야!

Subject는... Hot Observable 이랍니다..!!!

따라서 Subject를 사용할 경우,

내가 구독한 시점부터 방출되는 이벤트만 받을 수 있고,

내가 구독하기 전에 이미 방출되어버린 이벤트는 받을 수 없음!!!

예로 이해를 해보자면..!

유튜버에서 "알람"이라는 것을 Observable로 구현한다고 해보셈

우리가 만약 소들이란 유튜버를 알람 설정하고 싶음!

그러면 이제 알람 설정을 한 시점부터, 소들이가 영상을 올리거나 라이브를 할 때 알람이 와야 하잖음!?

그럼 이때는 Observable을 구독한 시점부터 항목이 방출되는 Hot Observable을 사용해야 할 것임!!

만약 이때 Cold Observable을 사용하면 ...

소들 유튜버가 가입 시기부터 쓴 글과 라이브들의 과거 알람들도 다 오는 대환장 파티가 될 거잖음!!

살짝 이해가 되셨나..?

아니! 이해 안 가! 그래서 그게 뭔데! 하시는 분들을 위해..

조금 더 쉽게 정리를 해볼게요!

자, 우리가 지금까지 배운 Observable 생성 연산자들!

이 Observable이 구독되었을 때

let observable = Observable.just(1)


 


let observable = Observable<String>.create { observer in
    observer.onNext("첫 번째 방출")
    observer.onNext("두 번째 방출")
    observer.onCompleted()
    observer.onNext("세 번째 방출")
    return Disposables.create()
}

나는 이런이런한 항목을 방출할 거예요! 라는 코드를 작성 했었음!

(just의 경우, 나는 1이란 숫자를 한번 방출 할 거예요! 고,

create의 경우, 나는 print를 두번 찍고 completed을 호출해서 정상 종료할 거예요! 잖음)

그리고, 실제 이 Observable을 구독했을 때

이렇게 미리 정의된 코드에 의한 항목이 방출되며,

Observer는 이 방출되는 항목을 오롯이 다 받을 수 있었음!

이것이 바로 ❄️ Cold Observable ❄️ 이란 것임!

자 여기까진 이해가 가시져!?!?

그럼,

Hot Observable 인 Subject 또한 코드로 이해해보면 좀 더 쉬울 거같음!

Subject는 물론 후에 배울 종류에 따라 다르지만 PublishSubject라는 것으로 보면

let subject = PublishSubject<String>()

이런 식으로 선언함..!!

대충 제네릭 타입을 String으로 선언한 거로 보아,

String의 항목을 방출하는 건 예상해볼 수 있지만

위에서 Cold Observable을 정의할 때와 어떤 게 다른지 확 보임?!?!

어떤 항목을 방출할 것인지에 대한 정의가 없음!!!!

아항.. 이 말 뜻이 뭐냐면 Hot Observable은,

Cold Observable마냥 내가 어떤 항목을 방출할 것인지를 생성 당시 정의해두는 것이 아니라,

내가(개발자가) 원하는 시점마다 항목을 방출할 수 있다는 것임!!

구독했을 때 온전히 처음부터 모든 항목을 다 방출해줘야 하는 Cold Observable과 달리,

나는 항목 발행 하고싶을 때마다 내 알아서 발행 할 곤뎅?

만약 내 항목 받고 싶으면 구독 하든가? ㅋ

근데 너가 구독하기 이전에 내가 이미 방출해버린 항목 못받는 건 내 알바 아닙니다!?

가 바로 Hot Observable이란 것임!

따라서, Subject를 생성했을 경우,

let subject = PublishSubject<String>()
subject.onNext("1")
subject.onNext("2")

이렇게 onNext라는 것을 통해 내가 원할 때마다 항목을 발행 할 수 있음!!!

(3편에 공부할테니 아 onNext? 그렇구나! 하고 넘어가셈)

따라서, Subject는 Observer가 구독하는 "시점"에 따라서

subject.subscribe(onNext: {
    print("첫번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)
 
subject.onNext("1")
subject.onNext("2")
 
subject.subscribe(onNext: {
    print("두번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)
 
subject.onNext("3")

이렇게 Observer가 받을 수 있는 항목이 달라질 수 있게 되는 것임

(Hot Observable이라 두번 째 Observer의 경우, 구독 전에 발행된 1, 2 항목은 받을 수 없는 것)

이제 Hot Observable과 Cold Observable의 차이가 이해가 가셨길 :)

3. Observable(unicast) vs Subject(multicast)

엥 위에서 Hot Observable.. Cold Observable 비교 한거 아닌가요 ..

웬 또 unicast... multicast.. 비교죠..?.. 싶죠 ..

예 ..저도.. 그럽니다.. 이제 운동 해야되는데.. 보내줘 후엥..

사실 위에 내용을 다 이해 했다면 아주 간단하게 끝날 내용임!!!

앞서 공부한 내용이 뭐임?

Cold Observable은 Observer가 어느 시점에 구독하든 똑같은 항목을 발행하는 거였고,

Hot Observable은 Observer가 언제 구독하든 말든 발행하는 거였잖음?

따라서 (Cold) Observable은 unicast고

(Hot Observable인) Subject는 multicast임ㅋ

아하하 ㅋ 끝 ㅋ 하고 싶으나.. ..

예제로 봅시다

3-1. Observable(unicast)

Observable은 나를 구독한 Observer가 몇 개든 간에, "독자적인 실행"을 가짐!!

무슨 말이냐면,

let observable = Observable<Int>.deferred {
    return Observable.just(Int.random(in: 0..<100))
}
 

이렇게 defer를 통해 Observable을 생성 했음!!

defer는 Observable이 구독될 당시에 항목을 생성하잖음??

그리고 이제 이 Observable을 여러 Observer에서 구독하면 어떻게 되냐면,

observable.subscribe(onNext: {
    print("첫번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)
 
observable.subscribe(onNext: {
    print("두번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)

어떻게 되냐면!!!!

이렇게 두 Observer가 받는 값이 서로 다름!!!

이게 의미하는 것이 바로 앞에 말했던,

Observable이 자신을 구독하는 Observer"들"에 대해 "독자적인 실행" 을 갖는다는 것임

이 Observable에 대한 Observer가 몇 개건 간에,

해당 Observer가 구독을 시작했을 경우,

그 구독에 대한 Observable이 각각 실행되어 Observer들이 서로 다른 값을 갖게 되는 것임!

그렇기 때문에 Cold Observable은 unicast라는 것임!!!

어렵지 않죠 :)

3-2. Subject(multicast)

Subject가 multicast라는 말은,

Subject는 "하나의 Observable의 실행"이 여러 Subscribe에게 "공유"된다는 말임!

예제로 바로 보자면,

subject.subscribe(onNext: {
    print("첫번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)
 
subject.subscribe(onNext: {
    print("두번째 Observer가 받는 항목 : \($0)")
}).disposed(by: disposeBag)
 
subject.onNext(Int.random(in: 0..<100))

이렇게 subject에 항목이 발행될 경우,

이렇게 해당 Subject를 구독한 Observer들은 모두 "동일한" 결과를 받게 됨!

때문에 Subject는 multicast라는 것임!!!

음.. 실제 코딩을 할때.. 예를 들면 A라는 부모 뷰에서 B, C, D 자식뷰에게

부모의 어떤 상태 값이 변경되었단 걸 뿌려줘야 할 경우, Subject를 사용하면 되겠져!? (RIBs의 방식!)

자, 위에서 이해한거까지 보면 ..

응.. 그래그래.. Subject? Hot Observable이고 .. multicast 방식인거..? 알겠어..

근데 이건 그냥 Observable의 입장에서 아냐? 얘가 왜 Observer의 역할도 한다는 거야?

싶지 않음..?

그래서 이 포스팅이 Subject의 Observable 역할인 것임돠

이제 다음 포스팅에서 Subject의 Observer 역할에 대해서 공부해보도록 하게씀니다

ObserverType이란 놈을 좀 까봐야 해서 너무 길어질까봐 3편으로 나눠버렸움

아마 3일 이내론 올라오지 않을까?

아니.. 이거 2시부터 썼는데.. 왜 벌써 8시 ..?

아니지.. 어제도 이거 2시간 넘게 쓰다 이어서 쓴 건데 ...

RxSwift.. 후.. 쉽지 않다ㅜㅜ

그럼 전 오공완을 완수 했으니.. 이만 운동하러 ..

만약 잘못된 내용, 오타, 피드백 있으면 언제든 댓글 주셔요!!!

참고 글 :

https://sujinnaljin.medium.com/rxswift-subject-99b401e5d2e5

[RxSwift] Subject

Observable이랑 Subject 나만 헷갈려..?

sujinnaljin.medium.com

날진은 신이야~ (1호팬 가슴이 벅차오른다)

Swift) switch 대신 if case, guard case 사용해보기

소들이 — Mon, 4 Sep 2023 20:25:02 +0900

안녕하세요! 소들입니다! 아닌가 망아지들인가?

연사 끝나고 근 한달간 제대로 고장이 나버렸었네요.. 저의 모든 걸 포기 했었어요.

그래도 지금 글을 쓴단 것은!!?? 다시 예전의 나를 찾아가고 있는 중이랍니다 XD

하핳 안 궁금하셨다구요!? 어쩌라고

오랜만에 글을 쓰는 만큼, 가벼운 문법 주제로 담아보려고 합니다

개발을 하다보면 은근 많이 사용하게 되지만 .. 간혹 까먹어서 ..

읭? 어떻게 쓰더라? 했던.. ㅎ.. switch문을 guard / if 구문을 통해 쓰는 방법을 보겠슴니다

간단한 글 매우 짧을 예정

모든 포스팅은 편의 말투로 합니다~!!

1. 기존에 Switch 구문을 쓸 때는 마리야

자 다음과 같이 성을 나타내는 연관값이 없는 Enum이 하나 있다고 생각 해봅시다 :)

enum Gender {
    case male
    case female
}

자, 이제 화장실에 대한 메서드 를 하나 만드려고 해요

근데 여자 화장실엔 남자가 들어오면 안 되잖음??

그럼 아마 기존엔 switch 구문을 써서 이렇게 구현했어야 할 거임

func useWomenRestroom(gender: Gender) {
    switch gender {
    case .male:
        print("어머 나가세요")
        return
    default: break
    }
}

그쳐???

아 근디 .. 진지하게 어떤 예제로 설명할까 고민.. 했는데

이전 포스팅처럼 롤을 예제로 써버리면 롤 안하시는 여성 개발자분들이 생소할까봐 참았고..

왜 제 머리속에서 나온 예제는 이런 저세상인 건지..ㅎ 당최 모르겠으나 그냥 봅시다

원래 같으면 위처럼 switch 구문을 쓰는 게 정배잖음

근데 나는 gender라는 파라미터 값이 male이란 값일 때만 어떤 처리를 하고 싶은데

switch 구문을 쓰기엔 default 값에 대한 처리도 해줘야하구.. 길구.. 귀찮고..

뭐 그렇지 않음??

따라서 이때,

if case / guard case란 것을 사용하면 코드를 아주 간결하게 줄일 수 있음!!

2. if case / guard case를 사용해보자!

func useWomenRestroom(gender: Gender) {
   if case .male = gender {
        print("어머 나가세요")
        return
   }
}

func useWomenRestroom(gender: Gender) {
    guard case .female = gender else {
        print("어머 나가세요")
        return
   }
}

요렇게!!

if case, guard case를 활용해서 원하는 case로만 비교를 할 수 있음!

(물론 추가로 원하는 조건문을 추가할 수도 있구)

여기서 사용법이.. 조금 헷갈릴 수 있는데,

if case / guard case .비교하고싶은case = 해당열거형타입의값

이렇게 보면 됨!!!

if let과 guard let은 서로 조건이 반대여서 헷갈릴 수 있으니 조심하셈

쨌든 이러면 쓸데없는 코드를 줄일 수 있고 가독성도 훨 좋져!?!? XD

3. if case let / guard case let를 사용해보자!

2번이랑 뭐가 달라졌냐구요!?! case 뒤에 let이란게 붙었움!!!

왜 붙었냐구요!?!?!? 연관값이 있는 열거형을 처리하기 위해서임!!

enum Gender {
    case male(age: Int)
    case female
}

에잏ㅎ 남자 애기는 4살까지 여자 화장실 와도 봐주자ㅎㅎ 엄마랑 온거겠찌ㅎㅎ

라는 조건을 추가하기 위해

위처럼 male일 경우, age라는 연관값을 받는 열거형을 만들었음

그럼 이제 연관값을 바인딩해서 사용해야 하잖음?

func useWomenRestroom(gender: Gender) {
   if case let .male(age) = gender, age > 4 {
        print("어머 다 컸어요 나가세요")
        return
   }
}

그럴 경우, 위처럼 if case let을 써주고

그뒤에 비교하려는 case 값뒤에 괄호()를 통해서 연관값을 받을 상수의 이름을 써주면

연관값을 해당 상수로 사용할 수 있게 되는 것임!!

모양이 생소할 수 있찌만 이렇게 쓸 수 있음!

guard case let의 경우, 위 예제로 설명하기가 적절하지 않아

다른 예제로 설명을 하자면,

func useMenRestroom(gender: Gender) {
  guard case let .male(age) = gender else{
        print("어머 나가세요")
        return
  }
  print(age)     // 연관값 사용 가능
}

이번엔 남자화장실입니다만..?

쨌든 이렇게 guard case let 구문도 if case let과 똑같이 연관값을 바인딩하여

연관값을 사용할 수 있음!!!

오랜만에 글을 써서 그런가...? 예시가 왜저러지..?

쨌든 생각보다 많이 사용하고 쓰면 코드도 깔끔해져서 좋지만

잘 몰느느 사람들도 많ㅇ은 문법 포스팅 끝!

내일부턴 문법 말고 개념 포스팅 공부하면서 쓸구야

KWDC 2023 Speaker 후기

소들이 — Sun, 23 Jul 2023 22:22:17 +0900

안녕하세요! 소들이입니다.

오랜만에 글을 쓰는데.. 그게.. 개발글이 아니라서 그건 참 스미마셍합니다

아시는 분들은 아시겠지만..(?) 제가 이번에 KWDC 2023이란 컨퍼런스에서 날진님과 함께 연사를 맡게 되었는데요

그 과정이 어땠는지를 한번 기록해보려고 합니다!

사실 날진님과의 추억 기록입니다^^

첫 연사 제안

때는 5월 15일.. 아마 이때 개발자로서의 회의감에 짙게 빠져 있을 때였습니다

ChatGPT를 보고 충격 받기도 했고.. 블로그를 계속 운영하는 게 맞나..? 하는 생각에 글도 한 글자도 안 써지던 때였져

그때 갑작스레 한통의 메일을 받게 됩니다

KWDC라는 국내 최대 규모의 Apple 컨퍼런스를 주최하려 하는데, 저에게 연사를 제안하는 메일이었어여

처음 메일을 받고 들은 생각은

연사..? 1천여명 이상 규모에서 ..? 제가여..?

전 그냥 방구석에서 공부하고 글만 쓰는 바보인데요 ..

뇌정지가 온 저는 고민할 시간을 달라고 부탁 드렸고,

덕분에 1주일 간 거의 인생 최대의 고민을 하게 되었습니다

하루에도 10번씩은

그냥 해봐? 죽기야 하겠어..? 하다가도

아무리 생각해도 개오반디? 발표 시작전에 거품 물고 쓰러지는 거 아냐..? ‍ ️

하며 생각이 바뀌었었는데요

결론은 네.. 뭐.. 하게 되었습니다..

일단 2인 1조 발표도 가능하다고 하셔서 혼자가 아니면 될 것 같았고,

발표시간도 20, 30, 45분으로 나눠져 있어서 20분이면 해볼만 한디? 했고,

2달이란 준비 시간이 있으니 완벽한 발표를 할 수 있을 것 같다는 근거없는 자신감이 생겼거든여^^

그렇게 저의 첫 컨퍼런스이자, 첫 연사의 서막이 올라가게 됩니다

날진님과의 접선

2인 1조로 함께할 연사를 찾기 위해 모색하던 도중,

제 팀원의 지인이 날진님인 것을 이용해서 날진님께 제가 먼저 대시를 했습니다..ㅎㅎ..

그전에 사실 날진님과는 블로그로 약 1년 간 내적 친분 오지게 쌓아놨는데여

접선이 COEX였을 줄은 며느리도 몰랐을 거야?

23년에 꼭 접선 한번 하자고 했던 것을 악용해

날진님께 공동 발표 제안을 드렸습니다

날진님께서도 사실 연사 제안이 왔었는데 (워낙 유명하신 분이니..!!!)

당시엔 거절(?) 하셨지만, 제가 제안 드리니 다시 한번 고민해보겠다고 하셨어요.. 감동 ..

그래서 저희는 2인 1조로 연사 준비를 하게 됩니다!!!

날진님은 Let's Swift 발표 경험도 있으신 경력자이신데,

나같은 쪼랩 발표 신입과 선뜻 같이 해주신다고 해서 진짜 세상을 얻은 듯 행복했었습니다

나나~ 두려울 게 없는 사람이야~~~ 경력자랑 함께 할건데~~ 뭐 어쩔건데~~

주제가 매크로가 되기까지

날진님과 이제 같이 연사를 나가기로 했으니, 주제를 정해야 하는 시간이 왔습니다

당시 "WWDC 2023"과 연관된 주제여야 한다는 조건이 저를 참 힘들게 했는데요^^..;;

사실 처음 같이 연사를 하기로 할 때 매크로 갈까요? 하긴 했지만, 그땐 진짜 간단한 찍먹이었고요ㅎ

이제 진짜 주제를 확정하기 위해 각자 매크로에 대해 제대로 공부해오기로 했습니다

근데 세션을 듣는 동안 "뭔데 이거? 나만 못 알아듣는 거임? 몰카임?" 싶을 정도로 내용이 쉽지만은 않더라구여

응 그래도 매크로야

글쟁이 2명ㅇ ㅣ모였는데 쉬운 주제만 하면 재미가 없잖아여!

새벽마다 머리 싸매고 있을 저희가 눈에 선하긴 했지만,

어찌저찌 저흰 매크로를 발표 주제로 정하기로 합니다

이제 주제도 정해졌으니, 각자 매크로 세션을 읽고 정리해오기로 하는데요,

날진님의 정성어린 노션 정리 글과

어그로킹 소들의 비공개글 Macro 정리가 이때 탄생하게 됩니다

참고로 저 비밀글 비밀번호 "macro" 였는데 뚫은 사람이 한 명도 없는 거 같은 게 아쉽네여^^;;

근데 매크로를 정리하며 저흰 뭔가 단단히 잘못 되어감을 느낍니다

20분 발표였잖아요 분명

사실 발표라고 해도 2명이서 20분이면 개꿀이네요 하고 있었는데,

매크로 이놈 20분? 진짜 어림도 없었습니다

아니 근데 다음 날 출근인데 새벽 5시까지 매크로 syntax 정리하는 나도 어이없는데

저때 정리하고 링크 보내면 바로 칼답오는 날진님은 뭘까..? 이정도는 돼야 파워블로그 하나 봅니다..

쨌든 매크로를 정리하면서 내용이 많고 어렵다는 것을 느낀 저희는

소들 : 20분 발표면 매크로 디자인 철학쯤 설명하다가 끊길 거 같은데요?

날진 : 뒷내용 궁금하면 저희 블로그 와서 보라고 합시다^^ 아님 KWDC 24에서 이어 해요^^

라는 드립을 치면서 놀다가..

슬금슬금 사태의 심각성을 느끼고 발표시간을 45분으로 늘리게 됩니다

이때부터 뭔가 잘못됨을 감지하긴 했지만 이미 무르기엔 너무 많은 길을 걸어버렸습니다

20분 발표라서 10분하고 내려갈라 했단 말이여!!!!!

가위바위보 져서 뒷부분을 맡게 된 날진입니다

매크로에 대한 정리가 어느정도 되고 나니, 이제 발표 순서를 정해야 했는데요

앞부분이 아무래도 매크로의 정의나 디자인 철학 쪽이라 상대적으로 내용이 쉬웠고,

뒷부분이 실제 코드 작성 부분이라 내용이 조금 빡셌습니다

우연히? 당연히? ^^.. 두 명 다 앞부분 발표를 하고 싶어 하는 것을 알고,

가위바위보로 정정 당당하게 승부를 정하기로 했습니다

이때 진짜 심장이 터지는 줄 알았습니다

살면서 내가 어? 면접 볼때도 이렇게 안 떨었을거야 ..

저는 원래 똥손으로 유명한데요 .. 날진님이 저보다 더한 똥손을 갖고 계시더라구요 ✊

근데 제가 또 양심은 있거든요 ..?

예 양심이 있었는데 없었습니다

날진님께선 이미 가위바위보 하기 전부터 질 거 같단 마음의 준비를 하고 계셨더라구여??

그래서 이미 마음의 준비를 하신 김에 뒷부분 편하게 드렸습니다

근데 사실 날진님이 그쪽 부분을 진짜 기가막히게 정리 잘해두셔갖구..

제가 맡는 거보다 날진님이 맡는 게 훨씬 발표에 좋아보이긴 했어요

(뒤늦은 변명이라고 합시다)

삐빅- 오후 발표입니다

아직 타임테이블이 나오지 않았을 때

날진님과 발표시간에 대해 애기하던 중

당일에 너무너무 긴장이 될 거 같아서 .. 좀 더 컨퍼런스를 즐기고 싶으니

오전에 발표를 하고 후딱 끝내는 게 좋지 않을까요!! 하는 말들을 했었는데요

네 귀신같이 점심시간 이후였습니다

근데 지금와서 생각해보면, 오후가 더 나았던 것 같아요!

해야할 게 있어서 조금 여유롭게 행사장에 도착하기도 했고,

여기저기 인사드리고 명함 받고 하느라 정신이 없었거든요

다만 밥 먹은 후에 들어야 하는 45분 발표라..

듣다가 조는 분들이 많을까봐 걱정이가 많이 되었습니다

근데 다행히 행사 당일에 조는 분은 (제 눈엔) 별로 안 보였습니다^^

지옥에서 돌아온 피피티

저는 사실 피피티를 만든 경험이 많지는 않았습니다

뭐 회사에서 기술 소개나 리팩토링 공유 같은 거 할 때 대충..? 만들긴 했지만,

이렇게 많은 사람들 앞에서 연사할 때의 피피티는 만들어 본 적이 없는데요

날진님이 먼저 피피티 초안을 보내주셨는데

혼자 맡은 부분만 총 150장인가를 주셔서 뭐지? 꿈인가? 했습니다

저는 영혼까지 끌어서 피피티 70장인가를 만들어 보내드렸는데(총 220장..?)

피피티 개고수 날진님께서는 이를 하나하나 피드백해주기 시작하셨습니다

✂️ : 내용 삭제

: 장표 추가

♻️ : 대본 대체

➕ : 대본 추가

뭐 대충 이런 내용으로 매번 피드백을 주셨는데요..!!

피드백 주실 때도 최대한 저의 입장을 고려해주시면서 예쁘게 피드백을 주셔서 ..

그래서 매번 정말 기쁜 마음으로 수정을 했습니다

소들의 속마음?

그리하여 매일매일 하루에 5-10번 이상의 피피티 수정본이 오갔고

(정말 한 달 동안은 매일매일을 수정했던 거 같네요)

완성 됐다 싶으면 오타 튀어나오고

완성 됐다 싶으면 하이라이팅 잘못된 부분 나오고.. 후..

우리의 금쪽이 피피티는 이렇게 우리의 피땀눈물로 완성되어 결국

진짜 광기의 PDF파일 기준 600장을 만들어냅니다

그거 아시나요 사실 발표 당일 전날까지도 게속 수정이 들어가서 최종적으론 600장이 넘었다는 사실을요..?

그거 아시나요 발표 당시 저희는 4초에 한번씩 엔터를 누르고 있었다는 사실을요..?

하지만 정말 힘든 피피티의 시간을 보냈지만 사실 우리의 팀플 과제는 그야말로 희망 그 자체였습니다

매번 이런식으로 서로 피드백한 내용을 정리해서 주고 확인하고 하는 시간을 가졌는데,

그시간이 정말 새벽 3-4시가 넘어가는 시간이었을지라도 서로 불평 한마디 없이

화이팅을 외치며 해나가는 모습이 정말 희망적이었습니다

이렇게 피피티가 차차 다 완성되어가니 솔직히 "우리 발표 퀄리티 미쳤는데?" 라는 생각이 들때쯤

리허설이 시작 되었습니다

온라인 리허설(드라이 / 지인 / 자체)

드라이 리허설은 7월 8일 KWDC 운영위원회분들과 온라인으로 진행 했고,

지인 리허설은 7월 9일 날진님의 지인 두분을 초대해 온라인으로 진행 했습니다

사실 45분이란 발표시간이 적지 않은 시간이라 리허설 듣는 것도 힘드실텐데 ..

모두들 정말 경청해서 들어주시고 발표 내용도 너무 좋다 해주시고,

피드백도 너무 알맞게 주셔서 정말 정말 감사한 시간이었습니다

사실 자체 리허설까지 합하면 제 생각에 리허설은 한 10번정도 한 거 같은데요

여러분. 45분짜리 리허설을 10번정도 하면요.

100장이 넘는 피피티의 장표만 봐도 외우지 않은 대본이 자동으로 튀어나온답니다 ?? 신기하죠 ??

어떻게 알았냐구요?? 저도 알고 싶지 않았습니다??

근데 지인 리허설 당시 날진님께서 그 자동완성..? STT?로 피드백 내용을 정리해서 주셨는데요

뼈가되고 살이된 피드백 이 자리 빌려 다시 진심으로 감사합니다..!!

여러분.. 사실 소들이 발음이 많이 어려운 거였을까요 ..?

아니면 AI가 소들이를 인식하지 못하는 걸까요..?

소두리는 이해하지만.. 호두희라뇨 .. 소주라뇨.. 소대라뇨.. 예..?

그래도 리허설을 많이 해서 그런지,

시간이 지날 수록 말도 많이 가다듬어지고 발표 때 숨쉬어야하는 타이밍이나

딕션을 정확하게 하는 방법 등에 대해 정말 많이 배우게 되어서 정말정말 좋았습니다

날진님과의 첫 대면 리허설

7월 15일 저희는 강남 스터디룸에서 처음으로!! 만나기로 했습니다

그전까지 약간 인터넷상에서만 보는 친구였는데.. 실제로 만난다니 심장이 두근두근 했습니다

그래도 그전까지 저희는 소개팅마냥 매일 하나씩 서로를 알아가는 시간을 가졌답니다?

후후..^^.. 저희 이런 사이입니다만 ^^..

그리고 실제로 만났을 때 제가 먼저 스터디룸에 도착하게 되어,

날진님을 반기기 위해 칠판에 낙서를 해놨습니다

쨔란-!

그렇게 시작된 3시간의 시간 동안 저희는 저녁도 못 먹구

정말 말 그대로 리허설과 폭풍 피드백만 하기 시작합니다

각자 45분 리허설을 끝낸 뒤 장표 한장 한장을 넘기며 주술 호응이 어색한 부분은 없는지,

청중의 입장에서 어느 부분이 이해가 안 갈지를 고려하면서 하다보니

3시간을 꽉 채우고, 1시간을 연장 했음에도 불구하고 날진님 피드백은 1/3도 못한 상황이 발생 (???)

그래서 그 다음날 온라인에서 날진님 부분쪽 피드백을 대략 1시간 정도 진행하고 나니,

이제 KWDC 피피티가 어느 정도 끝났다! 싶어졌습니다

현장 리허설도 코앞으로 다가오고, KWDC 행사는 2일 밖에 남지 않은 상황이었죠

이때 되게 후련하기도 하고 많이 설레기도 했던 것 같습니다

현장 리허설

7월 17일 4시에 실제 COEX에서 현장 리허설이 있었습니다

회사에 출근했다가 버그 하나 쳐내고 바로 퇴근을 하여 COEX로 뛰었습니다

이날 제가 바보 같이 우산을 안 들고 가서 비 쫄딱 맞으면서 우산 사러 다녔는데ㅋ_ㅋ

쨌든 우여곡절 끝에 COEX에 도착하고, 리허설을 진행했는데요

아무래도 현장에 처음 간 것이다보니 실제 행사장 크기에 압도되기도 했고, 긴장도 많이 됐는데

막상 리허설이 시작되고 나니 마음이 많이 평온해져서 성황리에 리허설을 마쳤습니다

발표 공포증인 사람이 왜 평온해졌을까에 대한 답은 -> 1달 동안 너무 갈려서 두려울 게 없는 상태^^ 라고 해두겠습니다

날진님과는 다음날 하루만 더 고생하자!를 외치며 집으로 돌아갔습니다

날진님은 COEX가까이 살아서 금방 가셨다는데, 저는 COEX에서 수원가다가 지옥을 봤습니다

COEX 주변 회사는 못다니겠다^^;;..ㅋㅋ;넝담입니다

KWDC 당일

드디어 당일이 되었습니다

사실 전날 밤에 너무 긴장되기도 하고..

COEX에서 리허설까지 하니 그동안 실감이 안 나던 게 한번에 확 실감이 되어서 그런가,

자려고 누웠는데 도통 잠이 안왔습니다.. 그래서 그냥 롤 켰습니다 (^^o)(o^^)

친한 회사 사람들과 게임을 한두판 했는데, 나나 무서워-!! 어떠케!!! 하면서 징징대는 저에게

다들 준비 많이 했으니 마음 편하게 먹으라구 쫄지 말라고 응원해주던 덕에 마음이 많이 진정이 됐어요

그래서 꿀잠을 자고 일어났습니다

Discord에서 Yong님께 공유받은 COEX 당일 현장 사진입니다

저는 일이 있어서 살짝 늦게 도착했는데,

미리 도착한 팀원들과 KWDC 관계자분들에 의하면 사람이 정말정말 많이 왔다고 했습니다

(들린 바에 의하면 1300명 이상..?이라 했는데 정확힌 모르겠습니다)

도착하자마자 저는 연사 굿즈를 받고, 신부 대기실이란 SPEAKER 대기실로 들어갔는데요

굿즈 만세!!!!!!!!!!! 굿즈까고 혼자 베실베실 웃고 있었는데 여기저기서 명함을 주셨습니다 ..

ㅎ ㅏ... 제가진짜 명함 드릴라고 새로 귀엽게 파놨는데

KWDC가 화요일인데 제 명함이 수요일에 도착한다하여..^^.. (장난?)

제 명함을 드리지 못해 너무 아쉬웠습니다..

그래도 이날 제가 좋아하는 개발자분들도 만날 수 있어서 너무너무 행복했었습니다

그리고 대망의 2시 15분

저는 2시부터 사실 숨을 못쉬고 있었는데요

아ㅋㅋ 우리세션 ㅋㅋ사람들 너무 몰리면 어떡하지? 하는 장난을 치며 긴장을 덜고 있었는데,

실제로 이미 시작 전에 줄이 저끝까지 서있고, 자리는 다 차서 다들 서서 계시고

나중엔 아예 입석도 없다고 제한되었다는 말을 듣고!!!

와.. 발표 준비를 1달 동안 진짜 개고생하면서 한 게 허투루 돌아가진 않겠구나! 싶었습니다

이제 나만 준비한 내용을 잘 발표하고 내려오면 되겠다 생각했고, 이때부턴 긴장도 떨림도 아예 없어졌습니다

저 노란머리입니다만?

제가 25분, 날진님이 20분의 시간 동안 발표를 했는데,

지금까지 했던 그 어떤 리허설보다도 가장 자신 있는 발표를 하고 내려온 느낌이 들었습니다

발표가 끝나고 내려오니 만감이 교차 했는데요

나의 길고 긴 1달 동안의 발표준비가 이렇게 끝나는구나!! 싶어 시원하기도 했고,

정말 열심히 많이 노력했던 만큼 다 보여주고 내려온 것 같아 뿌듯하기도 했습니다

그 중에서도 우리의 이런 노력들이 실제 청중들에게 좋은 연사로 남았길 바라는 마음이 제일 컸던 것 같습니다

이렇게 저의 첫 컨퍼런스이자,

방구석에서 개발 글만 쓰던 글쟁이가 처음 세상으로 나간 날!!

처음으로 많은 사람들 앞에서 발표를 한 날은 이렇게 막을 내리게 됩니다

정말 길고 긴 시간이었고 힘든 시간이었는데,

저희의 연사를 들어주신 분들, 귀한 걸음 해주셔서 감사하고,

매크로에 대해 어느 정도 부술 수 있는 시간이 되었길 바라겠습니다

(그래도 후일담으로 여기저기서 매크로 세션 너무 좋았다라는 얘기가 많이 들려서 행복했습니다^..^)

이렇게 큰 행사에 연사로 설 수 있는 기회를 주셔서 감사하고,

KWDC 준비 위원회분들이 행사가 진행되는 날까지 정말 고생을 너무 많이 하셨는데.. (혹은 그 이후에도..)

언제나 연사가 편하게 연사할 수 있도록 배려해주시는 모습에 감동을 많이 받았었습니다

모두모두 너무너무 고생 많으셨습니다

+ 제 최고의 파트너 최애 파트너 날진님과는 이미 장문의 편지를 주고 받았답니다^^

나 날진님 1호팬이야!!!!! 다비켜!!!!! 날진님이랑 하트하는 사이야!!!!!!!!1

비하인드 스토리

세상이 억까해도 우린 발표 준비를 해야 해

사실 .. 발표를 준비하며 진짜 말도 안되는 일이 있었습니다

내가 회사 다니며 2023년 반 년 동안 이렇게 바쁘지 않았는데..

KWDC 준비 기간이 되자 갑자기 일이 미친 듯이 바빠진 것입니다?

버그가 하루에 10개씩 올라오는 거 보고 세상이 날 몰카하나? 싶었는데

더 웃긴 건 날진님도 같이 현생에 치이고 있었답니다

진짜 엥?싶을 정도로 현업이 바빠졌는데

새벽 3,4시에 퇴근하고 집에 가서 지친 몸을 이끌고 피피티를 수정하면 이게 인생인가..? 뭐지? 싶었습니다..

힘든 일은 원래 몰아온다지만 이건 아닌데? 이건 아니라구!!! 싶었지만

그래도 우린 이겨내버렸습니다 에라잇 세상아 덤비든가!!! 더해!! 더해보라구!!!

부상 투혼을 기억해주세요

저렇게 매일 밤을 새듯이 발표 준비를 하고, 일을 하고 하다보니 사람이 멀쩡할 리가 없습니다

하루는 3시간 정도 자고 일어나서 출근을 하려고 보니, 왼쪽 눈에 흰자가 없네요..?

눈에 핏줄이 다 터져서 좀비 그 자체가 되었습니다

그래서 와.. 이건 출근했다간 사람 가겠는걸? 싶어서 살기 위해 연차를 냈는데요

그렇게 연차를 내고 저는 매크로 내용을 정리 했습니다 (실화인가요?)

근데 저 뿐만 아니라... 날진님은 중간에 응급실도 갔다 오시고...ㅠㅠㅠㅠㅠㅠㅠ

여러분 ..저희의 발표에는 뒤에 다 갈려서 뼈만 남은 연사 둘이 있었다는 것을 기억 해주세요 ..

날진님한테서 훔쳐온 정신나간 우리의 스케쥴이었습니다

따봉 팀원들아 고마워!

이렇게 갈리는 와중에도.. 우리 팀원들은 체고야!

매일 새롭게 올라오는 버그에 발표준비까지 빡세게 하려니..

진짜 멘탈이 터지다 못해 거의 번아웃 직전 상태까지 온 적이 있었는데,

버그 하나 더 넘기려는 속셈 아닙니다 아닐껄

자기 버그인마냥 이슈 가져가서 쳐내주는 팀원들이 있어서 버틸 수 있었습니다

그리고 행사 당일에도 다같이 와줘서 사진도 찍어주고, 발표 끝났을 땐 꽃다발까지 전해줘서

정말정말 감동이었답니다^^.. AfreecaTV iOS팀 최고 ❤️

마지막은 팀에서 귀여운 막내의 내 연사 시간 fixed 해놓은 사진

다른 팀원들이 동시간대 연사 현대차 SwiftUI 탐난다니 뭐니 장난치니

내꺼 들으라고 저렇게 박아놓은거 짱귀ㅠ

이제 후기도 막을 내려야겠군요..!

고생했던 만큼 7월은 좀 망나니처럼 놀고 8월부터 다시 글 올려보겠습니다!

그리구..

KWDC23은 제 인생에 있어 가장 진귀한 경험 중 하나가 되었습니다

여러분께도 제 연사가 좋은 경험이 되었길 바라며

다음 컨퍼런스에서는 청중으로 찾아뵐게요! 안녕! (발표 쿨타임은 꽤 길듯 하다)

저와 함께한 날진님의 연사 후기를 보고싶다면 다음 링크로 가주세요!

https://sujinnaljin.medium.com/conference-kwdc23-%ED%9B%84%EA%B8%B0-4c9cb0c7f894

RxSwift) Observable 생성하기 2편(empty, never, range, interval, timer, defer)

소들이 — Wed, 10 May 2023 18:33:26 +0900

안녕하세요! 소들입니다

저번 포스팅에서 Observable을 생성하는 간단한 Operator를 몇 개 알아봤잖아요?

(just, of, from, create)

이번에도 마찬가지입니다! 어렵지 않으니 이번 내용은 얼른 하고 넘어가죠

모든 포스팅은 편의 말투로 합니다~!!

1. Observable을 생성하는 또다른 방법

공부하기 전에

기억해야 하는 사실 하나만 짚고 넘어가자면,

onCompleted이나 onError가 호출되고 난 후에 그 Observable은

dispose 되어버리기 때문에 더이상 어떠한 이벤트도 방출할 수 없습니다

1-1. empty

어떠한 항목(Item)도 방출(emit)하지 않고,

즉시 onCompleted()을 호출하여 정상적으로 종료되는 Observable을 생성합니다

말 그대로 비었거등요 ...

그래서 어떠한 이벤트 항목을 방출시키지 않음!!!

다만 Empty Operator를 통해 Observable을 생성할 경우,

onCompleted() 메서드를 호출 후 스트림이 "정상 종료" 됨!!

따라서, 어떠한 항목 방출 없이 바로 정상적으로 스트림을 종료하고 싶을 때 사용됨!

let observable = Observable<Void>.empty()
 
 
observable.subscribe(onNext: { (data) in
    print(data)
},
onCompleted: {
    print("onComplete")
},
onDisposed: {
    print("onDispose")
})
.disposed(by: disposeBag)

실제 코드로 테스르를 해보면,

어떤 항목도 방출되지 않기 때문에, onNext의 이벤트는 불리지 않고,

바로 onComplete가 불리며 스트림이 정상 종료됨

1-2. never

어떠한 항목(Item)도 방출(emit)하지 않고,

스트림이 종료되지도 않는 Observable을 생성합니다

어떠한 이벤트 항목을 방출시키지 않는다는 점에서 empty와 동일하나,

empty는 즉시 onCompleted()을 호출시켜 스트림을 정상 종료하는 반면,

never는 onCompleted()도 호출시키지 않아, 스트림이 종료 되지도 않음!

따라서 직접 dispose를 실행시켜 주거나

disposeBag을 이용해 dispose되기 전까진 절대 스트림이 종료되지 않음!!

무한정 지속성을 나타낼 때 사용된다고 함

이또한 코드를 통해 확인해보면,

let observable = Observable<Void>.never()
 
 
observable.subscribe(onNext: { (data) in
    print(data)
},
onCompleted: {
    print("onComplete")
},
onDisposed: {
    print("onDispose")
})
.disposed(by: disposeBag)

위 코드를 실행시켜 보면,

아무런 결과값이 찍히지 않음

앞서 말했듯,

이벤트를 방출하지도, completed을 통해 정상종료를 하지도 않기 때문임

그럼 얘 죽었냐 ...? 싶지만..

아니..! 종료되지 않는다 했잖음!! 계속 살아있음!!!

그럼 ㅁㅔ모리 해제 언제 됨 ..?

앞서 말했듯 해당 Observable이 dispose될 땐

(위 코드에선 disposeBag이 메모리에서 해제될 때)

그땐 onDisposed 메서드가 실행되며 스트림이 종료됨

쨔란

1-3. range

range는 특정 범위의 "정수"를 순서대로 발행하는 Observable을 생성합니다

중요한 것은, 해당 범위 안의 "정수"를 모두 발행한 경우,

onCompleted()이 불리며 스트림이 종료됨!!!

움.. 어렵지 않으니 예제로 보고 넘어갈게영

let observable = Observable.range(start: 0, count: 5)

위 코드의 경우, 0부터 5번만큼 정수를 방출하고

onComplete이 불리며 dispose 되는 것을 볼 수 있음!!

당연히 "정수"를 발행하는 Observable 생성자이기 때문에,

Observable이 방출하는 타입은 Int로 지정되어 있어서

건들면 아..앙대..

1-4. interval

interval 연산자는 주어진 시간 간격으로 순서대로 정수를 발행하는 Observable을 생성 합니다

구독을 해제하기 전까지 이벤트를 무한히 방출하기 때문에,

불필요해졌을 경우 dispose를 해주어야 합니다

위 Range와 다른 점은

Range의 경우 주어진 범위 만큼 방출하고 onCompleted()이 불렸다면,

interval은 내가 불필요해져서 dispose를 해주기 전까진

주어진 시간 간격마다 무한하게 이벤트를 방출함!!

따라서 꼭 주의할 점!

"불필요 할시 dispose를 해주어야 합니다"

(물론 위 코드에선 disposeBag에 담았기 때문에,

disposeBag이 처분될 때 같이 처분될 것임)

예제는 코드로 보쟈

let observable = Observable<Int>.interval(.seconds(1),
                                          scheduler: MainScheduler.instance)

위와 같이 지정한단 것은

1초마다 정수를 발행하는 Observable을 생성한단 것이고,

dispose를 행하기 전까진 정수가 무한하게 발행되고 있을 것임

죽이기 전까지 무한하다능

1-5. timer

구독 시점으로부터 특정 시간 동안 이벤트 방출을 지연시킨 뒤,

지연된 후 이벤트를 방출하고 나서 onCompleted()이 호출되며 정상 종료됩니다

얜 그리기 귀찮아서 공식문서꺼 훔쳐옴 ㅌㅌ

살짝 헷갈릴 수 있으나

"구독한 시점"으로부터 특정 시간을 지연시켜 이벤트를 방출한다고 생각하면 편할 것 같음

쨌든 우리가 원래 쓰던 타이머같이 지연 후에 이벤트를 방출하고,

onCompleted()을 통해 자동으로 정상 종료(dispose)가 됨

let observable = Observable<Int>.timer(.seconds(3),
                                      scheduler: MainScheduler.instance)

위처럼 선언해줄 수 있고,

이 경우, 실제 테스트 해보면

구독을 한 후 3초 뒤에 이벤트를 방출하는 것을 볼 수 있음

또 방출이 끝난 후에 onComplete()이 불리며 dispose 됨!!

여기서 조심하셔야 할 건,

사실 이 timer 메서드는 두번 째 파라미터를 갖고 있었다는 것.. !!!!!! (두둥)

let observable = Observable<Int>.timer(.seconds(1),
                                      period: .seconds(2)
                                      scheduler: MainScheduler.instance)

이렇게 period란 파라미터를 설정해줄 수 있는데 (기본값은 nil)

period라는 것은 말 그대로 다음 값이 생성되기까지의 주기를 지정하는 것임!!

위처럼 내가 period를 2초라고 줘버리면,

위 Observable은 기존처럼 1초뒤에 이벤트를 방출하고 종료되는 것이 아니라

1초 뒤에 이벤트를 방출 - 2초 쉬고 - 이벤트 방출 - 2초 쉬고 - 이벤트 방출 ... 무한 반복

..ㅎㅎ 이 경우 Interval과 같이 무한으로 방출됨

때문에 period를 사용한 경우, disposeBag을 사용하든 직접 dispose를 시켜줘야함!!!

1-6. defer

Observer가 구독할 때까지 Observable의 생성을 지연시켜줍니다.

Subscribe() 메서드를 호출 할 때 Observable을 생성합니다

여러분은 지금 그림그리다 지쳐 공식문서 그림을 훔쳐오는 소들을 보고 계십니다

이게 먼소리잉겨,, 싶잖음 ,,??

여러분 우리가 지금까지 onNext를 직접 원하는 때에 호출하던 Operator는 제외하고

just, of 등등.. 으로 만든 Observable은

내가 해당 Observable을 생성하는 코드가 실행되는 시점에 Observable이 바로 생성 됨

그리고 이제 그 Observable에 대고 "구독을 하면",

그 이미 생성 시 발생된 이벤트가 순서대로 방출되는 것임

이건 예제로 보는 게 더 쉬울 것 같음

let observableJust = Observable<String>.just(getTime() + " ➕ Just")

 

현재 시간을 찍는 메서드 getTime이 있을 때,

위처럼 getTime을 통해 얻은 시간을 방출하는 Observable을 생성했음

그리고

DispatchQueue.main.asyncAfter(deadline: .now() + 60, execute: {
    observableJust.subscribe(onNext: { (data) in
        print("현재시간 \(getTime()), Observable 생성 시간 \(data)")
    })
    .disposed(by: self.disposeBag!)
})
 

Observable이 생긴 코드가 실행된 후 바로 그 Observable을 구독하는 게 아니라,

60초가 지난 후에 해당 observable을 구독하게 했음!!

그리고 나서 현재 시간(구독 시간)과 Observable이 방출한 시간을 찍어보면

이처럼 차이가 나는 것을 볼 수 있음

무슨 말이냐면, 구독을 하는 순간 Observable을 생성하는 게 아니라,

이미 Observable은 생성 코드가 불릴 때 생성이 되고,

구독을 하는 시점에, 그때 생성된 Observable의 항목이 방출 되는 것임!!!

그렇다면 defer는 어떨까?

defer 연산자는 deferred라는 메서드를 통해 만드는데,

이 defferd의 파라미터는 escaping 클로저로,

반환 타입이 Observable<Elemen>임..!

즉, 우리가 직접 클로저로 어떤 Observable을 생성할 건지를 전해줘야 함

let observableDefer = Observable<String>.deferred {
    return Observable.just(getTime() + " ➕ defferd")
}
 

따라서 위처럼 작성할 수 있는데,

이제 다시 60초가 지난 후에 해당 observable을 구독하게 하면

DispatchQueue.main.asyncAfter(deadline: .now() + 60, execute: {
    observableDefer.subscribe(onNext: { (data) in
        print("현재시간 \(getTime()), Observable 생성 시간 \(data)")
    })
    .disposed(by: self.disposeBag!)
})
 

이번엔 말임

Observable이 생성된 시간과 현재 시간(구독 시간)이 동일한 것을 볼 수 있음!!

아하! 정리하자면 defer Operator는,

구독 전에는 Observable이 생성되지 않다가,

Observer가 구독을 시작하면, 이때 Observer 별로 새로운 Observable을 생성해서 구독하고 있구나!

정도가 되겠음

따라서 deffer 연산자의 경우,

구독 직전에 Observable을 생성하여 가장 최신 상태의 아이템을 방출할 때 사용 함

-끗-!

연산자가 쉬워서 금방 끝날 줄 알아쓴데..

포스팅ㅇ이 재미가 엄서.. 킁

오타 잘못된 내용, 피드백 대환영입니다!!!!

RxSwift) Observable 생성하기 1편(just, of, from, create)

소들이 — Tue, 18 Apr 2023 16:51:33 +0900

안녕하세요!! 소들입니다

참으로 오랜만입니다.. ???

저는 뭐 그동안 바쁘기도 했고.. 해외여행도 다녀왔고..

혹은 개발? 공부? 인생?과 심각한 슬럼프를 겪기도 했고..

(블로그 글이 단 한 글자도 써지지 않던 마법..)

에힝ㅠ ChatGPT랑 짱친 된 기념으로 다시 열심히 공부 해야죠ㅠ

이번에 공부할 내용은 Observable을 생성하는 Operator 몇 가지에 대해 배울 것입니다!

앞서 Observable이 무엇인지에 대해 공부를 했으니

크게 어려울 것은 없습니다!

모든 포스팅은 편의 말투로 합니다~!!

1. Observable을 생성하는 방법 (just, of, from, create)

Observable을 생성할 때 자주 사용하는

몇 가지 메서드에 대해서 알아볼 것임!!!

1-1. just

단 1개의 항목(item)만 방출하는 Observable Sequence를 생성합니다

코드로 이해를 해보쟈

let observable = Observable.just(1)
// or
let observable = Observable<Int>.just(1)

 

위처럼 observable을 생성할 때

Observable이란 클래스의 just라는 메서드를 사용할 수 있는데,

이때 just는 단 한 개의 항목(위에서는 Int형 타입의 1)만 파라미터로 넘겨줄 수 있음!!

(이때 제네릭 타입은 명시해줘도 되고 안 해줘도 됨)

이제 이렇게 생성된 Observable을 구독할 경우, 어떻게 되냐면,

observable.subscribe(onNext: { (data) in
    print(data)
},
onCompleted: {
    print("onComplete")
},
onDisposed: {
    print("onDispose")
})

앞으로의 구독 코드는 위 코드로 생각해주시면 되겠음!!!

쨌든 위처럼 해당 observable을 구독해서 확인해보면,

우리가 아까 파라미터로 넘겨준 "1"이라는 항목을 한번 방출하고

바로 complete 불려서 dispose 되어버리는 것을 볼 수 있음!!!

참고로, item이 방출되는 시점이 궁금하신 분은 직접 해보면 알겠지만,

해당 Observable을 구독하자마자 파라미터로 넣어둔 항목이 방출됨!!!

just는 정말 just(단지ㅎ) "한개"의 항목만 방출하고 dispose 되어버리기 때문에,

배열을 넣을 경우, 해당 배열 자체를 방출하고

let observable = Observable.just([1, 2])

만약 한 개 이상의 item을 파라미터로 넣을 시

let observable = Observable.just(1, 2) // error!

에러가 발생함! just ? 갱장히 쉽군

근데 만약 1개 이상의 item을 방출시키고 싶을 땐 어캄?

1-2. of

1개 이상의 항목(item)을 방출하는 Observable Sequence를 생성합니다

자문자답 폼 미쳤다

만약 1개 이상의 항목을 방출시키고 싶을 땐 of라는 메서드를 사용하면 됨!!!

let observable = Observable.of(1, 2, 3)
// or
let observable = Observable<Int>.of(1, 2, 3)

위처럼 observable을 생성할 때 of라는 메서드를 사용할 수 있는데,

이때 of의 파라미터는 가변 파라미터이기 때문에, 위처럼 방출을 원하는 만큼 항목을 넘겨줄 수 있음!!!

이또한 마찬가지로 제네릭 타입을 명시하든 안 하든 상관은 없지만,

당연하게도 넘겨주는 파라미터들의 타입은 동일해야 함

이또한 구독을 해볼 경우,

우리가 아까 파라미터로 넘겨준 1, 2, 3이라는 항목을 순서대로 방출하고

바로 complete 불려서 dispose 되어버리는 것을 볼 수 있음!!!

이또한 해당 Observable을 구독하자마자 파라미터로 넣어둔 항목이 방출됨!!!

파라미터 하나를 하나의 항목(item)으로 보기 때문에,

just와 마찬가지로 배열을 넣을 경우, 해당 배열 자체를 하나의 항목으로 방출함

왜 자꾸 배열을 넣을 경우 해당 배열 자체가 항목으로 방출되는 걸 알려주냐면,

배열을 넣었을 때 Element 를 하나씩 방출하는 메서드가 있기 때문이쥐

1-3. from

파라미터로 오직 하나의 배열만 받으며,

배열의 요소들을 순서대로 방출하는 Observable Sequence를 생성합니다

그림과 글만 봐도 이제 어느정도 예상이 갈 것 같은데

from 메서드를 사용할 경우,

let observable = Observable.from([1, 2, 3])
// or
let observable = Observable<Int>.from([1, 2, 3])

위처럼 파라미터로 하나의 배열을 전달할 수 있음!!

그리고 이 Observable을 구독하면,

파라미터로 보낸 배열의 Element들이 순서대로 하나씩 방출되는 것을 볼 수 있음!!!ㅎㅎ

파라미터로 넘겨준 [1, 2, 3]이라는 배열을 순서대로 순회하여 1, 2, 3을 하나씩 방출하고

바로 complete 불려서 dispose 되어버리는 것을 볼 수 있음!!!

지금껏 공부한 것들은 모두 해당 Observable을 구독하면

파라미터로 전달한 항목이 순서대로 방출되고,

방출이 끝나면 complete가 불리면서 dispose되는 것을 봤음!!!

자, 그럼 여기서 한 가지 의문

아니 비동기 이벤트를 Observable로 만든다면서용,,

나는 어떤 API통신을 해서 결과값을 받은 다음에..

그 결과에 따라 onNext나 onCompleted, onError를 내 맘대로 방출하고 싶으면 어쩌죠,,,?

하는 분들을 위한 create

1-4. create

파라미터로 Observer를 매개변수로 받는 클로저를 전달받는 Observable Sequence를 생성합니다

매개변수로 받은 Observer의 onNext, onCompleted, onError 메서드를 직접 호출할 수 있습니다

클로저가 끝나기 전에 반드시 onCompleted이나 onError를 정확히 1번 호출해야 하며,

그 이후로는 Observer의 다른 어떤 메서드도 호출해선 안됩니다

살짝 설명이 어렵다고 느낄 수 있는데 정말 별 거 없음

먼저 create 메서드의 원형을 보면

위처럼 "Observer를 파라미터로 받고, Disposable을 반환하는 클로저"를

파라미터로 받는 것을 볼 수 있음!!!!

실제로 어떻게 사용하냐면,

let observable = Observable<String>.create { observer in
    observer.onNext("첫 번째 방출")
    observer.onNext("두 번째 방출")
    observer.onCompleted()
    observer.onNext("세 번째 방출")
    return Disposables.create()
}

이렇게!!!

create 메서드 다음에 트레일링 클로저를 이용해서

파라미터로 받은 observer에게 언제 onNext를 통해 이벤트를 방출 할 것인지,

언제 onCompleted를 할지, 언제 onError를 방출할지를

직접 내가 클로저 안에서 호출할 수 있는 것임!!!

이렇게 할 경우, 유동적으로 클로저 내에서

내가 원하는 만큼 item을 onNext로 방출할 수도 있고!

원하는 시점에 onCompleted이나 onError를 호출해서 종료시킬 수도 있음!!

자, 여기서 다시 짚고 넘어가자면

onCompleted이나 onError가 호출되고 난 후엔 그 Observable은

dispose 되어버리기 때문에 더이상 어떠한 이벤트도 방출할 수 없음!!!

떄문에

이벤트가 끝나거나 에러가 발생했을 경우

observer에게 이 Observable이 더이상 이벤트를 방출하지 않는단 것을 알리기 위해

(클로저가 끝나기 전에) 반드시 onCompleted이나 onError 중 하나를 호출해야 하며,

그 이후로는 어떤 메서드도 호출해선 안됨

따라서 위 코드의 Observable을 구독하고 실행해보면,

이렇게 onCompleted이 불린 이후 작성된

observer.onNext("세 번째 방출") 는 방출되지 않는 것을 볼 수 있음!!

또, 해당 클로저의 반환 타입이 Disposable이기 때문에,

반드시 Disposable을 생성해서 return 해주어야 함!!

간단한 Observable 생성 연산자 살펴보기 끝 >_<

이 외에도 empty, never 등등은 다음 포스팅에서 살펴 볼게요!!

기다려주신 분들께

포스팅이 늦어 죄송합니다 ....... ㅠ_ㅠ

뭔가 개발자로서의 회의감도 들고 여러가지로 복잡한 달을 보낸 것 같은데

다시 화이팅 해봐야죠 :>

읽어주셔서 감사합니다! 오타 및 잘못된 내용은 언제든 댓글 주셔요!

RxSwift) Dispose /Disposable / DisposeBag 이해하기

소들이 — Tue, 7 Feb 2023 19:47:29 +0900

안녕하세요, 소들입니다 XD

hm.. 요즘 제 블로그 댓글의 대부분이

소들님은 개발 공부를 어떻게 하셨나요? 에 대한 내용인듯 한디..

교과서.. 위주로.. 공부하셈.. 두번하셈.. 라고 할뻔... ㅎㅎ

나중에 제 공부 방법에 대해서도 한번 포스팅을 해볼게욥!!

저번 포스팅에서 Observable과 Observer가 무엇이고

Subscribe가 무엇인지에 대해서 공부를 해봤잖아요??!!

이번 포스팅에선 Dispose에 대해 공부해볼 것입니당!!

모든 포스팅은 편의 말투로 합니다~!!

1. Disposable과 dispose()

여러분 Dispose라는 단어의 뜻을 아셈??

Dispose는 "처리하다/없애다"라는 뜻을 갖고 있음!!

그럼 멀 처리하나염..??

자, 관찰 가능한 형태 Observable이 있을 때

Observer는 이 Observable을 "구독"을 통해 이벤트를 받을 수 있다 했음

(좀 더 정확히는 Obsever가 Observable이 방출하는 항목에 대해 받는 것)

그러면.. 내가 만약 더이상 이 Observable에 대한 이벤트를 받고 싶지 않아서..

"구독을 해제"하고 싶을 땐 어떻게 하나요!?

할 때 사용할 수 있는 것이 바로 Disposable이라는 것임!

아항,,,!! 머라능겨,,!!

여러분 이전 포스팅에서 우린 Subscribe라는 메서드를 통해

Observer가 Observable을 구독할 수 있단 것을 알게 되었잖음!?

근데 Subscribe 메서드 원형을 다시 살펴보면

이렇게 반환 타입이 Disposable인 것을 볼 수 있음!!

즉, Subscribe 메서드를 호출할 경우 Observable을 구독 할 수 있지만

해당 Observable의 이벤트가 나가리라 더이상 필요하지 않을 때

해당 구독을 취소할 수 있는 수단인 Disposable이란 타입의 값을 리턴하여 준단 말임!

자, 그럼 리턴 타입인 Disposable을 살펴보면

이렇게 dispose라는 메서드를 가진 Protocol로 정의되어 있음!!

여기까지 봤을 때 유추해볼 수 있는 것은,

Observer는 Observable을 구독하기 위해 Subscribe라는 메서드를 사용하는데,

이 Subscribe 메서드는 구독을 해제할 때 사용하는 Disposable이란 타입의 인스턴스를 반환하는구나!

그러면 이 리턴된 Disposable타입의 값에 대고 dispose() 메서드를 호출하면!!

우리가 구독한 Observable에 대해 구독을 해제할 수 있겠구나!

정답입니다~~!

예제로 보자

let sodeulDisposable = sodeulButton.rx
                                   .tap
                                   .subscribe(onNext: {
                                       print("소들이 버튼 눌림!")
                                   })
 
sodeulDieButton.rx
              .tap
              .subscribe(onNext: {
                     sodeulDisposable.dispose()
                     print("소들이 버튼을 구독 해제하자!")
               })

위 코드를 보면,

sodeulButton의 tap 이벤트에 대해 subscribe를 통해 구독을 하고,

해당 구독을 취소할 수 있는 리턴 값,

즉 Disposable 인스턴스를 sodeulDisposable이란 변수에 저장 했음!!!

그리고 sodeulDieButton이 눌렸을 때

이 sodeulDisposable의 dispose() 메서드를 호출 해보는 것임!!!

그럼 어떻게 되냐

gif 짤입니다만?

sodeulDieButton이 눌리기 전까지 잘 동작하던 sodeulButton의 tap 이벤트가,

sodeulDieButton이 눌리는 순간

sodeulButton의 tap Observable에 대한 구독을 해제해주기 때문에,

더이상 sodeulButton의 tap 이벤트에 대한 처리를 할 수가 없어짐!!!

따라서 구독 해제 후에 버튼을 누르면 더이상 아무런 이벤트를 하지 않는 것

정리하자면,

Observer가 어떤 Observable의 이벤트를 받고 싶을 경우,

Subscribe 메서드로 "구독"을 통해 할 수 있었음!

근데 더이상 이벤트를 받고 싶지 않아서 "구독을 해제"할 경우를 대비해

Subscribe 메서드는 Disposable이란 타입의 리턴 값을 줌

이 Disposable은 프로토콜 타입으로 dispose 메서드를 가지고 있는데,

만약 Observable이 방출하는 이벤트를 더이상 받고 싶지 않은 경우,

Subscribe를 했을 때 얻은 이 Disposable에 대고 dispose() 메서드를 호출할 경우

해당 Observable에 대한 구독을 해제 할 수 있음

이해가.. 됐.. 겠지..?

근데 사실 dispose 메서드를 실행하는 건,

해당 시점(내가 원하는 시점)에 해당 이벤트의 구독을 끊기 위함인 것도 있지만

가장 중요한 이유 중 하나는 바로

메모리 관리

를 위해서임!!

Observable은 기본적으로,

complete이나 error가 발생하기 전까진 계속 이벤트를 방출 시키는데,

따라서 이벤트가 더이상 방출되면 안 되는 시점에서 우리는 이 리소스를 직접 deinit 해줘야 함!!

만약 이 deinit 해주는 과정을 하지 않으면,

이 리소스는 계속해서 필요할 때마다 이벤트를 방출시키는 메모리 릭(leak)으로 이어짐

그러면 어떻게 해당 Observable과 관련된 리소스를 deinit 시킬 수 있냐구?

바로 위에서 공부한 dispose() 메서드가 있짜너!!!

Disposable 타입의 인스턴스의 dispose 메서드를 호출한다는 것은

해당 Observable에 대한 리소스를 deinit 시킨다는 것

즉, Rx에서 메모리 관리를 한단 것

라고 볼 수있음!!ㅎㅎ

따라서 Rx에서 이 Dispose는 메모리와 관련이 있기 때문에 아주 중요한 메서드였떤 것임

사실 엥 갑자기 메모리 릭이요?

이벤트가 더이상 방출되지 않는 시점이요? 0.1도 와닿지 않는데요?

할 ㅎ수 있기 때문에 이와 관련된 예제를 보여주겠음

class SodeulViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
 
        let _ = Observable<Int>.interval(
          .seconds(1),
          scheduler: MainScheduler.instance
        )
        .subscribe(onNext: {
            print($0)
        })
    }
}
 

당장 Observable을 생성하는 Operator는 모를 수 있으니

위코드의 역할을 잠깐 설명하자면

SodeulViewController가 실행되면,

1초에 한번씩 0부터 순차적인 숫자(0,1,2,3...)을 방출하는 Observable을 만들고,

해당 Observable을 구독하여 이벤트가 방출됐을 때, 그 숫자를 출력하게 한 것임

그리고 해당 구독을 통해 리턴받은 Disposable 타입의 인스턴스론 아무짓도 하지 않음

자, 이렇게 될 경우 어떤 문제가 생기는지 보겠음

짤입니다만? 메모리 릭입니다만?

SodeulViewController가 생성되어 띄어졌을 때,

1초에 한번씩 순차적인 숫자를 방출하는 Observable이 생성되고,

해당 Observable이 이벤트를 방출 했을 때 subscribe 클로저에 의해 0,1,2가 찍히고 있음

여기까진 문제가 되지 않음!!

근데 2까지 찍히고 나서 SodeulViewController를 내려서,

해당 Observer의 이벤트를 실행하던 ViewController가 앱에서 사라졌음에도 불구하고,

해당 Observer에 대한 리소스가 해제되지 않아서

죽지 않고 계속 이벤트를 방출하고 있는 메모리 leak이 발생하고 있는 것임!!

(이 Observable을 생성해서 Disposable을 갖고 있던 ViewController는

이미 deinit 되어버렸기 때문에 해당 리소스를 해제할 수 있는 방법이 없음)

따라서, 다음과 같이

class SodeulViewController: UIViewController {
    private var timerDisposable: Disposable?
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
         timerDisposable = Observable<Int>.interval(
           .seconds(1),
           scheduler: MainScheduler.instance
         )
         .subscribe(onNext: {
             print($0)
         })
    }
    
    deinit {
       timerDisposable?.dispose()
    }
}
 

나를 갖고 있는 ViewController가 deinit 되는 시점에

해당 Disposable에 대한 dispose를 통해

해당 Observable 리소스에 대해서도 같이 deinit을 실행시켜주면,

메모리 릭 컽

위처럼 ViewController가 deinit 될 때

해당 Observable 리소스에 대한 dinit도 같이 이루어지기 때문에

메모리 릭이 나지 않음!!!

이제 이 Disposable과 dispose 메서드에 대해 다 이해를 했길..!!

2. DisposeBag

DisposeBag은 ㅁㅓ냐하면,,,

말 그대로 Disposable을 담는 Bag..

자, 위에서 배운 대로 우린 해당

Observable 리소스가 해제되어야 할 시점에 dispose를 호출해주어야 한다고 헀음!

근데 만약 다음과 같이, 해제해줘야 하는 리소스가 많아지면,

class SodeulViewController: UIViewController {
    private var timerDisposable: Disposable?
    private var button1Disposable: Disposable?
    private var button2Disposable: Disposable?
    
...

    deinit {
      timerDisposable?.dispose()
      button1Disposable?.dispose()
      button2Disposable?.dispose()
    }
}
 

위처럼... 지저분한 전역변수와 코드가 늘어날 거잖음.......!????

아아 -...

누가 이 Disposable들을 담는 배열 좀 만들어줬으면 좋겠는데 ........

네 만들어드렸습니다~

누가!? DisposaBag이!

RxSwift에서 제공하는 이 DisposeBag이란 것은
쉽게 말해서 Disposable 객체를 담는 배열인 것임!!

class SodeulViewController: UIViewController {
    private var disposeBag: DisposeBag = .init()
}
 

위처럼, 전역 변수로 disposeBag 하나를 선언해주고,

disposable 객체를 이제 어떻게 담냐면!!!!

Disposable 프로토콜의 기본 메서드로 제공하는

이 disposed(by bag: DisposeBag) 메서드를 이용해서 담을 것임!!

class SodeulViewController: UIViewController {
    private var disposeBag: DisposeBag = .init()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
         Observable<Int>.interval(
           .seconds(1),
           scheduler: MainScheduler.instance
         )
         .subscribe(onNext: {
             print($0)
         })
         .disposed(by: disposeBag)
    }
}
 

위처럼 subscribe를 통해 배출된 Disposable 객체에 대고

disposed(by bag:) 메서드로 미리 선언된 disposeBag 객체를 넘겨주면,

해당 disposeBag 안에 해당 Disposable이 담기게 됨!!!

자, 그럼 이제 어떤 생각이 드냐면,

그럼 deinit되어야 할 때 disposeBag 안에 들어 있는 Disposable 객체들을 다

dispose() 시켜야겠네요!!!???

라는 생각이 들잖음??

근데, 실제로 위 코드처럼 굳이 deinit 때 아무런 작업을 해주지 않아도

앞에 짤리는 거 양해 바람

메모리 릭이 일어나지 않음!!!!!!1

이는 왜그러냐면,

DisposeBag 객체를 좀맘ㄴ 까보면 되는데

위처럼 DisposeBag 객체 자체가 deinit되는 순간,

내부에 있는 dispose() 메서드를 호출하는데

이 메서드에서 해당 Disposables란 Disposable 배열에 담긴

disposable을 순회하면서 모두 dispose() 메서드를 호출해주기 때문임!!!

(물론 self._dispose 메서드에서 뭐 Lock과 관련된 내용이 있는데.. 이 내용은 생략 하겠음!!)

정리하자면,

DisposeBag을 전역 프로퍼티로 선언해준 경우,

(다른 곳에서 참조하지 않은 경우) 해당 DisposeBag을 담고 있는 인스턴스가 사라질 때

DisposeBag이란 프로퍼티도 같이 deinit이 될 것이고,

이때 내가 갖고 있는 Disposable의 배열을 순회하며 dispose() 메서드를 호출해주기 때문에

딱히 별도의 작업을 해주지 않아도,

DisposeBag이 갖고 있는 Disposable들의 메모리 릭이 나지 않을 수 있던 것!!

(만약 특정 순간에 disposeBag을 직접 비워주어야 하는 상황이면

해당 상황에 맞게 disposeBag을 메모리에서 해제해주면 됨!!)

+ 위에서 말했듯

disposeBag은 자신이 deinit 될 때

자신이 갖고 있던 해당 Disposable을 모두 dispose() 시켜버리기 때문에,

class SodeulViewController: UIViewController {
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let disposeBag: DisposeBag = .init()
        
         Observable<Int>.interval(
           .seconds(1),
           scheduler: MainScheduler.instance
         )
         .subscribe(onNext: {
             print($0)
         })
         .disposed(by: disposeBag)
    }
}
 

위처럼 만약 disposeBag을 전역이 아닌 viewDidLoad 메서드 안의 지역변수로 선언할 경우,

viewDidLoad 메서드가 끝날 때 disposeBag도 같이 메모리에서 해제되기 때문에

이때 등록되어있는 Observable 또한 다 같이 구독 해제 되어 버려 위 코드에서의 Observable이 작동하지 않을 것임

따라서, disposeBag을 사용할 땐 유의 하시길!(보통 전역에 둠)

3. Subscribe 할 때 마지막 클로저 onDisposed: 는 말이죠

내가 이전 Subscribe 메서드를 설명할 떄,

public func subscribe(
    onNext: ((Element) -> Void)? = nil,
    onError: ((Swift.Error) -> Void)? = nil,
    onCompleted: (() -> Void)? = nil,
    onDisposed: (() -> Void)? = nil
) -> Disposable

onDisposed는 Disposable에 대해 설명하고 하려고 생략했었는데,

이제 disposed에 배운 이상 위 코드는 말 안해도 알 것이라 생각함

해당 Observable이 구독 해제될 때,

즉, disposed() 메서드가 불릴 때 실행 될 클로저를 넘겨주는 것임!!

(onError나 onComplete으로 인해 dipsosed 될 때도 당연히 실행 됨)

따라서 다음과 같이

낡 아진 서랍 속에서~~ 차갑 던 서로를 기억해~~

해당 Observable이 구독 해제 될 때,

등록해놓은 클로저가 실행된답니다 :)

(코드를 보면 onDisposed 클로저를 보실 수 있습니다 ㅋ)

4. ControlEvent의 경우, 해당 이벤트를 갖고 있는 인스턴스가 deinit 될 때 자동으로 dispose 됩니다

내가 이것 때문에 살짝 헷갈렸었는데 음 ..

다음과 같이 내가 ControlEvent를 통해 Observable을 구독할 때

import UIKit
import RxSwift
import RxCocoa
 
class SodeulViewController: UIViewController {
    @IBOutlet weak var sodeulButton: UIButton!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        sodeulButton.rx.tap
            .subscribe(onNext: {
                print("소들 버튼 눌림")
            }, onDisposed: {
                print("소들 버튼 disposed")
            })
    }
}
 

위처럼 Disposable에 대한 처리를 따로 해주지 않았음!!!!!!!!!1

(물론 Subscribe 메서드의 Result를 사용하지 않는다는 노란 에러는 뜸)

Dispoable을 받아서 deinit 될 떄 처리해주지도 않았고!!!

DisposeBag에 넣어두지도 않았음!!!!

근데!!!!!!!!!

5억년 뒤의 난 행복할 거야

엥..??? 제가 따로 dispose를 해주지 않았는데..

자동으로 disposed() 메서드가 불리며, onDisposed: 에 등록해놓은 클로저가 불림...

세상에 이럴 수가

이게 가능한 이유는 말이죠

코드를 까보면서 예상한 건데

ControlEvent를 만들 create 메서드를 통해 생성된 Observable에

take(until:)이라는 operator를 실행시키는데, 이때 파라미터로 deallocated를 넘겨줌!!

(deallocated를 넘겨주는 코드는 넘 ㅜ어려워서 생ㄹㄹ략 흐규흐규ㅠ)

이 코드를 본 내 생각은,

ControlEvent를 통해 Observable을 구독하는 경우,

해당 ControlEvent를 갖고 있는 객체(sodeulButton)가 deallocate 되기 전까지만 구독을 하기 ㅣ때문에

뷰가 사라져서 sodeulButton도 같이 deallocate 되었다면,

구독도 자동으로 중지되는 것이 아닌가 싶음!!

UIControlEvent를 가진 객체가 deinit되면,

당연히 해당 객체를 통해 생성한 Observable 또한 같이 쓸모가 없어지니...

자동으로 이때 해당 구독을 취소하는 작업도 진행하게끔 해놓은 게 아닐까

하는 생각이 듦...!!

(코드를 보고 해석한 건데, 만약 틀렸다면 피드백 주세요!!)

근데 ControlEvent의 경우 자동으로 dispose 된다고 해도,

명시적으로 disposeBag에 넣는 게 좋아 보입니다!! (노란 에러도 뜨기 때문)

음.. RxSwift의 포스팅의 텀이 길어지는 이유는 ㅠ

이해하기 쉽게 설명하려다 보니 생각보다 내용이 깊어지고, 자세해져서

이에대해 다시 공부하고 이해하고 쓰고 하느라 길어지네요 ㅠㅠ

Rx만 쓰다간 블로그 글 1달에 1개쓸 수 있으니

중간에 다른 공부도 포스팅 하도록 하겠읍니당ㅎㅎㅎㅎ

오늘도 읽어주셔서 감사하고,

오타 및 피드백은 언제나 환영입니다 :)!!!

RxSwift) Observable, Observer, Subscribe 흐름 이해하기

소들이 — Tue, 10 Jan 2023 20:39:49 +0900

안녕하세요, 소들입니다

12월 한 달.. 망나니처럼 논 업보를 청산하러 왔습니다.. OTL..

저번 포스팅에선 RxSwift가 무엇인지,

반응형 프로그래밍이 무엇인지에 대해 개념적인 이해만 했잖아요??

이번 포스팅에선

Observable

Observer

Subscribe

의 흐름에 대해 좀 이해를 해보려고 합니당!

당장 Observable를 생성하는 연산자가 뭐고 어떻게 생성하고를 배우고 하는 게 아니라,

이들이 어떤 상호작용을 통해 반응형 프로그래밍을 이루는지에 대해 다룰 포스팅이에요!

해당 기능에 대해 더 자세하게 다룰 내용은 다음 포스팅부터 진행 하겠습니다!

이전 포스팅 내용을 숙지 하고 있다는 가정 하에 쓰기 때문에,

Reactive Programming이 뭔지 모르신다면 먼저 보고오시길 바라겠음

모든 포스팅은 편의 말투로 합니다~!!

문서는 그저 기본 개념만 있어서..

문서 + RxSwift 코드 뒤적이며 제 방식대로 이해한 거라

혹여나 잘못된 내용은 꼭꼭 피드백 주세요!

내용이 꽤 어렵습니다

1. RxSwift가 뭐라구!?

RxSwift는 비동기 프로그래밍을

관찰 가능한 순차적 형태와 함수 형태의 연산자를 통해 처리하게끔 도와줍니다

우린 앞서 RxSwift에 대해 위와 같이 정의 하면서,

RxSwift는 반응형 프로그래밍이기 때문에

어떤 비동기 이벤트에 대해 관찰 가능한 형태로 만들고

이를 관찰하는 놈이 있을 경우, 이 비동기 이벤트의 변화에 따른 전파를 받을 수 있구나

를 이해 했잖음??

여기서..!!!

관찰 가능한 순차적인 형태가 바로 Observable

해당 이벤트의 변화를 관찰하여 전파 받는 놈이 바로 Observer

끝^^!!....

이라 하고 싶지만,,,^^,,,

좀 더 자세히 알아보러 갑시당!!

2. Observable과 Observer

2-1. Observable

자, 여러분

RxSwift의 정의 중 머릿부분만 짤라서 봐보셈

어떤 비동기 이벤트에 대해 관찰 가능한 형태로 만든다 였잖음!??!

여기서 이 관찰 가능한 형태라는 것이 바로!! 앞으로 Observable이라고 부르는 것임!! ㅎㅎ

따라서 Observable의 정의를 보자면,

Observable은 관찰이 가능한 흐름으로,

비동기 이벤트의 시퀀스를 생성할 수 있는 대상

을 말함!!

실제, RxSwift의 Observable이란 것에 대한 정의를 보면

제네릭 클래스로 구성이 되어 있음!!!!

우리가 비동기 이벤트를 어떤 관찰 가능한 형태로 만든다는 것은,

비동기 이벤트를 제네릭 타입의 Observable이란 클래스 인스턴스를 만든단 것과 같은 것임!!

당장 Observable을 어떻게 만드는지,

어떤 연산자를 쓰는지는 다음 Observable 포스팅에서 다룰 것이니 넘어가셈

아.. 음.. 오키..

근데 Observable이 비동기 이벤트의 시퀀스...?...를 생성한다는 게

도대체 무슨 말잉겨,, 싶잖음??

조금 더 쉽게 이해를 해봅시당

우리가 가장 많이 사용하면서, 가장 대표적인 비동기 이벤트가 뭐가 있음?

바로 UIButton(버튼)의 클릭 이벤트임!!!!!

위와 같이 버튼을 만들었을 때, 버튼은 왜 비동기 이벤트일까??

내가 버튼을 만들긴 했지만,

이 버튼의 클릭 이벤트가 유저에 의해 언제 발생할지 선언할 당시에는 모름!!

따라서 우린 이벤트가 들어왔을 때를 가정하고 프로그래밍을 해왔잖음?

(만약 버튼이 sync 동작이었다면, 버튼이 눌릴때까지 아무 작업도 할 수 없을 것임)

따라서 버튼은 비동기 이벤트에 해당됨

근데 Reactive Programming이란,

데이터의 흐름이 변경되었을 때 전파하는 데 중점을 둔 프로그래밍이잖음

따라서 여기서 데이터는 버튼이 될 거고,

데이터의 흐름이 변경된다는 것은 버튼이 클릭 된다는 것이 될 것임!

그렇다면 이 버튼의 흐름 변경을 전파하기 위해선

이 버튼의 클릭 이벤트가 "관찰이 가능한 형태"

즉, Observable이 되어야 하겠구나!

정리하자면,

버튼의 클릭을 나타내는 UIButton의 tap 이벤트는 비동기 이벤트로,

데이터의 변화에 대해 관찰이 가능한 형태,

즉, RxSwift에서 이를 Observable 형태로 만들 수 있음

그러면 이 버튼이 눌렸을 때 어떤 일이 일어나냐면,

버튼이 눌렸다는 것은 데이터의 흐름이 변경 되었다는 거잖음?

따라서 이 버튼의 tap event에 대한 Observable은

버튼이 눌렸을 때(비동기 이벤트가 발생했을 때),

해당 이벤트가 발생했다는 것을 알려주기 위해 "항목(item)"이란 것을 "방출(emit)"함!!

(좀 더 쉬운 단어를 찾았으나.. 음 ReactiveX 홈페이지에서 item이라 표현하넹..)

이런 식으로!!!

그럼 다시 이해할 수 없는 단어 조합으로 돌아가서,

Observable을 비동기 이벤트의 "시퀀스"를 생성할 수 있는 대상 이라 했잖음???

시퀀스라고 한 이유가,

이런 식으로 버튼이 여러번 눌리면,

그만큼 Observable은 해당 이벤트에 대한 항목을 순서대로 방출하기 때문임!!

(화살표 방향처럼, 오른쪽으로 갈 수록 더 최근에 눌린 항목이 됨!)

정리하자면,

비동기 이벤트를 관찰 가능한 형태로 만든 것이 바로 Observable이고,

이 Observable은 실제 그 비동기 이벤트가 일어났을 때, 이를 알리기 위해

그 이벤트에 대한 항목(item)을 시퀀스로 방출하는구나!

그럼 이 비동기 이벤트가 방출하는 항목을 누가 받나염?

바로 Observer가 받아염!!

2-2. Observer

Observer는 Observable을 구독합니다

좋아요.. 구독... 알람 설정까지..ㅎ

우리가 유튜브를 볼 때, 어떤 유튜버에 대한 영상을 내 피드에서 보고 싶을 때

그때 해당 유튜버를 구독하잖음??

이와 마찬가지로,

Observer는 내가 원하는 비동기 이벤트를 방출하는 Observable이 있을 때,

해당 "Observable을 구독"을 할 경우,

그 Observable이 비동기 이벤트가 실행 되어 항목(item)을 방출 했을 때,

그 항목을 받을 수 있음!!

유튜브는 구독 버튼이라도 있는데..

Observer는 도대체 Observable 구독을 어떠케 하져,,?

이는 ReactiveX 공식문서를 보면,

Observer가 Observable을 구독할 수 있게 해주는 것이 바로 Subscribe 라는메서드임!!

또한 Observer가 이 Subscribe를 통해 Observable을 구독 했을 때,

총 세가지 클로저를 파라미터로 넘겨줘서 이벤트를 처리 시킬 수 있는데

Subscribe라는 메서드의 원형을 보면,

public func subscribe(
    onNext: ((Element) -> Void)? = nil,
    onError: ((Swift.Error) -> Void)? = nil,
    onCompleted: (() -> Void)? = nil,
    onDisposed: (() -> Void)? = nil
) -> Disposable

위와 같이 onNext, onError, onCompleted라는 파라미터가 있고(onDisposed는 설명 생략)

모두 타입이 클로저 타입인 것을 알 수 있음

자, 우리가 기존에 어떤 비동기 이벤트를 넘기고 싶을 때 클로저로 넘겼잖음??

같은 맥락임

Observer는

내가 구독하려는 Observable이 항목(item)을 방출 했을 때 어떤 작업을 할 것인지,

만약 해당 Observable이 오류가 발생 했을 때는 어떤 작업을 할 것인지,

더이상 이벤트가 발생하지 않고 종료됐을 때는 어떤 작업을 할 것인지를

subscribe의 메서드 파라미터를 통해 클로저로 같이 넘겨주는 것임!!

onNext:

Observable이 새로운 항목(item)을 방출할 때마다 이 클로저가 호출 됩니다

이때 Observable이 방출하는 항목을 클로저의 파라미터로 전달받습니다

onError:

Observable은 기대하는 데이터가 생성되지 않았거나 다른 이유로 오류가 발생했을 때,

이 오류를 구독자인 Observer에게 알리기 위해 이 메서드를 호출합니다

onCompleted:

Observable은 이벤트가 종료되어 더이상 호출되지 않을 때,

이벤트가 완료 되었음을 구독자인 Observer에게 알리기 위해 이 메서드를 호출합니다

으음...

이해가 좀 가세여..? 똑똑똑..

정리하자면,

비동기 이벤트를 관찰 가능한 형태로 만든 것이 Observable,

Observable은 해당 비동기 이벤트가 발생했을 때 항목(item)을 방출함

관찰 가능한 형태인 Observable을 관찰하는 것이 Observer,

Subscribe(onNext:...) 메서드를 통해 Observable를 구독할 수 있는데,

Observable에서 항목이 방출됐을 때, 에러가 났을 때, 이벤트가 종료되었을 때에 대한 처리를

클로저로 작성하여 파라미터로 넘겨줌

아 앞으로

subscribe(onNext: onError: onCompleted: onDisposed:)는 넘나.. 기니까

subscribe(onNext:...)로 생략해서 말하겠음

일단 이론은 이게 끝인데 ....

내가 처음 공부할 때.. 먼 생각이 들었냐면..

그럼 Observer는 또 뭔 객체로 생성해줘야 하는 건가..?

그래서 Observable을 구독 하는 건가..?

였음

이건 이제

실제 버튼을 클릭했을 때의 코드를 예제로 봐보자

3. UIButton 클릭 이벤트로 보는 Observable과 Observer, Subscribe

위에서 지겹도록 얘기 했던 것처럼

UIButton의 클릭 이벤트는 비동기 이벤트라

RxSwift에서 Observable이 될 수 있다고 했잖음??

이를 통해 실제 어떻게 사용하는지 흐름을 봐볼 것임!!

참고로 RxSwift에는 UIKit에 대한 정보가 없기 때문에,

UI와 관련된 Reactive Programming을 하려면 RxCocoa를 사용해야 함

(그렇다고 RxCocoa만 import 하면 안 되고, RxSwift로 같이 import 해주어야 함)

UIButton은 UIKit에 속해있기 때문에

RxCocoa를 import해서 UIButton의 tap에 대한 비동기 이벤트 처리를 다음과 같이 작성할 수 있음

(참고로 여기서 tap 이벤트란, .touchUpInside에 대한 동작임)

sodeulButton.rx
            .tap
            .subscribe(onNext: {
                print("Observable이 항목을 방출 했다!")
            },
            onError: { error in
                print("에러가 발생 했다!")
            },
            onCompleted: {
                print("해당 이벤트가 끝났다!")
            })
            .disposed(by: disposedBag)

위처럼 작성하면 되는데,

당장은 disposed에 대한 것은 무시해주세요~~!!!!!!!!

위 코드는 지금껏 우리가 이론으로 공부한 내용 그대로인데,

sodeulButton에 대해 tap event가 발생했을 경우,

subscribe(onNext:...)를 통해 "구독"을 해서

해당 Observable이 방출하는 항목에 대해 받을 수 있고,

이때 이 메서드의 파라미터로

onNext(항목이 방출 됐을 때, 즉 버튼이 눌렸을 때 실행시킬 클로저)

onError(에러가 발생 했을 때 실행시킬 클로저)

onCompleted(이벤트가 종료됐을 때 실행시킬 클로저)

를 각각 넘겨줄 수 있단 것임!!!

그러면 다음과 같이,

실제로 버튼이 눌렸을 때(Observable의 항목이 방출 됐을 때)

gif 짤입니다만?

Observer가 등록해놓은 클로저가 실행이 됨!

아니.. 근데.. 저는 Observer를 만든 적이.. 없는데...

그냥 Observable이 항목 방출 했을 때 실행할 클로저만 넘겨줬을 뿐인데..

어떻게 Observable이 구독이 되어 항목을 받을 수 있는 것임.??????

이거는 말이져

subscribe(onNext:...)로 클로저를 넘겨줄 경우, 해당 메서드 안에서

자체적으로 AnonymousObserver란 것을 생성해서,

해당 Observable에 subscribe를 해줌!!

결론적으로,

subscribe(onNext:...) 메서드를 사용할 경우,

메서드 내부에서 옵저버를 자체적으로 생성해서

우리가 따로 Observer를 생성하지 않고 파라미터로 클로저만 넘겨줘도

Observable을 구독하여 방출하는 항목을 받을 수 있게 된 것!

+ 참고로, Observer를 직접 생성할 수도 있는데

대표적으로 Observable이자 Observer 역할을 하는 Subject가 있음

이건 다음 포스팅에서 Observable에 대해 다룰 때 같이 다루겠음

3-1. 조금..? 많이..? 심화 내용

sodeulButton.rx
            .tap
            .subscribe(onNext: {
                print("Observable이 항목을 방출 했다!")
            }
            .disposed(by: disposedBag)

내가 위 코드를 예를 들었기 때문에

button.rx.tap 까지만 했을 때 Observable이 나오고,

따라서 그 Observable에 대고 구독을 한 것이구나! 라고 생각할 수 있는데

실제 button.rx.tap 까지만 했을 경우,

리턴 타입은 Observable 타입이 아니라, ControlEvent<Void> 타입임!!

따라서 ControlEvent란 구조체 타입을 살펴보면,

ControlEvent 구조체 안에 events란 프로퍼티로 Observable이 존재 하고,

UIButton의 경우 rx.tap 이란 연산 프로퍼티를 통해 ControlEvent의 init 함수가 불려질 때

.touchUpInside 이벤트에 대한 Observable이 생성되어 이 events 프로퍼티에 들어가게 된 것임!!

정리정리 정리!!!!!!! 하자면!!!!!!!!

button.rx.tap을 했을 땐 해당 tap event에 대한 Observable이 리턴 되는 게 아니라,

ControlEvent<Void>라는 타입이 리턴 되고,

그 ControlEvent<Void> 인스턴스 안에 events란 프로퍼티가 있는데,

이 eventes란 프로퍼티가 바로 우리가 버튼 클릭 이벤트를 받고 싶을때 구독해야할 Observable이란 것

어.. 근데 그러면

button.rx.tap까지 하면.. Observable 타입이 아닌데..!

어떻게 subscribe를 통해 구독을 한 것임..?

Observer는 Observable을 구독하는 거잖아!

그러면 button.rx.tap.events.subscribe를 해야하는 거 아닌가..!?!? 싶잖음??

응 events 프로퍼티 어차피 접근 제어자 internal이라 접근 못해~

이 의문을 풀어봐봅시당

위에서 Observable 타입이 아닌 ControlEvent 타입에 대고

subscribe를 해도 문제가 되지 않았던 이유는!!

ControlEvent 구조체가 어떤 프로토콜을 따르는지 먼저 봐야 됨

이 ControlEvent 구조체는 ControlEventType이란 프로토콜을 따르는데,

이 ControlEventType이란 프로토콜은 ObservableType이란 프로토콜을 따르고 있음!

이렇게!

근데 이 ObservableType이란 프로토콜은 ControlEvent 구조체만 따르는 게 아니라,

Observable 클래스 또한 이 프로토콜을 따르고 있음

뭘 말하고 싶은 거냐면,

extension ObservableType {
    public func subscribe(
        onNext: ((Element) -> Void)? = nil,
        onError: ((Swift.Error) -> Void)? = nil,
        onCompleted: (() -> Void)? = nil,
        onDisposed: (() -> Void)? = nil
    ) -> Disposable {
        ...
    }
}
 

우리가 구독할 때 Observable에 대고 사용하던 subscribe(onNext: ...) 메서드는

사실 Observable 클래스의 고유한 메서드가 아니라

ObservableType이란 프로토콜의 extension에 구현되어 있어서,

ControlEvent 타입 또한 이 프로토콜을 채택하고 있기에

subscribe(onNext: ...) 메서드를 사용할 수 있던 것임!

다시, 정리하자면

button.rx.tap 까지 했을 땐 해당 tap event에 대한 Observable 타입이 반환되는 것이 아니라,

이때 반환되는 것은 ControlEvent<Void> 타입임

다만, ControlEvent<Void> 타입이 내부적으로 ObservableType을 따르기 때문에

ObservableType 프로토콜 extension에 정의되어 있는

subscribe(onNext:...) 메서드를 통해 구독을 할 수 있었던 것

이해가 됐으려나..!?

근데 그러면 한 가지 의문이 또 들어야 됨

Observable에 대고 subscribe(onNext: ...)를 할 경우..

어떻게 이 Observable 자체에 알아서 구독이 되는 것이고,

ControlEvent에 대고 subscribe(onNext: ...)를 할 경우..

ControlEvent에서 Observable은 events란 프로퍼티로 갖고 있는데..

어떻게 이 events 프로퍼티에 알아서 구독이 되는 것일까..!?

를 알아보자!

이 의문을 풀기 위해선..

다시 ObservableType 프로토콜에 구현되어 있는 subscribe(onNext:...) 메서드에서

Observer를 subscribe 하는 부분을 살펴보면 됨

마지막에 코드 부분을 보면 disposable을 생성해서 리턴 할 때

이렇게 asObservable이란 메서드를 호출 한 후

observer 자체를 파라미터로 넘기는 subscribe(_:) 메서드를 호출하는 것을 볼 수 있는데,

위 의문이 가능했던 것은 바로 이 asObservable이란 메서드 때문에 가능한 것임!

자, 이 asObservable이란 메서드는 어디서 튀어나왔냐면,

Observable도 ControlEvent도 따르는 ObservableType이란 프로토콜을 다시 보면

ObservableConvertibleType이라는 프로토콜을 따르는데,

이 ObservableConvertibleType 프로토콜 안에

선언되어 있는 메서드임!!!!

따라서 당연히 ControlEvent 구조체도, Observable 클래스도

이 asObservable이란 메서드를 구현해줘야 하는데,

기존 Observable 클래스에선 asObservable 메서드에

자기 자신인 self를 리턴하고,

ControlEvent 구조체에선 asObservable 메서드를

자신이 갖고 있는 이벤트 Observable인 self.events라는 프로퍼티를 리턴하기 때문에,

Observable에 대고 구독을 하든,

Observable 타입이 아닌 ControlEvent 타입에 대고 구독을 하든

문제 없이 Observable을 구독을할 수 있었던 것이랍니다..!!!!!!

+ 아 근데

ObservableType 프로토콜의 extension에

asObservable이 기본 메서드로 제공되긴 하는데,,

이 메서드는 언제 쓰는지는 머르겠음..;;

마지막으로 한 가지 더 짚어보자면,

subscribe(_:)랑 subscribe(onNext:...) 메서드는 오버로딩으로 서로 완전 다른 메서드인데,

클로저를 통해 AnonymousObserver를 생성하는 subscribe(onNext:...) 메서드는

ObservableType 프로토콜에 extension으로 정의되어 있지만 (프로토콜에는 선언 x)

바로 다른 옵저버를 구독시켜버리는 subscribe(_ observer: Observer) 메서드는

아예 ObservableType 프로토콜 자체에 선언되어 있고,

extension으로 제공도 해주지 않기 때문에(내기준 아무리 찾아봐도 없..음....)

이 메서드의 경우

Observable 클래스는 위처럼

rxAbstractMethod라는 추상 메서드를 호출하게 구현 되어 있고,

ControlEvent 구조체는 내부 이벤트 Observable의 subscribe(_:)를 사용할 수 있도록

해당 메서드가 각각 구현되어 있음!

따라서 최종적으론, Observable의 subscribe(_:)가 불린다..!

아.. Observable subscribe(_:)에서 부르는 추상 메서드 rxAbstractMethod는

더 공부해봐야 되고.. 내용이 좀 깊어질까봐.. 사실 잘도 모르겠음ㅋ

흐름 다루는 건 여기서 그만........하겠음

왜 ControlEvent에 대해 이렇게 깊게 다루세염..?ㅠ

하고 생각하실 수 있는데,

앞으로 공부할 내용 중 하나인 Traits에 이 ControlEvent이 속해서

말 나온 김에 좀 자세히 다루고 가자!! 하다가 길어진 것 같음,,ㅠㅠㅠ

Observable과 ControlEvent 프로토콜의 내용이 좀 복잡해서 정리를 해봤는데,

당신이 독수리가 아니라면 확대해서 보시길..

위에서 말한 주요 프로토콜에 한해 이런 그림이라 보면 될듯......!?

(참고로 위에 정리해둔 메서드는 자주 사용하는 메서드와

의문점을 풀기 위한 메서드 정리일 뿐, 저게 전부는 아닙니당)

길고 .. 길다..

흠.. 이번 내용은 개인적으로 조금..? 많이..? 어렵다고 생각해요ㅠㅠ

저도 글 쓰면서 많이 찾아보고 공부하며 썼지만

잘못된 내용이 있을 것 같은 이 기분..?은 뭘까? 왠지 잠을 이룰 쑤가 업서

2022 연말 정산

소들이 — Thu, 5 Jan 2023 00:13:37 +0900

안녕하세요! 소들입니다

2021 연말 정산을 쓴 게 엊그제 같은데.. 어떻게 벌써 일 년이 이렇게 다 가버려서..

2022년의 한 해를 돌아보고 있는지.. 정말 감개가 무량하다고 볼 수 있네요

이번 연말 정산 글은 꽤나 길어질 것 같아요

한 해 동안 너무 많은 일이 있었고, 너무 많은 생각을 했고,

어쩌면 내 인생의 가장 변화가 많았던 1년이지 않을까

전 제 자신을 기록하는 글이 참 좋더라구요

1년 전의 글만 읽어도 아 나 이때 이랬구나! 이런 일이 있었구나! 이런 생각을 했었구나!

라는 회고를 할 수 있게 되기도 하고, 되게 나의 오랜 일기장을 훔쳐 보는 느낌

이번 연말 정산 말투는 그냥 내가 쓰고 싶은 말투로 쓰겠습니다

참고로 저 문과 출신, (전)국문과 지망생, (전)작가 지망생이었던 사람으로 굉장히 글이 감성적일수 있음

어찌됐든 나의 2022년, 길고 길었던 1년 간의 연말 정산 시작!!

개발

전생에 무슨 죄를 지었길래 개발자가 된 거야

유튜브 썸네일로 어그로 끄는 사람들의 마음이 이런 걸까?

내가 윤회사상을 지닌 사람은 아닌데 말이지

2022년도에 팀원들과 장난으로 이런 얘기를 많이 했다

우린 분명 전생에 나라를 팔아먹어서 개발자가 된 것이라고.. 을사오적이었을 거라구..

뭐 이렇게만 쓰면 이 사람 개발이 싫어졌나?란 생각이 들 수 있는데,

나 개발 좋아하네!?

를 정말 많이 깨달았기에, 그만큼 힘든 1년이었다

사실 뭐든지 적당히만 하면 어려울 게 없는 것 같다

개발도 적당히.. 공부도 적당히.. 말만 봐도 얼마나 쉬워!

근데 만약 적당히 하는 개발자가 내 꿈이었으면,

나의 1년은 힘들지 않았을 것이고, 개발 블로그를 운영하지도 않았을 것이다

어렵더라도, 적당히 하는 개발자가 되고 싶지 않았다

하루, 한 달, 일 년이 지날 때마다 성장하는 사람이 되고 싶었고,

연차가 쌓일 수록 그에 상응하는 경험과 지식이 쌓이길 바랐다

그래서 시간이 흐른다는 것에 대해 어느 순간부터 불안감이 들기 시작했고,

그것을 해소하기 위해 뭐라도 해보려고 많이 노력 했던 것 같다

아침에 잠으로 보내는 시간이 아까워서 8시에 출근을 했고,

4시에 퇴근하면 집이 가까운 팀원들과 함께 스터디룸에 가서 공부를 했다

덕분에 평일엔 피곤에 쩔어 있는 사람이 되어버리긴 했지만,

이렇게라도 해야 불안감이 좀 사라지는 것 같았다

내가 무슨 부귀영화를 누리자고 8시 출근을 한다고 해서 @#!*(@*(!

물론 나는 잠이 너무너무너무 많은 사람이라..

주말에 하루 쉬는 날을 모두 잠으로만 보내는 사람이라..

8시 출근에 자주 삐걱대긴 했다 ... 새벽에 팀장님한테 제일 말 많이거는 사람 나야 나~!

1월부턴 마음 다잡고 다시 열심히 살아봐야지 꼭

지금와서 돌이켜보면.. 음..

1년 동안 개발자로서의 성장통을 겪은 것 같다

성장에 대한 욕구가 정말 엄청났던 1년이었고, 그랬기에 즐거움과 괴로움을 함께 보낸 1년이었다

그렇다면 1년이 모두 지난 지금 봤을 때, 나는 많은 성장을 했을까?

그래도 이번 1년, 2022년은 정말 애썼다! 라고 말 하고 싶다

최근에 바로 1년 전에 짰던 코드를 리팩토링 했는데, 작년과 나의 차이가 많이 느껴져 신기했다

물론 지금의 코드 또한 1년 뒤의 내가 보면 "누가 이렇게 짬?ㅋㅋㅋ 엌ㅋ나넼ㅋ" 할 수도 있지만,

1년 전의 코드를 보며 와 나 이때 잘 짰네! 라는 것 보다,

이 코드 뭐임? 하고 부끄러워 하는 것이 그 간의 성장을 증명해주는 것이 아닌가 싶다

부족하기에 성장하는 개발자가 되기 위해,

계속 무엇인가를 시도하고, 공부하는 사람이 되기 위해,

2023년엔 더 많은 성장을 이룰 수 있게 노력하는 내가 되길 바란다

늦어도, 느려도 괜찮으니 천천히 가자

온전히 나를 위한 2023년의 목표다

난 매번 무엇인가 이루고 싶은 목표를 세우면,

그것을 이루기 위해 나를 벼랑 끝까지 몰아세우는 경향이 있다

나를 잘 아는 주변사람들은 그런 나를 보고 위태로워 보인다고 말하기도 했다

워낙 잔병치레가 많은데, 스트레스가 좀만 쌓이면 몸에 바로 반응이 나오기 때문에 병원을 완전 탐색 하기도 했다

그래서 2023년엔.. 그러지 않기로 마음 먹었다!

2022년의 내가 나를 몰아세웠던 이유는, 연차가 쌓이는 것에 대한 부담이었던 것 같다

내가 12월에 처음 일을 시작하기도 했고,

중간에 일을 쉰 텀도 있고 해서 연차로 따지기가 참 애매한데..

(ㅁㅓ.. 태어나마자 두 살 되는 그런 느낌..?)

경력으로만 따지면 개발 경력 3년이 채워지는 해여서 더 그랬던 것 같다

첫 회사에서의 2년 경력이, 온전한 iOS개발이 아닌 C언어 수준의 코어 개발이 주였기에

나.. 나.. 진정한 iOS 개발자 맞아..?? 에 대한 의문이 들어서 더 불안해 했던 거 같다

다행히 그 의문과 불안을 요즘엔 많이 해소시켜 나가고 있다

그래서! 마음을 좀 바꿔 먹기로 했다

아직 이뤄낸 게 많이 없어도 괜찮아! 앞으로 이뤄낼 것이 훨씬 많잖아!

그리고... 아예 없진 않잖아...!??????????

많이 성장한 블로그도 있고..!! 지금껏 열심히 공부한 지식들이 있고.....?!

조급해 하고 성급해 하지 않기로

응 만나이 도입되면 나 27살이야~ 아직 어려~ 이제 시작해도 될 나이야~

라는 마인드로 살기 ㅎ^ㅎ;;

회사

협업은 즐거워

2021년 6월, 지금 회사에 입사 하자마자 풀 재택을 했고, UI 기능을 단독으로 개발하게 됐었다

우리 팀은 iOS 개발자가 많은 편이라 협업을 하고 싶어서 많이 아쉬웠었는데,

다행히 2022년엔 여러 기능들을 시니어들과 함께 작업 할 수 있게 되었다!

상반기에는 신규 기능을 개발하며, 해당 파트의 기존 코드를 RIBs로 바꾸는 작업을 같이 진행 했다

RIBs에 대한 러닝커브 때문에 처음에 난 정말 개똥멍청인가? 해서 힘들었지만,

이해가 되지 않는 부분은 같이 진행한 팀원들에게 도움을 구하며 해결해나갔다

이때 아마 정말 일을 많이 했던 것 같다

맨날 새벽까지 회사에 살았었다 (소들이 회사의 등대라는 소문이 들렸다)

사실 어렵지 않은 기능이라 금방 구현할 수 있었지만,

오래된 코드를 새로 리팩토링 하겠다는 시니어즈의 의지 때문에 사실 사서 고생한 것이나 다름이 없었다

제대로 번아웃이 왔던 때를 생각하면, 해당 기능이 릴리즈 되고 난 후였던 것 같다

그래도 새벽에 판교에서 퇴근하는 거 생각보다 낭만은 있다

하반기에는 한 것을 꼽으라면.. 리팩토링.. 리팩토링.. 모듈화.. 모듈화..!!!

옵젝씨를 박멸하기 위한 마음으로 Swift 컨버팅 겸 리팩토링을 진행 했고,

(앱의 얼굴 쪽을 건드렸는데.. 다들 품 속에 장애보고서 10장씩 쓰고 릴리즈 하기로 했다...)

모듈화를 진행 할 땐 이 모듈의 내부를 모르고 사용하게 될 다른 개발자들의 입장에서

어떤 기능이 필요할지, 어떤 부분을 공개해야 하고 숨겨야 할지에 대해 많이 생각했던 것 같다

매일 회의실에서 각자 작업한 내용의 코드를 띄워놓고 리뷰하는 시간을 가졌는데,

함께 더 나은 코드를 만들어간다는 관점에서, 리팩토링도 개발도 너무 즐거웠다

지금 하고 있는 작업은..

작년에 직접 모듈화 한 기능을 실제 프로젝트에 도입하는 중이다..!

근데.. 와.. 이건 정말 대만족!!!!.. 이 기능을 사용하는 다른 팀원들한테 가서 자꾸

어때? 좋지? 편하지? 기존 레거시로 했을 때랑 비교 해보면 어때!??

... 내 자식 자랑마냥 물어보게 된다.. (미안..)

1년 동안 좋은 동료들을 만나 협업을 하며 정말 많이 배웠다

객체 지향, 프로토콜 지향으로 프로그래밍 하는 방법에 대해 더 심도 있게 알게 되었고,

다양한 디자인 패턴을 공부하고 직접 코드에 적용해볼 수 있어서 좋았다

아마, 나 혼자 진행 했으면 절대 이렇게 못 했을 것 같다

블로그

기초가 단단한 개발자가 되고 싶어

2022년 초반엔.. 블로그에 현업에서 사용하는 기술에 대해 좀 많이 다루고 싶었는데,

Swift의 문법이나 기초에 대해 또 많이 다루게 되어 버렸다..

그나마 최신에 1개 올리고 잠적해버린 RxSwift가 현업과 좀 밀접한 글이 될 것 같긴 헌데..

12월 연말 망나니 이슈로 맛보기만 올리고 잠적해 버려서..ㅎㅎ 요즘 주변 인사가

"님아 RxSwift 글 2탄 언제 올라옴?"이 되어버린 느낌

내 블로그 안 망했어요 ... 정상 영업 합니다..

(70프로 정도 쓰긴 했는데.. 연말정산 글만 마무리 짓고 쓸 예정)

사실..! 쓰고 싶은 내용은 정말 많다

새로 공부한 아키텍쳐에 대해서도 얼른 쉽게 글로 정리하고 싶고

모듈화나 디자인 패턴, 단위 테스트에 대해서도 다루고 싶은 게 많은데..

(물론 글을 작성하며 내가 공부하기 위함이 더 크지만)

뭐랄까.. 개발할 때마다 느끼는 거지만,

우리는 생각보다 개발할 때 Swift에서 제공하는 많은 문법들을 모르고 사용할 때가 많다

개발을 함에 있어 아케텍쳐와 디자인 패턴도 물론 중요하지만,

그 전에 내가 사용하는 언어에 대한 기초가 탄탄해야 코드의 퀄리티도 올라가고

그 이후 무엇을 공부하든 습득이 빠르다고 생각한 것이 컸던 것 같다

난 블로그에 글을 쓸 때 늘 단계를 중요시 했는데,

익명 클로저가 뭐임? -> 그 전에 함수 공부 했음? -> 함수부터 공부하고 오렴!

내 머릿속의 단계에선 아직 내 블로그는 기초를 다 끝내지 않았단 생각이 들었다

뭐 그런 이유로 2022년엔 아직 다루지 않은 기초 문법에 대해 많이 다루게 됐다

2023년엔.. 음.. 그래도 기초만 중심으로 글을 쓰지는 않을 예정이다!

기초는 이제 어느정도 다뤘다고 생각한다

RxSwift로 시초를 끊은 만큼, 현업에서 사용하는 기술들에 대해 많이 다뤄볼 예정이다

현업 개발자분들도 내 블로그를 많이 애용하실 수 있게.. ㅎㅎㅎ...

내 블로그 화이팅..

개발자 소들이 ☃️

이번 연도에 들며 나를 '개발자 소들이'로 알아봐주시는 분들이 정말 많이 늘었다

조회수가 많이 늘고, 구독자가 많이 늘고, 댓글이 많이 달리는 것은 체감 했지만

실제로 다른 iOS 개발자분들이 나를 알아봐준단 것은 생각도 못 했던 일이었는데..

2022년엔 생각치 못한 일이 많이 일어났다

지금 회사에 들어오고 얼마 안 돼서 자기 소개를 작성할 때

5년 뒤 목표를 위와 같이 잡은 적이 있다

이때 당시엔 별 볼 일 없는 블로그였어서 원대한 꿈을 안고 쓴 글 같은데,

지금은 그래도 조금씩 실현해 나가고 있는 것 같아서 기분이 좋다

물론, 내가 기초 글을 중시한 만큼

거의 대부분은 iOS 개발 연차가 낮으신 분들이 많이 봐주시긴 한다

2023년엔..! 현업과 관련된 글도 많이 작성해서

개발 연차가 있으신 분들도 많이 참고하는 블로그가 될 수 있도록 노력해봐야겠다

2021년 회고 때 1주일에 글 1개를 쓰겠다! 라는 무지성 목표를 잡았었는데,

현업이 바쁠 때 1주일에 1개는 무슨, 1달에 1개도 힘들단 것을 체감했다..

그리고 블로그 글 쓰는 것을 날짜를 정해두고 마치 일처럼 하다보니, 더 부담되고 하기 힘들어져버렸다

따라서 2023년엔 글에 대한 부담을 줄이고,

내가 쓰고 싶은 글을 내가 쓰고 싶은 날짜에 쓰는 것이 목표다

다만, 2022년보단 훨씬 더 많이 쓸 수 있도록 노력할 것은 확신한다

나의 4년 남은 목표를 위해서라도! (현 시점 구독자가 312명이나 되었다 >^<)

개발 외의 나의 2022년

어쩌면 내 인생 가장 힘들었던 1월 ☘️

나는 저번 연말 정산 글에서 얘기했듯이,

작년은 나에게 뭔가 정말 좋은 일이 생길 것만 같은 그런 나이였다

아무 근거 없이 그냥 1년 내내 행복 회로를 돌리면서 살았던 것 같다

그거에 대한 후폭풍인가? 2022년의 1월은 그렇게 긍정적으로만 보낸 내 1년을

"님 뭐하셈? 인생은 원래 힘든데요?" 하고 비웃듯 시작부터 정말 힘든 일만 몰아쳤다

개인적인 여러 일들도, 회사 일도 너무 힘들었다

새벽까지 일을 하고 자기 전에 침대에 누우면,

내일 지구 멸망 안 하나? 란 생각이 먼저 들었던 것 같다

근데 지구는 쉽게 멸망하지 않았다ㅎ;;

난 원래 힘든 티를 주변에 잘 내지 않고 혼자 감내하는 스타일인데,

이때 만큼은 후에엥 애드라 나 힘들어!! 하고 주변 여기저기에 많이 얘기했던 것 같다

그럴 때마다 주변 사람들이 정말 많은 위로를 해주고 도와줬다 (고마워!!!!!)

힘들게 시작했던 2022년의 1월이었던 만큼, 2023년의 1월은 누구보다 찬란했으면 좋겠다!

코캉스..는 무슨..?

8월 초에 코로나에 걸렸다

워낙 사람 만나는 것을 좋아하던 나였고,

아무리 싸돌아댕겨도 끄떡 없길래 난 내가 슈퍼면역인 줄만 알았다

그러나.. 강남이 침수된, 서울에 비가 억수로 내리던 날.. 그날 나는 코로나에 걸렸다!

전날 이상 증세를 느꼈고, 다음날 아침에 일어나자마자 열이 나고 목이 더 아파졌길래 자가키트를 했다

근데!!!!!! 뭐임...!?!??! 진짜 이렇게 하자마자 대기 시간도 없이 새빨간 두 줄은 처음봤다

분명.. 확진자들이.. 자가키트는 흐릿한 두 줄이랬는데.. ...

어쨌거나 코로나에 확진되고 처음엔 1주일 격리라길래 응 코캉스 개이득~ 했는데ㅎㅎㅋㅋ

코캉스는 개뿔 며칠 동안 고열, 근육통, 오한... 그리고 인후통에 미각 상실까지 아주 골고루 다 왔다

식중독 걸렸을 때보다 더 아팠다.. ㅇ<-< (카레에 코박아도 냄새가 안 나..)

슈퍼면역이라고 말하며 무지하게 돌아다녔던 나 자신.. 매우 반성해..

새로운 취미의 시작, 나는야 기타맨

밴드 이야기는 바로 다음에 쓰겠지만...

밴드에서 포지션을 피아노와 겸직으로 기타를 하게 됐다!

이유라 함은 나의 오랜 숙원.. 난 통기타를 정말 오래 전부터 배우고 싶었다

그래서 뭐.. 못할게 뭐 있어..!!! 배우기로 했다..!!

10월 부터 기타학원을 다니면서부터 벌써 3달차 기린이가 되었다

근데 기타 배우면서 느낀점이 뭐냐면,,

기타 오래 친 사람들은 혹시,, 손가락 감각을 몽땅 잃어버린 건 아닐까,,? (공포,,)

기타를 친지 어언 3달.. 내 손은 벌집 삼겹살이 되었다..

그래도 이젠 어느 정도 굳은살이 박여서 괜찮다

대신 네일아트나 손톱 미용은 꿈도 꾸지 못하는 몸이 되어버렸다...ㅠㅠ

처음엔 통기타로 아르페지오를 연습하고 싶었지만,

지금은 밴드 연습을 위해 일렉으로 전향해 파워코드와 다 때려 부수는 곡을 연습하고 있다

곧 이빨로 일렉 기타 뜯을 것 같다

그래도 어느정도 흉내낼 수 있는 곡이 꽤 늘었다!

일렉만 배우고 있긴 하지만 나의 로망이었던.. 통기타도 꾸준히 연습하고 있다

최근에는 소들이의 Wind Song 연습이.. 시작... 되었다... (1일ㅊㅏ ...)

어느 한곡이라도 완곡 할 수 있을 때, 꼭 블로그에 올려 기념 해야겠다

그전까진 다시

기타 학원 다녀오면 이 이모티콘 보내줘야 됨

이빨로 일렉 뜯으러 이만

2022년의 우리 밴드는

2022년의 마지막은 밴드 얘기로 끝내볼까 한다!

대학생 때 친구들과 무계획으로 만들어본 밴드였지만,

점점 욕심이 생기고 진지해지고 했던 것 같다

따라서 새로 사람도 받았다! 당근마켓으로 일렉 기타를 새로 뽑았는데,

우리랑 처음부터 친했던 사람처럼 잘 어울린다.. like 망나니..

그동안 꽤 많은 곡을 했는데,

대충 2022년 곡을 요약해서 영상으로 짧게씩 올려볼까 한다

참고로 정말 엉망진창이고, 화질과 음질이 정말 정말 구림 ..ㅎ..

https://www.youtube.com/watch?v=e-sFycCtXqo

0:00 뭐라할까 - 브리즈 (통기타)

A에서 Bm로 가는 게 잘 안 돼서 소리가 예쁘게 나진 않지만,

내가 너무 좋아하는 곡이라 꼭 제대로 될 때까지 연습할 예정이다

2:25 zombie - Day6 (통기타)

아마.. 이 모든 곡 중 내 통기타 소리가 가장 잘 들리는 곡이 아닐까..

데이식스 만세

4:36 한페이지가 될 수 있게 - Day6 (피아노)

중간으로 갈 수록 피아노가 허술해지는 것 같은 건 기분 탓일거야

여러분의 기분이 안좋은 탓일거야

6:16 나는 나비 -YB (피아노)

중후반에 피아노 급발진 진짜 먼데

잘 한 영상도 있는데.. 찾기 귀찮아서 가장 최신 거로 (틀렸지만) 올려버림

7:48 스물 다섯 스물 하나 - 자우림 (피아노)

예전에 블로그에 올렸던 적 있으니

풀 영상은 거기서 보세염 보컬 만세~!!

10:02 시작 - 가호 (일렉)

일렉 파워코드로 백킹 치는 중인데 들리긴 하는 걸까..?

우리가 중간 중간 호우! 안 외쳐 주니까 보컬이 드럼 머리통 하나 떼와서 그거 치고 논다..ㅠㅠ

11:06 그대에게 - 무한궤도 (피아노)

아니 이거 신디 치는 거 찾아야 되는데 드럼이 그냥 시작해버려서 무슨 오르골 소리가 남..

중간에 소리 찾아 가기 위한 여정을 떠나는 피아노.. 그러나 찾지 못 하는..

이거 원래 멜로디 치는 게 아니라 드럼이랑 박자맞춰 치는 건데 당시엔 내가 몰라서 멜로디 쳤다 히히

12:50 고백 - 델리스파이스 (통기타)

내가 일렉으로 좀 마음 돌리게 된 계기..

통기타로 처음 도전한 곡인데 일단 F코드에 한번 좌절 했었고,

무엇보다 통기타를 앰프에 연결해서 치면.. 소리가 굉장히 별로다ㅠㅠ.. 째지는 소리..

14:12 (이제 도전할 곡) 알루미늄 - 브로큰 발렌타인 (통기타)

튜닝도 안 하고 쳐보려다가 깜짝 놀라서 멈추는 김소들. ..

중간에 피크 통기타 바디에 들어가서 꺼내는 건 왜저래...ㅠㅠㅠㅠㅠㅠ?? 관종인가..

사실 이 곡은 한 6월 쯤에 도전하려고 했었는데

기타쌤한테 뒷부분 일렉 솔로 1분짜리 들려줬더니 3년쳐도 못 할 수도 있다는 소리 듣고 /ff..

근데 뭐 뒤에 솔로만 다른 친구가 가라로 쳐주면 되지 않을까 싶어 다시 도전 할 곡!!

노래가 넘흐 좋아

사실 중간중간 친 곡까지 더하면 진짜 훨씬 많은데

일단 2022년도의 곡들은 대충 정리한 것 같다

2023년에 새로 시작하는 곡은

Smells Like Teen Spirit - Nirvana (일렉)

don't look back in anger - Oasis (통기타)

넌 내게 반했어 - 노브레인 (피아노)

지금 연습 중에 있다..!!

사실 기타로 포지션 번경을 하면서 .. 사알짝 방황?을 했다

피아노의 경우 어렸을 때부터 익숙했고,

합주 때 틀리면 그것은 온전히 연습이 부족한 나의 잘못이었다

근데 기타는 이제 막 처음 시작 한 사람으로서,

바쁜 일상 속에 짬을 내 연습을 열심히 해가도

합주 때 다른 악기 소리에 맞춰 내 스트로크를 치는 게 헷갈려서 자꾸 놓치게 되고,

제대로 나지 않는 내 기타 소리에 합주가 망가지는 것 같아서 너무 속상하고 무력감을 느꼈다

난 원래 노력하면 다 된다! 주의였는데... 음악이란 영역은..아닐지도...?

당장 연습한다고 바로 해결되지 않는 문제란 것에 더 답답했던 것 같다

근데 내 이런 고민을 들은 친구들의 대답은 매우 명쾌 그 잡채

완벽한 합주 원했으면 우리 밴드 안 했어~~ 우리도 다 틀려~~

글쿤..ㅎㅎ... 혼자 처음하는 악기라고 너무 부담을 떠안았던 느낌 ㅎ^ㅎ...

녹음본을 들어보니 정말 나만 틀리는 게 아니잖아 하하하

우리 원래 엉망진창 밴드잖아~ 우린 이게 맞아~

틀리면 어때~ 다른 애들도 틀리는데! 아직 난 좀 많이 틀릴 뿐!

2023년엔 꼭 한 곡이라도 완벽하게 합주해서,

야외에서 공연 한번 해보는 게 목표다 (이런 밴드라도.. 많이 보러 와줘 ..)

2023년 목표는 간단하게

- 개발 공부는 개짱 열심히

- 블로그 부흥 시키기

- 로스트아크 OST 피아노 연습하기

- 밴드 야외 공연 한 곡 하기

- 롤 자유랭 다이아 도전하기

- Wind Song 통기타 마스터하기

- 동영상 편집 공부해서 브이로그 만들어보기

- 두려워 하지 말고 도전해보기

아.. 내가 최근에 갓오브워란 게임에 빠졌는데 ...

아 물론 하진 않고 스토리 영상만 다봤다 진짜 영화 대작 하나 본 기분..

앞으로 내 좌우명은

We Must Be Better

우리는 더 나아져야만 해

하루하루 더 나아지는 사람이 되기가 최종목표

(아트레우스는 북유럽 금쪽이.. ㅡㅡ)

뭐.. 거의 책을 한 권 낸 건가...?

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

오랜만의 TMI라 말이 참 길어진 것 같다!!

2022년 수고 많았고,

제 블로그에 들러주신 모든 분들 감사드립니다 :)

2023년도 화이팅 입니다.

RxSwift) RxSwift가 도대체 뭔데요(Reactive Programming)

소들이 — Wed, 30 Nov 2022 20:57:44 +0900

안녕하세요!! 소들입니다 :>

저는 Let's Swift 티케팅에 낙제하고

퇴근 후 포스팅이나 쓰는 사람입니다 ㅋㅋ;;;;;

아쉬움은 뒤로하고

RxSwift의 드디어 첫 걸음마 포스팅을 써보려고 합니다

RxSwift... 어찌보면 꽤 예전부터 대세였잖아요?

누군가는 정말 필요함을 느껴서 공부를 할 수도 있고,

누군가는 대세에 뒤쳐지기 싫다는 생각으로 공부할 수도 있고,

누군가는 면접에서 써먹기 위해 억지로 공부 할 수도 있고,

공부의 이유야 어찌 됐건 그게 뭐가 중요합니까

안 하는 사람보단 100배 낫지

사실 저는 억지로 공부했던 것 같아요ㅎ;;

RxSwift가 대세래! 모르면 간첩이래!

하하하 이 글을 보는 당신은 간첩 하하하!

농담이고 쨌든 최대한 이해하기 쉽게 풀어쓰려고 노력 해볼게요!

다만, 저도 아직 배워야 할 게 너무 많은 사람으로서

틀리거나 의아한 부분이 당연히 있을 수 있습니다(RxSwift에 한해서 더 그럴 수 있음)

따라서 잘못된 내용이나 피드백은 언제나 댓글 바랍니다 :)

그럼 이제 공부하러 가봅시다!

모든 포스팅은 편의 말투로 합니다~!!

+ 참고로 초안입니다! 부족하다 생각하여 계속 수정하고 수정될 포스팅입니당

처음 내용은 매우 부실할 수 있음

1. RxSwift를 어거지로라도 이해해봅시다

움.. 나는 뭐랄까...

RxSwift를 공부한다? -> RxSwift가 도대체 머하는 놈인데?를 먼저 알아야 하는데

처음 RxSwift를 검색했눈데.. 거의 대부분의 글에선 갑자기..

태초에 Observable, Subscribe가 있었다...

그리고 갑자기 등장하는 operator 대잔치...;;

아니 그래서 RxSwift가 당장 뭔데요..? 싶었음..

그래서 내 포스팅에선 간단하게 서론부터 RxSwift가 뭔지부터 시작할 것임!

휴먼 소들체로 작성할테니 물흐르듯 읽어주시면 감사

여러분 RxSwift의 뜻이 뭐인 것 같음??

RxSwift의 약자는 바로바로

Reactive Extension + Swift

임!! 또한

RxSwift를 검색해보면, RxSwift Github에선

Reactive Programming in Swift

라고 나와 있음!

공통적으로 들어있는 Reactive와 Swift라는 단어.. 호옹이..

자, Reactive라는 것은 "반응"과 관련된 단어잖음??

그럼 우린 저 설명만 보고 그냥

RxSwift는 뭐.. Swift에.. 반응 같은 것을.. 끼얹었나?

라고.. 생각.. 해보면 될듯..???

그래서.. 그.. 반응이란 것이 도대체.. 뭔데...?

여러분, 혹시 반응형 프로그래밍이라는 것에 대해 들어보지 않았음??

자, 우리는 지금까지 OO프로그래밍에 대해 익히 들은 것들이 있잖음??

예를 들면

객체지향 프로그래밍

함수형 프로그래밍

과 같이!!

반응형 프로그래밍이란 것은 사실 거대한 것이 아니라

그냥 어떤 프로그래밍에 있어 하나의 패러다임이라고 생각하면 됨!

그럼 우린 이렇게 생각해볼 수 있는 것임

RxSwift라는 것은

Swift를 반응형 프로그래밍 하는 것이겠구나!

웅!

그래서 반응형 프로그래밍이 도대체 먼데!

1-1. 반응형 프로그래밍

반응형 프로그래밍(Reactive Programming)이란,

데이터의 흐름 및 변경사항을 전파하는 데 중점을 둔 프로그래밍 패러다임입니다

이 패러다임을 사용할 경우, 주변환경/데이터에 변화가 생길 때

연결된 실행 모델들이 이 이벤트를 받아 동작하도록 설계하는 방식입니다

.. ? 학생,, 글 내려,,^^

이게 먼 소린가 싶잖음??

"데이터의 흐름 및 변경사항"을 "전파" 하는 데 중점을 뒀다라..

만약 변경사항이 일어났을 경우, 연결된 "실행 모델"들이 이 "이벤트를 받는다"라..

ㅋ..

좀 더 쉽게 이해 해봅시다 XD

var a = 10
var b = 20
 
var sum = a + b
sum              // 30

자 위와 같은 코드는 우리가 일반적으로 작성하던 코드잖음??

위에서 sum이란 변수엔 당연히 30이 들어가 있음!!

자, 근데 다음과 같이 만약 a라는 변수의 값이

어느 순간 단순 변심에 의해 갑자기 바꼈음

a = 20
sum              // 30

위처럼 20으로 바뀌어 버린 것임..

근데 우리가 평소 하던 일반적인 프로그래밍일 경우,

sum의 타입은 Int 타입이고, 대입할 당시의 a의 값을 복사 했고,

우리는 sum에 a가 바꼈다고 어떠한 작업을 해주지 않았기 때문에,

sum이 a+b였긴 하지만, a의 값이 바뀌었다고 해서 sum의 값이 바뀌진 않음

자, 근데 반응형 프로그래밍에선 말이죠..

a = 20
sum              // 40

ㅇㅖ..?? 싶겠지만, a값을 20으로 바꾸면,

a가 바뀐 이후 우리가 어떠한 작업을 추가적으로 해주지 않아도,

sum의 값이 바뀌어야 함..!

이게 어떠케 가능한 일이죠..? 싶잖음?

근데 앞서 반응형 프로그래밍이 뭐라고 했음?

데이터의 흐름 및 변경사항을 "전파" 하는 데 중점을 뒀다고!

만약 변경사항이 일어났을 경우, 연결된 "실행 모델"들이 이 이벤트를 받는다고!

지금 a라는 데이터의 흐름이 기존 10에서 20으로 변경됐을 때

이 변경사항에 대해서 a와 연결되어 있는 sum(실행 모델)이 이벤트를 "전파"받아서

어떠한 동작(값 갱신)을 할 수 있는 것

이것이 바로 반응형 프로그래밍인 것임(ㅋ)!!!!

자, 그러면 이제 어떤 생각이 드나면

아 그럼 sum, 즉 실행 모델이란 놈은,

a의 값이 바뀌는지 안 바뀌는지에 대해서 "관찰"을 하고 있어야겠네요!!??

또한! 그러고 a의 값이 바뀌었을 때 관찰 중인 sum에게 이를 전파 해야 겠네요..?

그리고 해당 이벤트를 전파 받았을 때 어떤 일을 하지 sum에서 정하면 되겠네요..!!??

맞음!!! 이게 어떻게 가능 하냐구..?

이게 가능하게 해주는 것이 바로 !!!

우리가 앞으로 공부할 RxSwift의 Observable, Obsever, Operater임!!!

(물론 지금은 공부하지 않을 것이니 응 관심없ㅇ ㅓ하셈)

당장 위 예제는 a라는 단순한 Int 변수 값이라 이해가 안 갈 수 있는데,

만약 다음과 같이 프로그래밍을 하다보면 자주 사용되는 이벤트들을 생각해보셈

버튼이 눌렸을 때

키보드가 올라 왔을 때

언제 일어날지 모르는 어떤 이벤트가 발생 했을 때

위 이벤트들의 공통점이 뭐임?? 비동기적인 이벤트들이다!

언제 유저가 버튼을 누르고 키보드를 띄우고 할지 등등을 프로그래머인 우린 알 수 없잖음!!

다만,

유저의 "반응"이 비동기적으로 왔을 때,

즉 어떤 데이터의 흐름이 바뀌었을 때,

즉 처음 예제에서 a의 값이 언제 어디선가 변경 되었을 때

이 반응에 대해 관찰을 하는 놈이(sum) 있다면,

변화가 일어났을 때 이 관찰하던 놈은 이 변화에 대해 전파를 받을 수 있고,

따라서 변화에 대한 어떤 동작을 진행할 수 있는 거구나

가 사실 .. 바로.. . 반응형프로그래밍인 것...!!

이런 이벤트들로 생각을 했을 때 보통 어떤 생각이 드냐면..

음.. 이거 Swift의

Notification

Delegate Pattern

Closure

등등 으로도 충분히 구현할 수 있지 않나요?..ㅎㅎ 물논.. 당근.. ㅎㅎ

당연하잖음? 만약 반응형 프로그래밍 없이 못하는 거였다면

RxSwift는 대세가 아니라 필수가 되었을 거잖음

근데 충분히 Swift로도 가능하지만,

기존 프로그래밍 방법들로 했을 때의 발생할 수 있는 한계점

(쓰레드 넘나들기, 비동기 코드 처리로 인한 코드 뎁스 깊어지기 등)

을 해결해줄 수 있는 것이 Reactive Programming이자 즉 RxSwift임 ㅎ_ㅎ

이건 나중에 RxSwift를 썼을 때의 예시 코드를 보며 같이 이해 해볼 것임..!

+ 또한 Reactive Rrogramming에서의

선언적 프로그래밍 / 함수형 프로그래밍과 관련된 내용은

Rx를 조금 더 다룬 후에 하겠습니다!

아 뭐 그래~ 지금은 그냥~

반응형 프로그래밍이 대충 뭔지 알았어~

어떤 비동기 이벤트가 있을 때! 그것을 관찰하는 놈이 존재하고~

만약 이벤트가 발생한다면, 관찰하는 놈은 해당 이벤트(데이터 흐름 변경)에 대해 전파 받을 수 있고

따라서 그에 따른 어떤 작업을 할 수 있다는 거구나~

이는 Swift로도 충분히 가능하지만~ RxSwift를 쓰면 뭔가 좀 더 좋은가보구나~

정도만 알 것임!!

그리고 그것이 어떻게 가능하게 해주는지는

앞으로 RxSwift의 Observable과 Observer, 다양한 Operator 들을 통해 배우면 되는구나 ~.~

1-2. RxSwift 정의 다시 봐보기

RxSwift는 비동기 프로그래밍을

관찰 가능한 순차적 형태와 함수 형태의 연산자를 통해 처리하게끔 도와줍니다

위 내용을 다 보고 왔다면,

아하 RxSwift는 반응형 프로그래밍이기 때문에

어떤 비동기 이벤트에 대해 관찰 가능한 형태로 만들고

함수 형태의 연산자를 통해 이 비동기 이벤트의 변화에 따른 전파를 받을 수 있고

또한 여러 연산을 처리할 수 있게 한는 거구나

라고 정도만 이해하면 될 것 같음 ㅎ_ㅎ..

왜냐?? 실제로 예제를 보다 보면

위 이론이 그냥 말로 해서 어렵구나~~ 이런 내용이었구나~를 이해할 수 있기 때문에!!

다음편에선 그럼 도대체

비동기 이벤트를 어떻게 관찰 가능한 형태로 만든단 건데!

그리고 어떻게 이 이벤트에 대한 변화를 전파 받는건데!

를 알아보도록 하겠습니다 :)

참고로 제가 쓰면서도 엥.. 음 .. 어..? 싶은 부분이 있어서

계속 수정해나갈 예정이니,

지금 완전한 초고을 읽으셨다면 유감

잘못된 부분이 있다면 언제든 피드백 주세요!!!

출처 :

https://admd13.tistory.com/211

https://velog.io/@myoungsubsim/%EB%B0%98%EC%9D%91%ED%98%95-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

Swift) Protocol 이해하기 (6/6) - Protocol에 선언된 메서드는 기본값을 가질 수 없나요?

소들이 — Thu, 24 Nov 2022 19:32:14 +0900

안녕하세요! 소들입니다

저... 저... 블로그 새단장 했어요!!!!!! 너무 귀엽지 않아요???ㅠㅠ

진짜 ㅠㅠㅠㅠ세상에.. ㅁ내 블로그가 세젤귀야....ㅠㅠㅠ

근데 이번 포스팅에선요

되게 간단하지만, 알아두면 좋고

또 생각할 거리도 있는 주제에 대해 다루려고 합니다!

바로 Protocol에 선언된 메서드의 파라미터는 기본 값을 가질 수 있는가! 없는가!

'에 대한 것입니다!

또한 associatedtype이 포함 되었을 떄의 경우도 볼 거예요!

생각보다 모르고계시는 분들이 많답니다... :)

그럼 공부하러 고고싱!!!

모든 포스팅은 편의 말투로 합니다~!!

1. Protocol에 선언된 메서드는 기본값을 가질 수 없습니다

정답을 ㅂㅏ로 써버리기

다음과 같이 프로토콜에 선언된 메서드에 기본값을 주려고 하면,

protocol SodeulRepository {
    func fetchData(url: String = "www.sodeul.com")    // error! Default argument not permitted in a protocol method
}

 

위처럼

Dafault argument not permitted

(기본 값 허용하지 않셈)

라는 에러가 뜸!!

ㄴㅔ.. 맞습니다..

프로토콜에 선언하는 메서드는 기본적으로 기본값을 가질 수 없음

그럼 기본 값을 못.. 쓰나..?

아....뉘 ..? 우리에겐..

extension

이 있잖아....! 허걱!

2. 기본값을 가지고 싶을 경우, extension을 통해 기본 메서드를 구현해주면 됩니당

protocol SodeulRepository {
    func fetchData(url: String)
}
 
extension SodeulRepository {
    func fetchData(url: String = "www.sodeul.com") {
        print("sodeul blog dog cute")
    }
}
 
 

이렇게 선언부는 그냥 그대로 냅두고,

extension을 통해서 파라미터의 기본값을 지니게 할 수 있음!!

그럼 이렇게 실제 사용할 때

프로토콜에 기본값을 가진 메서드처럼 사용할 수 있음!!!

3. 프로토콜이 associatedtype을 가지고, 파라미터 타입이 이 제네릭 타입일 경우엔 기본값을 가질 수 없습니당

이게 살짝 생각해볼 만한 포인트인데,

우리가 전 포스팅에서 배운 Protocol에서 제네릭을 사용하기 위해 다음과 같이

protocol Stack {
    associatedtype value
    
    func push(value: value)
}

이렇게 위처럼 associatedtype을 선언해 줬음!!

근데 어라라 나 제네릭 파라미터인 value에 기본값 주고싶은데!!!! 해서

extension을 통해 제네릭 파라미터인 value에 기본 값을 줘버리면

extension Stack {
    func push(value: value = 1) {    // Generic parameter 'Self' could not be inferred
        ...
    }
}
 

이렇게

Generic parameter 'Self' could not be inferred

(제네릭 파라미터 'Self가 유추가 안 되셈)

하고 에러가 뜸!!

음.. 어찌보면 당연한 것??이라고 생각함

제네릭을 사용하는 이유가 뭐임??

바로 타입에 대한 제한을 주지 않기 위해서잖음!?!? 말 그대로 "범용 타입"!

근데 위처럼 extension을 통해 제네릭 파라미터인 value의 타입을

1 즉, Int로 제한시켜 버리면,,

이건 뭐... value란 associatedtype을 Int로 사용할 녀석들만..

저 메서드 확장이 가능한 건가..?

싶잖음??

안도 ㅣ면 가능하게 하라...

assosicatedtype 파라미터에 기본값을 주기 위해선

associatedtype 타입이 기본값으로 1이란 값을 가질 수 있게

associatedtype 타입 자체에 BinaryInteger 프로토콜을 채택하고 있어야 한다는

제약을 다음과 같이 주거나,

protocol Stack {
    associatedtype value: BinaryInteger
    
    func push(value: value)
}

extension Stack {
    func push(value: value = 1) {   
        ...
    }
}

또는

value라는 associatedtype이 BInaryInteger를 채택하고 있을 경우만

extension이 가능하게 제한을 두어도 됨

extension Stack where value: BinaryInteger {
    func push(value: value = 1) {    
        ...
    }
}
 

위처럼!!

위 두 가지 방식을 사용했을 경우,

더이상 기본값을 1로 가지는 push 메서드에 에러는 나지 않음!!

위 두 방법의 차이점이라고 하면,

associatedtype 자체에 BinaryInteger를 채택하고 있어야 한다는 제약을 줄 경우,

struct HStack: Stack {          // error! Type 'HStack' does not conform to protocol 'Stack'
   typealias value = Double
}
 

위처럼 value 자체가 BinaryInteger를 무조건 채택하는 타입만 선언이 가능하기 때문에

BinatyInteger 프로토콜을 따르지 않는 associatedtype은(Double) 사용 할 수 없음!

근데,

where 구문을 통해 확장에 제한을 둔 경우라면,

struct HStack: Stack {         
   typealias value = Double
   func push(value: value) {    
       ...
   }
}
 

확장에만 제한이 걸리는 것이기 때문에,

associatedtype 자체엔 제약이 없지만 BinaryInteger를 채택하지 않은 Double의 경우,

extension에 구현된 기본 메서드를 제공받을 수 없어

이땐 해당 메서드를 직접 구현해줘야 함!(그러면 사용 가능!)

움.. 근데 associatedtype 자체에 제한을 두는 것보다

where을 통해 조건부 확장을 하는 게 좀 더 낫나..?

모르겠다 ㅎ

+ 또 다른 방법으론 이전 포스팅에서 배웠듯,

제네릭 메서드를 사용하셔도 됨니당

protocol Stack {
    func push<T: Equatable>(value: T)
}
 
extension Stack {
    func push<T: Equatable>(value: T = 1) {}
}
 

이렇게!

프로토콜에서 단일 메서드에서만 제네릭 타입을 사용해야 할 경우엔

위처럼 제네릭 메서드를 사용하는 것도 나쁘지 않다고..?........ 봅니당

음.. 프로토콜에 대해 더 할말이 있는데

이정도에서 끝내구! 나중에 추가할 일 있으면 더 추가하겠습니당 :)

같이 프로토콜 포스팅을 달리신 분이라면 고생하셨습니다!!

만약 잘못된 내용이나 오타 및 피드백은 댓글 주세용!!

그럼 마지막으로 ..

넘나 .. 기여운 내블로그 화이팅.. ㅎ

Swift) Protocol 이해하기 (5/6) - associatedtype :: Protocol의 Generic

소들이 — Tue, 22 Nov 2022 20:23:50 +0900

안녕하세요! 블로그를 새단장한 소들입니다!!!

앞으론 제 글 마다 위 로고가 보일테니 참아주세요 하하하!!

이번 포스팅은 Protocol의 associatedtype에 대해 알아볼 거예요!!

혹시 범용 타입인 Generic을 잘 모르신다면 이 포스팅을 먼저 보고 와주세용!!

Generic을 안다는 가정 하에 포스팅을 진행할 거예용

이번 포스팅에선 Protocol에서 Generic을 사용하는 방법에 대해 알아볼 거예요!

내용이 간단하나 처음에는 좀 헷갈리고 어려울 수도 있습니당!

모든 포스팅은 편의 말투로 합니다~!!

1. 기존 Generic을 사용할 떈 말이죠

먼저 여러분 제네릭에 대해 간단하게 다시 짚고 가자몀

제네릭은 머다??

제네릭이란 타입에 의존하지 않는 범용 코드를 작성할 때 사용한다

제네릭을 사용하면 중복을 피하고, 코드를 유연하게 작성할 수 있다

코드의 중복을 줄이기 위해 사용하는 게 범용 ㅌ ㅏ입이다!!!

따라서 다음과 같이 구조체(or 클래스 or 메서드 등)에서 제네릭을 사용하고 싶으면

struct Stack<T: Equatable> {
    func push(value: T) { }
    func pop() -> T { ... }
}

이런 식으로 타입 네임 옆에 <>와 타입 파라미터(Type Parameter)인 T를 이용해서 작성 했잖음??

물론 위처럼 어떠한 제약을 줄 수도 있었음

(T의 타입은 Equatable을 준수하고 있어야 한다는!)

그리고 실제 내부에서 이게 당장은 무슨 타입인진 모르지만,

범용 타입 파라미터인 T를 사용해서 개발하면 됐었음!!!

근데 그럼 만약 프로토콜에서도 제네릭을 사용하고 싶음!!!

그러면 위처럼 똑같이 <>와 타입 파라미터를 이용해서 선언해주면 될까?

protocol Stack<T: Equatable> {         // error! An associated type named 'T' must be declared in the protocol 'Stack' or a protocol it inherits
    func push(value: T)
    func pop() -> T
}

안~ 대~ 용~

Protocol에서 위처럼 Generic을 사용하고 싶다면 associatedtype이란 것을 사용해야 함!!

2. associatedtype : Protocol에서 Generic을 사용하는 방법

Protocol에서 Generic을 사용하고 싶을 경우,

이때는 associatedtype이란 것을 사용하면 됨!!

protocol Stack {
    associatedtype value
    
    func push(value: value)
    func pop() -> value
}

이렇게 프로톹콜 내부에 associatedtype을 쓰고

protocol 내부에서 사용할 범용 타입의 이름을 선언해주면 됨!!!

그러면 기존에 사용했던 방식처럼,

value라는 이름으로 범용 타입으로 사용할 수 있음!!!

만약, 타입에 제한을 주고 싶다면 당연히,

protocol Stack {
    associatedtype value: Equatable
    
    func push(value: value)
    func pop() -> value
}

이렇게 제약 주는 것도 가능함!! :)

3. 채택하는 곳에서 associatedtype이 선언된 제네릭 프로토콜을 쓸 때면..

제네릭의 경우, 실제 사용하는 곳에서 타입이 정해진다는 게 특징이잖음?

따라서 이 associatedtype이 선언된 제네릭 프로토콜의 경우,

실제 이 프로토콜을 채택하는 곳에서

struct VStack: Stack {
    typealias value = Int
    
    func push(value: value) { }
    func pop() -> value { ... }
}

이렇게 typealias를 이용해서,

associatedtype을 나는 이런 이런 타입으로 사용할 것이야! 하고 명시해주는 게 일반적임!!!

근데 만약, 아래와 같이

struct VStack: Stack {
    func push(value: Int) { }
    func pop() -> Int { ... }
}

typealias 없이도 어떤 타입인지 위처럼 충분히 추론이 가능할 경우,

이때는 typealias를 생략해도 됨!!!

(보통은 위처럼 추론이 가능하게끔 하고, typealias는 생략한다구 함)

4. 놀랍게도! protocol에 기존 방식으로 제네릭 함수를 선언할 수 있습니당!

protocol Stack {
    func push<T: Equatable>(value: T)
}
 

associatedtype 때문에 기존 제네릭을 아예 사용 못하는 것 같아 보이지만,

이렇게 메서드를 선언할 때는 제네릭을 사용하는 것이 가능함!!

망했다 분량조절 대실패다(챕터 나누기 땜시..)

5편에서 7편으로 늘어날 예정^^;;;;

오늘은 Protocol에서의 Generic에 대해 알아봤습니당....

잘못된 내용이나 오타 및 피드백은 댓글로 주세요!! 대환영입니다!!

개발자 소들이 프로필 완성

소들이 — Tue, 22 Nov 2022 18:42:22 +0900

안녕하세요 소들입니다 XD

오늘 갑자기 뜬금없이

제 개발자 프로필? 로고?를 만들어보고 싶더라구요!?!?!

그래서 만들었습니다!!

미친 거 아냐?ㅠㅠㅠ 미쳤냐구ㅠㅠㅠ 너무귀엽잖아ㅠㅠㅠㅠ

참고로 저 위에 웰시코기의 출처는요!!!! 여기랍니다!!!!

무려 구매한 겁니다!!!!! 막 갖다 쓴 거 아님!!!!

사실 저 코기 한 마리에 12달러래서 고민하고 질렀는데

환율 때매 16,000원이 긁힌 슬픈 전설이 있어..

내 카카오 뱅크는 이 사건을 기억할 거야..

구매하여 다운로드 했고, 이용 예에 블로그 포스트가 있으니

더이상의 저작권 문제는 없겠지 뭐 하하하

만약 그 누군가... 문제가 있어 보인다면 말해주삼..

사실 킹받는 잼민이 컨셉으로

꽃달고 만들었었는데요

12,000원(x) 16,628원(o)

저작권을 피해가라는 다른 팀원들의 격려어린 그림들

ㅎ..ㅎ;;

그럼 전이만 다시 글 쓰러 안녕!

앞으로 저 로고가 매번 보여도 거슬려도 봐줘요!

돈주고 비싸게 산거니께!!!

Swift) Protocol 이해하기 (4/6) - Protocol Extension

소들이 — Tue, 15 Nov 2022 19:34:32 +0900

안녕하세요, 소들입니다 XD

프로토콜 포스팅이 훔 .. 생각보다 한두편 정도 더 늘어날 수도 있겠더라구요

내용이 왤케 많고 난리임

쨌든 이번 포스팅에선 Protocol Extension(프로토콜의 확장)!에 대해서 공부해볼 거예요

이 프로토콜의 확장은 생각보다 자주 쓰이는 문법이랍니다!

그럼 공부하러 가봅시다 :)

모든 포스팅은 편의 말투로 합니다~!!

1. 상속 대신 프로토콜을 사용할 때의 불편함을 느낀다면,,

여러분

우리가 만약 늘 등장하는 Band라는 프로토콜을 만들었음

protocol Band {
    func play()
}

밴드라면 당연히 연주는 해야지! 하고 play라는 메서드를 프로토콜에 정의 했음

그리고 다음과 같이 ABand, BBand, CBand 구조체가 모두 Band는 프로토콜을 채택 함

struct ABand: Band {
    func play() {
        print("play!")
    }
}
 
struct BBand: Band {
    func play() {
        print("play!")
    }
}
 
struct CBand: Band {
    func play() {
        print("play!")
    }
}

세 구조체 모두 Band 프로토콜과의 약속을 지키기 위해

play란 메서드를 각자 구현 했음

근데!!! 아닛 구현해놓고보니!!

모두 공통적으로 play 메서드를 동일하게 구현하고 있음

한 마디로 Band에서 정의한 play라는 메서드는

특별한 일이 없는 한..! 기본적으로

print("play!")

를 실행 하는 메서드였떤 것임..!

아니 근데 그러면..

저 똑같은 메서드를 Band를 채택하는 프로토콜마다 다 구현해줘야 하나요!?!?!

이런이런,, 비효율적인걸..

만약.. 클래스라면..! 상속이 된다면..!

부모 클래스에서 정의하고 자식 클래스는 별도로 정의 없이 갖다 쓰기만 하면 되는데..

괜히 프로토콜로 구현해서 모든 클래스마다

공통된 기능을 다 구현해야 하잖아여!!

라고 생각할 수 있잖음?

근데 프로토콜이 뭐 빙다리 핫바지도 아니고

Swift에서 클래스보다 프로토콜이 훨씬 중요도가 높은 만큼

당연히 기본 기능의 메서드를 프로토콜도 지원할 수 있음!!

어떻게?

extension! 확장!을 통해!!

2. 확장을 통해 프로토콜 메서드의 기본 구현을 제공하세요

위에서 기본적으로 play란 메서드의 기본 기능이 채택하는 곳마다 같았잖음?

이처럼 프로토콜에서 기본적으로 구현을 제공해주고 싶을 경우,

extension을 통해서 제공할 수 있음

protocol Band {
    func play()
}
 
extension Band {
    func play() {
        print("play!")
    }
}

이렇게 프로토콜에 extension을 해주고,

기본적으로 제공하고 싶은 기능(메서드)를 직접 위처럼 extension 내부에 구현 해줘버리는 것임

이렇게 할 경우,

해당 Protocol을 채택한 곳에서 직접 play()라는 메서드를 더이상 구현하지 않아도 됨

왜냐?? 만약 구현하지 않을 경우,

extension에 미리 구현된 play()가 불리게 되그등요!!!

struct ABand: Band { }
 
ABand().play()                  // "play!"

이렇게!!

ABand 구조체는 Band를 채택했지만, play() 메서드를 ABand에서 직접 구현하지 않아도 됨

대신 이땐, play() 메서드를 호출할 경우 extension에 구현된 play()가 호출 됨!!

에에 근데 저는요

기본으로 제공하는 메서드 사용 안 하고, 제가 직접 play()를 구현 하고 싶은데요??

하면, 기존처럼 그냥 구현해주면 됨

struct BBand: Band {
    func play() {
        print("BBand play!")
    }
}

BBand().play()                  // "BBand play!"

이렇게 직접 구현할 경우,

extension에 구현된 기본 제공되는 play()보다, 직접 구현한 play()의 우선순위가 높기 때문에

내 클래스/구조체/열거형 안에 직접 구현한 놈으로 불린답니다!!

+ 또한 where을 통해서 기본 메서드를 제공하는 것에 제한을 둘 수도 있음!

protocol Human { }
protocol Band {
    func play()
}
 
extension Band where Self: Human {
    func play() {
        print("play!")
    }
}
 

위처럼 where을 통해서 제한을 둘 경우,

Human 클래스를 채택하고 있는 경우에만 확장을 제공하겠다! 라는 뜻이 되고,

따라서,

struct ABand: Band { }
ABand().play()                  // X! Type 'ABand' does not conform to protocol 'Band'
 
struct BBand: Human, Band { }
BBand().play()                  // O! "play!"
 

이렇게

Human 프로토콜을 채택하지 않은 ABand의 경우 extension에 구현된 기본 메서드가 제공되지 않기 때문에,

ABand는 play() 메서드를 구현하라!!!!! 하고 에러가 뜨는 것이고,

Human 프로토콜을 채택하고 있는 BBand의 경우 extension에 구현된 기본 메서드가 제공되기 때문에,

BBand는 play()메서드를 구현하지 않아도 기본 메서드를 사용할 수 있음

3. 메서드만 확장 되나요? 프로퍼티도 기본 값 extension으로 주면 안 되나요?

extension의 경우, 프로퍼티를 추가하고 싶다면 연산 프로퍼티만 가능 하자나요??

그렇다면 extension을 통해 프로토콜에 선언된 프로퍼티를

연산 프로퍼티로 구현해서 기본값을 지니게 해놓으면 안되나요??

라고 생각 해서 해봤는데

protocol Band {
    var piano: String { get }
}
 
extension Band {
    var piano: String {
        return "sodeul"
    }
}
 
struct ABand: Band {}             
 
 

잘 되네염ㅎㅎㅎㅎ!!!!!!11

바보같이 get set 해놓고 getter만 구현해놔서 안 되는 줄 알았는데!

형식만 잘 지켜주면 프로퍼티도 잘 적용 된답니다!!! :)

extension에서 프로퍼티를 추가할 땐 연산 프로퍼티만 가능하단 점만 잘 유의해두시면 될듯 합니당!!

프로토콜의 확장에 대해 포스팅 끝~_~!!!!

음... 한두편 늘어날 것 같군 허허

잘못된 내용이나 오타 및 궁금증은 언제나 댓글 주세용~~!

Swift) Protocol 이해하기 (3/6) - 프로토콜도 1급 객체다!

소들이 — Mon, 31 Oct 2022 20:53:48 +0900

안녕하세요 :) 소들입니다

프로토콜도 얼른 끝내버리기 위해 돌아왔다고 할 수 있습니다

프로토콜 글이 여태껏 제가 쓴 글 중 조회수가 제일 빠르게 오르더라구요..?

다들 프로토콜 덕후인듯.. 사실 나는 덕후 맞음..

Swift는 프로토콜 지향 프로그래밍이잖아여??

그래서 저는 요즘 코드를 짤 때 프로토콜 지향적으로 짜기 위해 매우 노력하는데..

늘 이 코드가 최선일까!?!에 대해 괴로워 하는 일개미 개발자..랄까 ..

쨌든 이번 포스팅에서는!

1급 객체로서의 프로토콜에 대해 공부해보겠습니다!!

쉬운 내용이니, 한번 공부하고 머릿속에 꼭 기억해두시길 바라겠습니다!

모든 포스팅은 편의 말투로 합니다~!!

1. 1급 객체로서의 프로토콜

먼저.. 1급 객체가 무엇이냐 묻는다면..

1급 객체 함수를 다룰 때 등장했으나!!!

언젠가의 포스팅이 보러가기 귀찮은 분들을 위해 대충 정리 해보겠음

일급 객체의 조건은 뭐 객체가 런타임에도 생성되어야 하고,

파라미터로 객체를 전달할 수 있고, 반환 값으로 객체를 사용할 수 있고 등등 있는데,

그중 프로토콜이 일급 객체가 되기 위해선 다음과 같은 조건들을 만족해야함

변수/상수의 타입이 프로토콜이 될 수 있어야 하고,

함수의 파라미터 타입과 반환 타입으로 프로토콜이 될 수 있어야 한다

고로,

어떠한 객체(object)가 독립적인 하나의 타입으로 사용될 수 있다면 이 객체는 1급 객체임!!

Swift에선 함수, 클로저, 프로토콜이 바로 1급 객체임

자 이제 1급 객체에 대해서 좀 이해를 했다면!!

아항 프로토콜은 독립적인 하나의 타입으로 볼 수 있구나!!!를 이해 했다면!!

사실 포스팅 끝ㅋ

이나.. 실제로 예를 통해 봅시다..

protocol Band {
    var piano: String { get }
}

위와 같은 프로토콜이 있다고 가정해보자!!

1-1. 프로토콜 타입을 변수/상수 타입으로 선언할 수 있다

let beatles: Band

위처럼 beatles란 변수의 타입으로, 프로토콜을 선언할 수 있다는 말임!!!

근데 여기서 이제 프로토콜 초보들은 말이여..

헷갈리기 시작할 것임

아닣..

근데 그러면.. 프로토콜을 변수의 타입으로 선언하면..

프로토콜은 구조체도 클래스도 열거형도 아니라 인스턴스 생성도 못하는데요..

프로토콜은.. 야레야레.. 약간 ... 추상적.. 이랄까..?

선언부만 가진 놈 아닌가요..?

실제 구현은 프로토콜을 채택하는 구조체/클래스/열거형에서 한다면서..

그럼 위처럼 변수 타입을 프로토콜로 설정해버린 경우는 어떻게 객체를 생성하죠..?

싶을 수 있잖음!!

맞음!! 프로토콜은 클래스도, 구조체, 열거형도 아니기 때문에 해당 프로토콜의 인스턴스를 생성한단 것은 말이 안 됨

따라서 위처럼, 프로토콜을 타입으로 쓴다는 말은,

해당 프로토콜을 채택한 구조체/클래스/열거형의 인스턴스를

프로토콜로 타입 캐스팅을 해서 사용하겠다!

라는 말이라고 보면 됨!!

자, 만약 아래와 같이 Band라는 프로토콜을 채택하는

struct Beatles: Band {
    var piano: String = "sodeul"
    var bandName: String = "Beatles"
}
 

Beatles라는 구조체가 있음

이 Beatles는 Band라는 프로토콜을 채택했기 때문에,

반드시 구현해줘야 하는 piano란 프로퍼티를 위와 같이 선언하고,

내 내부에서 사용하고 싶은 bandName이란 프로퍼티또한 별도로 선언 했음!!

그러면!!!

let beatles: Band = Beatles.init()

이렇게 1급 객체 특징에 의해 Band라는 상수의 타입으로 프로토콜을 선언했을 때,

이 Beatles의 인스턴스를 이 프로토콜 타입을 가진 변수 beatles에 대입할 수 있다는 것임

어떻게 이게 가능하냐구?

Beatles라는 구조체 인스턴스를, 프로토콜 타입으로 "타입 캐스팅" 해버리기 때문에 가능한 거임!!

(타입 캐스팅이 어려운 스린이는 이 글을 먼저 봐주세요!)

따라서, 이때 beatles는

Beatles란 구조체의 인스턴스를 생성해서 대입해 줬지만,

타입 자체가 Beatles란 구조체 타입이 아닌, Band라는 프로토콜 타입이기 때문에

프로토콜에 선언되어 있는 piano라는 프로퍼티엔 접근할 수 있지만,

Beatles 구조체에 선언해줬던 bandName이란 프로퍼티엔 접근 할 수 없음!

타입 캐스팅을 알고 있다면, 어렵지 않을 것 :)

물론, 타입 캐스팅이기 때문에

만약에 Band란 프로토콜을 채택하지 않다면

as로 동작하는 위 코드의 경우

(아무 프로토콜도 채택하지 않은 BBand의 인스턴스를 캐스팅 함)

BBand는 Band를 따르지 않는다며 컴파일 에러가 발생하지만,

만약, as?나 as!를 써서 런타임까지 가게 될 경우,

as?로 캐스팅 할 경우엔 해당 상수는 nil로 떨어지고,

as!로 캐스팅 할 경우엔 크래쉬가 발생한답니당..!!

참고로, 위처럼 프로토콜로 타입 캐스팅된 인스턴스를

다시 기존 타입으로 캐스팅할 경우엔, 무조건 as?, as! 만 가능하답니다 XD

프로토콜의 경우, 기존 인스턴스가 어떤 타입인지에 대해선 전혀 1도 관심 없고

너 이 프로토콜 채택했으니 이 약속은 지켰겠지? 이 프로퍼티, 메서드는 당연히 갖고 있겠지?

하고 그 프로토콜에 선언된 놈들만 쓰기 위한 용도로 캐스팅 해버렸기 때문에

기존 인스턴스 타입이 어떤지에 대한 정보가 1도 없기 떄문에

타입 캐스팅에 성공할지 여부에 대해서 알 수가 없어서

실제 런타임에 확인해야만 알 수 있어서인듯 함..!!!

정리하자면,

인스턴스를 프로토콜로 타입으로 캐스팅 할 땐 as, as?, as! 모두 가능하지만,

프로토콜로 타입 캐스팅 된 인스턴스를 원래 타입으로 캐스팅 할 땐 런타임에 확인하는 as?나 as!만 가능합니다

(물론 잘못된 타입으로 캐스팅 할 경우 크래쉬 발생)

1-2. 프로토콜 타입을 함수의 파라미터 타입과 반환 타입으로 사용할 수 있다

우린 위의 포스팅을 이해했다면

아하ㅋ 함수의 파라미터 타입과 반환 타입을 프로토콜 타입으로 선언할 수 있단 말은 말이죠ㅋ

프로토콜은 자체적으로 인스턴스를 생성할 수 없기 때문에

해당 프로토콜을 준수하는 구조체/클래스/열거형 인스턴스를

프로토콜 타입으로 캐스팅해서 전달한다는 거군요 ㅋ

라는 결론이 도달 했다면 포스팅 나가세요ㅕ

하산하셈

func doSomething(band: Band) -> Band {
    return Beatles.init()
}
 

위처럼 Band란 프로토콜 타입을 파라미터 band의 타입으로 지정해줄 수 있고

리턴 타입으로 Band란 프로토콜 타입을 지정해줄 수 도 있음!!!

당연히, 프로토콜은 어떤 인스턴스를 생성할 수 있는 객체는 아니기 때문에

위 코드에서 return문을 보면

Band란 프로토콜을 채택하고 있는 Beatles 구조체의 인스턴스를

Band란 프로토콜 타입으로 타입 캐스팅해서 리턴한단 말이고,

let beatles = Beatles.init()
doSomething(band: beatles)

실제 함수를 호출하는 곳에서도

Band란 프로토콜을 채택한 Beatles 구조체의 인스턴스를

Band란 프로토콜 타입으로 타입 캐스팅 해서 파라미터로 보낸다는 뜻임!!!

이 타입 캐스팅이란 것을 처음 말했던 "약속"이란 측면에서 보면 이해가 쉬움

너 Band란 프로토콜 준수하네!? 그러면 반드시 piano란 프로퍼티 갖고 있겠지!?!?

나 너가 다른 어떤 프로퍼티 / 메서드 선언했는진 관심 없어!

너가 Band란 약속으로 인해 구현해놓은 piano란 프로퍼티에 접근한다!!

라는 뜻으로! :)

2. 프로토콜 적합성

마지막으로, 우리가 타입 캐스팅에서 대해 얘기했으니

프로토콜 적합성이란 것에 대해 쉽게 이해하고 가겠음

2-1. is : 해당 인스턴스는 이 프로토콜을 채택하고 있니?

protocol Band { }
protocol Solo { }
 
struct Beatles: Band { }
 
let beatles = Beatles.init()
beatles is Band     // true
beatles is Solo     // false

위처럼 is를 사용하면,

인스턴스가 해당 프로토콜을 채택하고 있는지 아닌지를 Bool(true / false)값으로 리턴해줌!!!

프로토콜 3번째 포스팅도 끝!!!

월요일은 힘들군요 ㅠㅠ....

오타나 잘못된 내용 있으면 언제든 댓글 주세여!!

Swift) Protocol 이해하기 (2/6) - 프로퍼티 / 메서드 선언 이해하기

소들이 — Wed, 26 Oct 2022 20:45:48 +0900

안녕하세요!? 소들입니다 ☘️

저번 포스팅에서 프로토콜이 무엇인지에 대해 간단하게 공부했잖아요!?!?!

이번엔 이 프로토콜을 프로퍼티, 메서드로 선언할 때의

여러 가지 특징(?)에 대해 공부를 해보려고 해요!!!

모든 포스팅은 편의 말투로 합니다~!!

1. 프로토콜에서 프로퍼티 선언하기

protocol Band {
    var drum: String   { get set }
    var vocal: String  { get set }
    var piano: String  { get set }
    var guitar: String { get set }
}

위처럼 Band라는 것에 대해 일종의 약속, 즉 프로토콜을 만들었잖음?

앞으로 밴드는 이러이러한 속성(보컬, 피아노, 드럼, 기타)는 꼭 필요해요!! 하고!!

위처럼 필요한 속성에 대해 프로토콜 내부에 프로퍼티로 선언을 해두는데,

이때으 ㅣ특징에 대해 알아보겠음

일단 프로퍼티가 4개나 되어 넘 많우ㄴㅣ..........

피아노 프로퍼티 1개로 살펴 봅시다

1-1. 프로토콜을 채택해서 선언된 프로퍼티를 구현할 경우, 저장 프로퍼티로 구현하든, 연산 프로퍼티로 구현하든 상관 없다

우리가 쉽게 오해할 수 있는 것 중 하나가,

프로토콜에 선언되어 있는 프로퍼티는 항상 저장 프로퍼티로 구현해야 한다!! 인데,

class ABand: Band {
    var piano: String = "sodeul"    // piano 프로퍼티를 저장 프로퍼티로 정의
}
 
class BBand: Band {
    var piano: String {             // piano 프로퍼티를 연산 프로퍼티로 정의
        return "sodeul"
    }
}
 

위처럼 Band라는 프로토콜에 선언되어 있는 같은 piano 프로퍼티를 구현하더라도,

저장 프로퍼티 / 연산 프로퍼티와 상관 없이 구현할 수 있음!

1-2. 프로토콜에 선언되는 프로퍼티는 항상 var로 선언 되어야 한다

protocol Band {
    var piano: String { get set }
}

잠깐 다시 프로토콜 선언으로 돌아가서 보자면,

위처럼 프로토콜 내에 프로퍼티를 선언할 땐 반드시

var로 선언해주어야 함!!!

만약 let으로 선언해주면,

이렇게 에러가 뜨면서 var로 바꾸라고 나옴!!!!

프로토콜의 프로퍼티는 채택하는 곳에서 저장 / 연산 상관없이 구현 가능한데,

이때 연산 프로퍼티는 반드시 var로 선언해야 하기 때문에 (연산 프로퍼티의 경우 let 선언 자체가 불가)

만약 프로토콜에서 let으로 선언해두면, 구현하는 곳에서 연산 프로퍼티로 사용할 수 없어,

var가 필수로 요구되는 것이 아닐까 싶음(에러 메서지 내용도 그렇고!!)

에엥 그러면 해당 프로토콜을 채택하는 곳에선 항상

프로토콜에 선언된 프로퍼티를 var로 선언해야 하나요??

라는 의문이 들 수 이씀니다

이 질문에 대한 답은 바로바로!!!!!!!!!!!

연산 프로퍼티는 당연히 var로 선언해야 된다! (let은 원래 불가하다 닝겐!)

그러나 저장 프로퍼티의 경우, 타입 뒤에 달려 있는 { get set }에 따라 달려있다!

입니다 XD

이해가 안 갈테니 이해를 하러 가봅시다!

1-3. { get set } 속성에 따라 달라지는 let / var 속성

여러어부운

{ get set }의 속성에 대해 알아봅시다아

근데, 머라거??

저장 프로퍼티는 { get set }에 따라서 let / var의 속성이 달라질 수 있습니다

근데 연산 프로퍼티는 오로지 var만 가능하기 때문에 var만 사용해야 됩니다

를 이해 했다면 매우 쉬움ㅋ

1️⃣ { get }

저장 프로퍼티의 경우 let / var선언 모두 가능 합니다

연산 프로퍼티의 경우 getter(get-only) / getter & setter 선언 모두 가능 합니다

protocol Band {
    var piano: String { get }
}

위처럼 get으로 선언할 경우,

실제 채택하는 곳에서 저장 프로퍼티로 구현할 경우

let, var로 선언하든 상관 없음!!! 둘 다 가넝!!!

class ABand: Band {
    let piano: String = "sodeul"          
}
 
class BBand: Band {
    var piano: String = "sodeul"          
}
 

이렇게, let으로 선언해도 / var로 선언해도 문제 없단 말임!!

연산 프로퍼티로 구현할 경우,

class ABand: Band {
    var random: String = ""
    var piano: String {
        get {
            return "sodeul"
        }
    }
}
 
class BBand: Band {
    var random: String = ""
    var piano: String {
        get {
            return "sodeul"
        }
        set {
            self.random = newValue
        }
    }
}
 

위처럼 getter만 만들어서 get-only로 만들어도,

getter setter모두 만들어서 둘 다 사용하든 문제 없음!!!

2️⃣ { get set }

저장 프로퍼티의 경우 var로만 선언 가능합니다

연산 프로퍼티의 경우 getter & setter로 선언해주어야 합니다

protocol Band {
    var piano: String { get set }
}

위처럼 프로토콜 선언부의 프로퍼티를 { get set }으로 해줄 경우,

실제 채택하는 곳에서 저장 프로퍼티로 구현할 경우

무조건 var로만 선언할 수 있고, let으로는 선언할 수 없음

class ABand: Band {
    let piano: String = "sodeul"          // error! Type 'ABand' does not conform to protocol 'Band'
}
 
class BBand: Band {
    var piano: String = "sodeul"          
}
 

위처럼 저장 프로퍼티를 let으로 선언할 경우, Band 프로토콜을 따르고 있지 않다고 에러가 남!

따라서 { get set } 으로 선언 될 경우, 반드시 구현하는 쪽에서 저장 프로퍼티는 var로 선언 해주어야 함!

연산 프로퍼티로 구현할 때도 마찬가지로,

class ABand: Band {     
    var random: String = ""
    var piano: String {      // error! Type 'ABand' does not conform to protocol 'Band'
        get {
            return "sodeul"
        }
    }
}
 
class BBand: Band {
    var random: String = ""
    var piano: String {
        get {
            return "sodeul"
        }
        set {
            self.random = newValue
        }
    }
}
 


 

{ get set } 일 경우, getter setter 모두 제공하는 것이 필수임!

따라서 위처럼 getter만 제공하는 경우(get-only), 에러가 발생함! setter만들어! 라는 ㅎ;ㅎ;;

1-4. 어떤 프로퍼티는 opional로 설정하고 싶은데요

하면 이전 포스팅에서 말했듯이

@objc protocol Band {
    var piano: String  { get set }
    @objc optional var base: String { get set }
}

이렇게 @objc를 붙여서 @optional로 선언해주면

채택해주는 곳에서 꼭 선언해주지 않아도 에러가 안 남

2. 프로토콜에서 메서드 선언하기

protocol Band {
    func play()
}

프로토콜에서 메서드의경우,

함수의 헤더 부분만 위처럼 작성해두고,

바디 부분은 해당 프로토콜을 채택하는 곳에서 직접 구현해야 된다고 했잖음!??!

class ABand: Band {
    func play() {
        print("ABand!")
    }
}

이런 식으루!!! 메서드의 선언은 매우 간단함 :)

아.. 근디

함수의 헤더 부분을 프로토콜의 선언해 둔다는 게 조금 어렵게 와닿을 수 있는데..

함수 타입 선언임니까...? 함수 표기법임니까...? 먼디요..? 싶을 수 읶ㅆ는디..

그냥.... 우리 그냥 메서드 선언할 때 있잖음..? 그때 { } 이거 뺀 부분 선언하는 것임...

이렇게..ㅎ_ㅎ...

어렵게 생각하지 마셈 ㅎ_ㅎ..

2-1. 구조체의 경우, mutating이 필요하면 프로토콜 자체에 추가

만약, 구조체의 경우 메서드 안에서 프로퍼티 값을 변경해야 할 경우

반드시 mutating이란 키워드를 func 앞에 붙여줘야 하잖음??

이때는, mutating도 같이 프로토콜에 선언해주면 됨!!

protocol Renameable {
    mutating func changeName(newName: String)
}
 
struct Sodeul: Renameable {
    var name: String = "sodeul"
    
    mutating func changeName(newName: String) {
        self.name = newName
    }
}
 
class DeulSo: Renameable {
    var name: String = "sodeul"
    
    func changeName(newName: String) {
        self.name = newName
    }
}

이렇게!!

이때 위처럼 프로토콜 메서드 자체에 mutating이 붙어 있는 경우,

구조체의 경우는 반드시 changeName이란 메서드를 선언할 때 mutating을 붙여야 하고,

클래스의 경우엔 mutating 키워드가 필요 없으니 떼고 선언해 주면 됨!!!

(위 코드에서 구조체의 경우 mutating이 붙지 않을 경우, 아예 다른 함수로 인식하기 때문에 에러가 뜸)

후움.. 생각보다 길어져서 생각보다 포스팅이 늦어졌네요 ㅠ_ㅠ...

만약 잘못된 내용이나 오타 및 피드백 댓글 주세요!!!

Swift) Protocol 이해하기 (1/6) - Protocol이 도대체 뭔가요?

소들이 — Wed, 12 Oct 2022 20:48:09 +0900

안녕하세요!! 소들입니다
이번에 이니셜라이저가 끝났으니..!!! 프로토콜에 대해 포스팅을 해보려고 해요 :)
프로토콜만 냅다 다 포스팅 하기보다 중간 중간에
Rxswift나 Design Pattern, Architecture(Ribs / Clean Architecture)도
된다면 섞을 예정입니당!!
다시 블로그 되살리기 운동인 소들이니께 :ㅁ:

이번엔 가볍게 프로토콜이 무엇인지,
스위프트에선 어떻게 사용해야 하는지에 대해 정말 가볍게!! 공부해볼 예정입니다!!
모든 포스팅은 편의 말투로 합니다~!!

1. Protocol이란?

프로토콜이란, 어떤 기능에 적합한
특정 메서드, 프로퍼티 및 기타 요구 사항의 청사진(Bluprint)을 의미합니다
프로토콜은 클래스, 구조체, 열거형에 의해 채택되며,
프로토콜에 정의된 요구사항의 실제 구현을 제공합니다
프로토콜의 요구 사항을 모두 충족하는 모든 유형(클래스/구조체/열거형)은
해당 프로토콜에 부합하다고 합니다

위 정의는 말이죠
처음보면 무슨 말인지 1도 모른단 말이죠
따라서 나는 애플의 정의는 일단 가볍게 무시하고
좀 더 쉬운 방법으로 접근해보겠음!
(나중에 이해하고 나서 위 정의를 다시보면, 모두 완벽히 이해할 수 있기에!!)

여러분 저는 완전 신입 시절에 사수분께서
소들씨~ 프로토콜이 뭐라고 생각하세요~~?
라고 했을 때

약속이요!!

라고 대답했었음!
Protocol의 정의를 찾아보면 뭐 협약, 통신 규약 등이 있지만
좀 더 쉽게 우린 약속이라고 생각을 해보는 것임!!

자, 프로토콜을 이해하기 위해서 우린 밴드라는 것을 생각해볼 것임
내가 음악을 개짱 좋아해서 밴드라는 것을 만들고 싶음!!!
그렇다면, 밴드를 만들기 위해선 어떤 요소들이 필요할까?!!

물론 뭐 베이스도 있을 수 있고, 악기야 추가로 좀 더 많을 수 있겠지만
보통의 밴드라고 함은 위와 같이 기타, 드럼, 피아노, 보컬이 필수적으로 있어야 되잖음??

근데 밴드라는 것은 저 사람들이 모여서 수다만 떨고 끝나는 게 아니라,
어떠한 곡을 연주한다는 것이 목표잖음!?!??!
그렇다면 밴드에 대한 또다른 요구사항 중 하나는 바로, 연주가 될 것임!

그래그래ㅋ 적어도 밴드를 만들기 위해선 위와 같은 약속은 지켜줘야지 ㅋ
하고 우리가 위처럼 어떤 Band라는 것에 대한 가이드를 만들어버렸음ㅎㅎ
이것이 사실 프로토콜의 전부임ㅎㅎ

자, 이젠 위 내용들을 좀 더 프로그래밍적으로 생각해보는 것임!
Band를 구성할 때 필요한 속성 vocal, guitar, piano, drum은 프로퍼티로,
play라는 연주에 대한 행위는 메서드로 만들 수 있잖음!?!

따라서, 프로토콜이란 것은,
실제 보컬이 누구고, 기타가 누구고, 어떤 곡을 연주 할 것이고를
실제로 지정(구현)하는 것이 아니라
Band라는 것은,
이런 이런 프로퍼티는 꼭 필요해요!
이러이러한 메서드도 꼭 필요해요!
하고 해당 기능에 필요한 요구 사항을 선언해두는 것이 바로 Protocol 이란 것임!!

앞으로 내가 어떤 밴드를 만들 때,
마치 [밴드를 만들 때 필요한 101가지 방법]과도 같은
미리 정의된 Band라는 프로토콜을 통해서(채택해서) 만들 경우,
보컬, 기타, 피아노, 드럼이라는 속성은 필수적으로 필요하며,
연주하다 라는 기능도 필수적이겠구나!!

를 생각해본다면,
여러분은 프로토콜을 모두 이해한 것입니다 ㅋ
이해가 안 가셔도 괜찮음 설명을 개떡같이 해서..ㅎㅎ;;
코드를 보면서 차근차근 이해해 봅시당 :)

1-1. 프로토콜을 정의하는 방법

protocol Band {
    var drum: String   { get set }
    var vocal: String  { get set }
    var piano: String  { get set }
    var guitar: String { get set } 

    func play()
}

우리가 위에서 Band라는 것으로 만든 프로토콜(약속)은 위처럼 정의할 수 있음!!
프로토콜이란 것은 앞서 누누(간다!)히 말했듯이
프로퍼티를 선언하여 값을 직접 정의하고, 메서드를 직접 구현 하는 것이 아님!!
이 프로토콜을 따르려면 이러 이러한 것들이 필요하다!! 라는 약속을 정의해두는 것임

밴드라는 프로토콜을 따르기 위해선
드럼 보컬 피아노 기타 프로퍼티가 반드시 정의되어 있어야 하고,
play란 메서드가 반드시 정의되어 있어야 해요!!
라는 것을 선언해두는 것이 바로 Band란 프로토콜임!!

프로퍼티는 let으로 선언하면 안 되나요?
{ get set }이 뭔가요? get만 두면 안되나요?
메서드는 어떤 식으로 선언해 두는 건가요!?

같은 의문은, 바로 다음 포스팅에서 다룰 것이니 넘어가셈!!

지금은 그냥 위처럼
프로토콜은 어떤 기능을 수행할 때 필요한
어떠한 프로퍼티, 메서드에 대해 구현하는 것이 아닌, "선언"만 해두는 것이구나!!만
이해하고 가자 :)

1-2. 프로토콜을 채택하는 방법

자 우리는 Band라는 프로토콜을 선언함으로써,
Band라는 일종의 약속을 만들어둔 것임

그럼 이제 그것을 클래스, 구조체, 열거형이 채택하여 사용할 수 있게끔 만들 수 있는데,
자, 우리가 만약 ABand라는 새로운 밴드를 만들 것임!!

struct ABand {}

위처럼!!
근데, 이 ABand라는 밴드는
밴드를 생성할 때 필요한 요소들을 미리 정의해둔 Band라는 프로토콜(약속)을 따르고 싶어!!
라고 할 경우에,

struct ABand: Band {}

위처럼, 마치 상속을 받을 때처럼,
Band라는 프로토콜을 클래스 이름 옆에 선언해주는 것만으로 해당 프로토콜을 "채택"하게 되는 것임!!

그러면 이제, ABand라는 구조체에서 에러가 뜸

야 너! Band라는 프로토콜 따른다매!!
너어 Band라는 프로토콜을 따르려면
보컬, 기타, 피아노, 드럼 이란 프로퍼티가 정의되어 있어야 하구!!
play란 메서드도 구현되어 있어야 한다구!!
왜 약속 안지켜!!

하고 에러가 뜨는 것임!

class ABand: Band {
    var drum:   String = "A"
    var vocal:  String = "B"
    var piano:  String = "C"
    var guitar: String = "D"
    
    func play() {
        print("day6 예뻤어 연주 중!")
    }
}

 

따라서 위와 같이 Band 프로토콜 안에 선언만 되어 있던 녀석들을
채택한 곳인 ABand라는 구조체 안에서 실제로 구현 해주는 것이 필요함!!
이렇게 하면 이제 에러가 사라짐!

이것이 바로 프로토콜임!!
프로퍼티/메서드에 대한 껍데기만 제공하되, 실제 구현은 채택한 곳에서 하는 것임!!

어느 정도 이해가 갔을 거라 믿구,
그럼 처음에 봤던 애플 정의를 다시 본다면

프로토콜이란, 어떤 기능에 적합한
특정 메서드, 프로퍼티 및 기타 요구 사항의 청사진(Bluprint)을 의미합니다
프로토콜은 클래스, 구조체, 열거형에 의해 채택되며,
프로토콜에 정의된 요구사항의 실제 구현을 제공합니다
프로토콜의 요구 사항을 모두 충족하는 모든 유형(클래스/구조체/열거형)은
해당 프로토콜에 부합하다고 합니다.

이젠ㅇ ㅣ해 할 수 있기를..!!! :)

2. 필수라기엔.. 베이스는 구하기 힘든데...

위에서 아무렇지 않게 프로토콜 안에 선언되어 있는 프로퍼티 / 메서드는 모드
required 즉, 필수적인 것임
따라서 채택하는 곳에서 구현하지 않을 경우 에러가 남!!

근데,, 베이스 같이 구하기 힘든 멤버도 프로토콜 안에 선언해두고 싶은데,,
이녀석은 밴드마다 있을수도,, 없을 수도 있거든요,,
희귀한 녀석이거등요,,

할 경우에,
optional로 선언할 수도 있음!!

@objc protocol Band {
    var drum: String   { get set }
    var vocal: String  { get set }
    var piano: String  { get set }
    var guitar: String { get set }
    @objc optional var bass: String { get set } 

    func play()
}

bass란 프로퍼티 앞에 @objc optional을 붙일 경우(프로토콜에도 당연히 @objc 선언),
이땐 bass라는 프로퍼티에 한해서 required가 아닌 optional로 바뀜!
채택해주는 곳에서 꼭 선언해주지 않아도 에러가 안 남

뭐죠 bass 선언은 자유라며요!! 왜 에러가 나죠!!
이때의 에러는, bass란 프로퍼티를 선언하지 않아서 나는 에러가 아니라,
Band라는 프로토콜을 채택하는 녀석이 "구조체"이기 때문에 나는 에러임

왜냐?
@objc라는 문법을 붙이는 순간 Objective-C에서도 사용될 수 있단 것인데,
Objective-C에서 프로토콜은 오로지 "클래스 전용"에서만 채택할 수 있음..
따라서 호환성을 위해 @objc가 붙는 순간 자동으로,

@objc protocol Band: AnyObject {
    var drum: String   { get set }
    var vocal: String  { get set }
    var piano: String  { get set }
    var guitar: String { get set }
    @objc optional var bass: String { get set } 

    func play()
}

이렇게 클래스 전용일 때 사용하는 AnyObject가 자동으로 채택된다고 보면 됨!!!
Optional인 만큼, 채택하는 곳에서 선언 했을지 안 했을지 여부를 알 수 없기 때문에,

만약 Band라는 프로토콜 타입을 통해 bass에 접근할 경우,
이때 bass는 String? 즉, Optional(String) 타입으로 접근해야 함!!

.
.
.
이번엔 프로토콜의 정말 기초.. 정말 기초.. 기초 중에 기초에 대해 알아봤.. 습니다..
초반에 프로토콜이 이해하기 꽤 어려워서ㅠㅠ.. 쉽게 이해 시키고 싶었는데ㅜㅜ
요즘 머리가 굳었는지 쉽게 설명이 잘 안되네여..ㅎㅎㅎㅋ...
이번에 맛만보기를 했다면
다음 포스팅에서부턴 프로토콜에 대해 좀 더 깊게 들어가서 공부해보도록 하게씁니당..!!
잘못된 내용 및 오타피드백 댓글로 남겨주세요!!!

Swift) 초기화(Initializers) 이해하기 (6/6) - Failable Initializers / deinit

소들이 — Thu, 6 Oct 2022 22:52:54 +0900

안녕하세요 소들입니다.. zZ

8시 출근 후기

ㅋ..

으아앙으아ㅏㅇ졸려 졸려!!! 졸리지만 난 점심시간에 포스팅을 쓸 거야!!!

이번 포스팅은 드디어... 이니셜라이저의 막을 내릴 수 있겠네요!!

6편에 걸쳐 진행한 만큼 사실 내용이 조금 어렵기도 하고,

이해하기 어려웠을 수도 있어요...!!!

하지만 이니셜라이저는 기본기 중에서도 정말 중요한 내용이기 때문에..!!

만약 제대로 이해가 안 가시면 몇 번이고 읽어서 완전히 자기 것으로 만드시길 바라겠습니다 :)

물론 저도.. 이제 3년꽉한 개발자라서.. 많이 공부하고 쓰지만

잘못된 내용이 있을 수 있으니..! 발견 시 꼭 피드백 주세요!! ‍ ️

모든 포스팅은 편의 말투로 합니다~!!

1. Failable Initializers

기존 생성자(Nonfailable Initializers)는 컴파일 시점에 모든 프로퍼티가 초기화 되어야 하기 때문에

초기화에 실패할 경우, 컴파일 에러가 발생합니다

하지만 Failable Initializers는 초기화에 실패하더라도 에러가 발생하지 않고 nil을 리턴합니다

생성자의 Optional 버전이라 보면 됩니다

사실 생성자의 Optional 버전이라 하면 이해는 가지만,

엥?? 초기화에 실패?? 언제 쓰셈..?? 할 수 있잖음!?

근데 사실 우린 이걸 꽤나 자주 사용하고 있었음!

let one: String = "1"
let two: String = "two"
 
let oneNum = Int(one)       // 1
let twoNum = Int(two)       // nil

이렇게!!!!

우리가 String을 Int로 형변환하고 싶을 때 위처럼 사용했잖음?!?!?

그럼 이때

Int(String 타입)

이 위 메서드 자체가 바로 Int형이 갖고 있는 생성자 중 하나잖음?

파라미터를 String 타입을 받고 있는!

근데 어떻게 "1"을 넣으면, 1이 저장된 Int 자료형을 리턴하고

"two"를 넣으면 숫자로 변환할 수 없으니 nil을 리턴할까!?

생성자가 nil을 어케 리턴하냐 이말이다!! 쾅ㅋ와쾅!!

그게 가능한 것이

바로 저 생성자가 우리가 공부하고 있는 failable initializers,

즉 실패가 가능한 초기화이기 때문임 :)

실제 생성자의 형태를 보면,

이렇게 init 다음에 ?가 붙은 것을 볼 수 있음!!

아까 failable initializers는 이니셜라이저의 Optional 버전이라 했잖음!?

그래서 뒤에 ?가 붙은 것임!

이럴 경우, 초기화에 실패할 경우 nil을 리턴할 수 있음!!

실제로, 애플 문서를 보면

extension Int {
    init?(fromString: String) { 
        if let i = fromString.toInt() {
            // Initialize
            self = i
        } else { 
            // return nil, discarding self is implied
            return nil
        }
    }
}
 

이렇게 나와 있음!!

Int로 변경할 수 있을 없을 경우엔 nil을 리턴하고 있음

따라서 nil이 리턴된 경우엔 초기화가 실패했음을 의미함!!
(실패할 경우 무조건 nil만 반환해야지, 다른 값으로 대체하면 안됨!!)

다만, Optional 생성자라고 말한 만큼!!!

리턴 받은 인스턴스의 타입은 무조건 "옵셔널 타입"임(꼭 기억)

따라서, 우리가 Int(one)으로 인해 생성받은 oneNum에 할당된 인스턴스는

이렇게 Int 타입이 아니라 Int? 타입임!!

왜냐? failalbe initializers를 통해 인스턴스를 생성했기 때문!!

아 참고로 생성자에서 우리가 상황에 따라 nil을 리턴 시키지만,

생성자에선 리턴 타입을 명시하지 않음!!

또 다른 예시로는,

우리가 enum을 쓸 때 rawValue를 이용해서 쓸 때가 있잖음!?!?

enum Color: String {
    case Red, Green, Blue
}
 
let RedInstance = Color.init(rawValue: "Red")           // Red
let redInstance = Color.init(rawValue: "red")           // nil

이렇게 RawValue를 이용해 enum을 초기화 할 때

이때도 RawValue에 해당하는 값이 case로 정의되어 있지 않을 수 있으니,

이때도 failable initializers인 것임!!

따라서, 정의되어 있는 RawValue 중 "Red"가 있을 경우엔 해당 case를 가지는 인스턴스가 반환되고,

정의되어 있는 RawValue 중 "red"가 없을 경우엔 nil이 리턴 됨

당연히 RedInstance, redInstance 둘 다 타입은 Color란 열거형의 옵셔널 타입인

Color? 타입이 되는 것임

또 생각해봤는데 저번 포스팅에서,

required init?(coder aDecoder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}
 

이 코드를 공부 했잖음!?!

NSCoder 자체가 xib / storyboard에서 xml 형태의 데이터를 읽어와서 UI를 구성하는 놈이었는데,

만약 해당 xib / storyboard를 어떠한 이유로 읽어올 수 없다면,

그땐 초기화에 실패해야하니까

그래서 init?으로 지정해둔 것이 아닐까 함..! (아님 말구..)

1-1. init?

초기화에 성공하면 초기화된 인스턴스가 "Optional Type"으로 리턴

초기화에 실패하면 "nil"을 리턴

init?() { ... }
 

바로 위에서 공부한 것!

1-2. init!

초기화에 성공하면 초기화된 인스턴스가 (특정 조건일 때) "Non-Optional Type"으로 리턴

옵셔널 강체 추출이기 때문에, 초기화 실패 시 크래시가 발생

이건 IUO랑 관련이 있느데, 만약 IUO가 모른다면 이 포스팅을 먼저 보시구!

어쨌든 옵셔널 강제 추출이란 말로 생각을 해보면,

class Human {
    let name: String
    
    init?() {
        self.name = "unknown"
    }

    init!(name: String) {
        guard name != "" else { return nil }
        self.name = name
    }
}
 
let sodeul = Human.init(name: "sodeul")   // Human
let deulso = Human.init(name: "")         // nil


 

자, 봐보자

sodeul란 인스턴스는 init! 생성자의 name을 "sodeul"로 주었으니 정상 초기화 된 건 오케이!

근데 deulso이란 인스턴스는, name을 ""로 주었기 때문에

이는 초기화 실패이고 크래시 발생해야 하는 거 아닌가요?? 이때도 왜 nil이 할당 되죠??

란 생각이 들잖음??

근데 이건 IUO로 생각을 해야할 것 같음

IUO도 Optional Type으로 선언하는 방법 중 하나으로,

Non-Optional Type으로 처리되어야 할 때 값을 자동으로 추출해줌

Non-Optional Type으로 처리되어야 할 때 값을 자동으로 추출해주는 것이 IUO잖음??

우리가 IUO 포스팅에서 공부할 때 그 처리되어야 한다는 때가 바로 어떤 때였음!?

바로 IUO로 선언된 놈을 Non-Optional Type에 대입할 때 였음!

아까 위에서 초기화에 성공할 경우, (특정 조건일 때) Non-Optional Type의 Instance를 리턴한댔잖음!?

그 특정 조건이 바로 Non-Optional 타입의 인스턴스를 init!으로 초기화할 때를 말한 것임!!

자, 정리해보면!

init! 이나 init? 이나 기본적으로 인스턴스를 옵셔널 타입으로 반환하는 것은 똑같음

그러나 init!은 IUO로 동작하기 때문에,

만약 이 생성자를 받는 인스턴스의 타입이 Non-Optional타입일 경우,

Non-Optional Type으로 자동으로 묵시적 옵셔널 바인딩을 해서 리턴해주는 것임

따라서,

위에서

Human.init()에서 사용한 생성자는 init? 생성자로,

sodeul의 타입, 즉 옵셔널 타입이 아닌 Human 타입에 대입할 시 초기화 성공/실패와 상관 없이 무조건 위처럼 에러가 남

왜?? Human.init()은 Human? 이란 옵셔널 타입인데! 어떻게 옵셔널 바인딩 없이 넣어!란 컴파일 에러임

근데,

Human.init?(name: "deulso")에서 사용한 생성자는 init! 생성자로,

deulso의 타입, 즉 옵셔널이 아닌 Human 타입에 대입할 경우, 에러가 나지 않음

왜?? Human.init?(name:)은 IUO로 인해 자동으로 필요할 때 값이 Non-Optional Type으로 추출되어 들어가는 것임!

근데 어라? 아무리 init!이 묵시적 추출이라 해도, 이 아이는 초기화 실패 시 nil을 반환하는데,

어떻게 Non-Optional Type에 대입이 가능한거죠?

응 강제추출이야~

만약 실패화에 초기한 인스턴스를 위처럼 강체 추출하게 될 경우,

이땐 컴파일 에러가 아닌 크래시가 남!!

당연히 크래시가 날 위험이 있는 코드는 지양하는 게 맞기 때문에

init!은 사실 거의 사용되지 않음ㅎㅎㅎ;;..

1-3. failable initializers의 오버로딩 / 오버라이딩

1️⃣ initializers를 오버로딩 할 경우, failable / nonfailable을 구분하지 않는다

이처럼 init?(name: String) , init!(name: String)은 앞에 ?냐 !에 따라 다르니까

오버로딩 가능한 거 아닌가요!? 하겠지만,

initializers의 오버로딩일 경우, failable / nonfailable을 구분하지 않음!!

2️⃣ 슈퍼 클래스의 failable initializers를 자식 클래스에서 nonfailable initializers로 오버라이딩 해도 되지만,

이땐 당연히 failable initializer만 사용할수 없다(다른 놈 쓰던가 / 옵셔널 바인딩 해주든가)

위처럼 슈퍼 클래스 Human에서 작성된 init?(name:),

즉 failable initializer를 서브 클래스 Sodeul에서 오버라이딩 할때,

override init(name:)으로 nonfailable로 오버라이딩 해도 된다는 말임!!!

다만, 이때 super.init(name:)은 실패할 수 있는 초기화이기 때문에

이거에대한 옵셔널 해제 작업이 필요함!

음... 내가 생각한 건 nonfailable로 선언된 슈퍼 클래스의 이니셜라이저를 부르는 것이었는데..

super.int(name: name)! 이렇게 슈퍼 클래스의 failable 이니셜라이저를

강제 해제해버리는 방법도 있긴 하답ㄴ디ㅏ...

굳..이요..?....

2. deinit

소멸자라고 불리며, 클래스 전용으로

인스턴스가 메모리에서 정리되기 전에 자동으로 호출된다

deinit은 메서드 하나만 작성할 수 있게 제한되고, 직접 호출할 수는 없다

class Human {
    deinit {
        print("☺️")
    }
}
 
var sodeul: Human? = Human.init()
sodeul = nil                            // 메모리에서 해제됨과 동시에 deinit 실행되어 ☺️가 프린트됨
 
 

요렇게 직접 deinit을 클래스 내에 작성하고,

메모리가 해제되기 전에 해야할 작업을 지정해두면

메모리가 해제될 때 deinit이 불린답니다아 :)

점심시간에 다 작성할 줄 알고 시작한 포스팅이었는데..

꽤나 오래 걸려버렸다..

IUO를 모른다면 쪼금 이해하기 어려웠을 수 있는 포스팅.!

드디어 이니셜라이저가 끝났습니당 :)

잘못된 내용 피드백은 언제나 댓글 주세용!!

Swift) 초기화(Initializers) 이해하기 (5/6) - Required initializer

소들이 — Wed, 5 Oct 2022 19:56:13 +0900

안녕하세요, 소들입니다 :>

유연 근무제로 인해 공부 시간과 취미 시간을 모두 얻었지만

피곤을 x100배로 얻어버렸다ㅠ;; 망할

그래도 전 요즘 기타 치느라 박인 왼손의 굳은살을 자랑하는 낙으로 산답니다

응 이제 코드 몇 개 치는 게 다야~ 소들갑이야~

사실!!! 포스팅 시간과 공부 시간이 많아진 게 가장 좋네요 XD

카페 값으로 월급 다 나가겠어^^;;

Aㅏ.. 초기화 이해하기 시리즈가 5편에서 6편이 된 것 같은 건 피곤한 여러분의 기분 탓입니다ㅎ..

쨌든 이번 포스팅에선 required init에 대해 알아보려고 합니당!!

이번 포스팅은 지금껏 공부한 것보다 크게 어렵지 않은 내용이랍니다~~

모든 포스팅은 편의 말투로 합니다~!!

1. required init

필수 생성자로, 슈퍼 클래스에서 정의해둘 경우

서브 클래스가 슈퍼 클래스의 생성자를 상속받지 않는 한

서브클래스에서 반드시 구현해주어야 합니다

필수 생성자는 말이야.. 말 그대로..ㅋㅋ... 필수 생성자임

서브 클래스에서 반드시 구현해야 하는 생성자의 경우,

슈퍼 클래스에서 required init으로 설정해두는 것임

사실 개발자가 필수 생성자를 직접 구현할 일은 거의 없기 때문에!

생소할 수 있음!

그러나 UIView / UIViewController 를 상속받은 클래스를

xib나 storyboard 없이 코드로 화면을 꽤나 구성해보신 분이라면 바로,

required init?(coder aDecoder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}
 

이 코드가 익숙할 것임!!

ㅇㅣ 포스팅에서 required init에 대해 공부한다면,

이 위 코드가 언제 등장하는지에 대해 알 수 있음!!!

자, 다음 코드를 봐보자 :)

class Human {
    var name: String?
    
    required init(name: String) {
        self.name = name
    }
}
 

위와 같은 코드가 있음!!

Human이란 클래스 안에 required init(name:)이란 필수 생성자를 작성했음

아하! 그러면 이제

Human을 상속받는 모든 서브 클래스는 required init(name:)를 필수적으로 작성해야겠네요!?

싶잖음!?

class Sodeul: Human {
    var nickName: String
    
    init(nickName: String) {
        self.nickName = nickName
        super.init(name: "")
    }
    
    //erorr! 'required' initializer 'init(name:)' must be provided by subclass of 'Human'
}
 

맞음!! 실제로 Human이란 클래스를 상속받는 Sodeul 클래스의 경우,

required initializer를 작성하지 않았다며 에러가 남!!!

따라서 다음과 같이

class Sodeul: Human {
    var nickName: String
    
    init(nickName: String) {
        self.nickName = nickName
        super.init(name: "")
    }
    
    required init(name: String) {
        fatalError("init(name:) has not been implemented")
    }
}
 
 

Human 클래스에서 정의 했던 required init(name:)을 정의해주어야만 에러가 사라짐

아닝 근데 Human클래스의 required init(name:)을 그대로 작성하는 거면

이것은 오버라이딩 아닌가용?? 근데 왜 오버라이딩 키워드를 안 붙이나용??

결론적으론 오버라이딩이 맞음!

근데 required init 같은 경우,

override 키워드 없이, 슈퍼 클래스와 동일한 형태로 구현을 해주어야 함!!

자, 근데

class Sodeul: Human {
    var nickName: String?
}
 

이렇게 모든 프로퍼티가 기본 값을 갖고 있어 지정 생성자를 따로 작성하지 않으면

부모 클래스의 지정 생성자를 모두 상속받는다는 사실은 저번 포스팅에서 공부 했잖음!?

근데 이렇게 부모의 생성자를 모두 상속받을 경우에는,

required init(name:)을 구현하지 않아도 에러가 안 남!!

아항!

required init은 서브 클래스에서 "지정 생성자를 직접 구현"했을 경우에만 필수적이구나!

왜냐?

부모의 모든 생성자를 상속받으면 부모에 선언되어 있는 required init(name:)을 상속 받지만,

자식 클래스에서 지정 생성자를 구현해버릴 경우, 더이상 상속 조건에 맞지 않아

required init(name:)을 상속받을 수 없어서

이땐 required init(name:)를 자식 클래스에서 필수로 정의 해줘야 하는 것임

2. NSCoding 네 놈 때문이었다

자, 이제 required init을 우린 이해해버렸음!!

그럼 다시 돌아가서,

UIView / UIViewController로 이해를 해보자면,

UIView / UIViewController를 상속받아 커스텀 클래스를 만들 때,

import UIKit
 
class SodeulView: UIView {
    func draw() { }
}

이렇게 지정 이니셜라이저를 직접 서브 클래스에서 작성하지 않을 경우엔,

아무런 문제가 없지만,

import UIKit
 
class SodeulView: UIView {
    override init(frame: CGRect) { ... }

    required init(coder: NSCoder) {
        fatalError("init(name:) has not been implemented")
    }

    func draw() { }
}

위처럼 지정 생성자를 직접 서브클래스에서 작성할 경우엔,

required init이 필수적이라고 위에서 배웠음

이번엔 그 이유를 보자면,

SodeulView의 상위 클래스인 UIView가 바로

NSCoding이란 프로토콜을 채택하고 있음!!!

자, 우리가 코드로 화면을 구성할 수도 있지만, storyboard나 xib를 이용해서 View를 구성할 때도 있잖음??

그때 그 storyboard나 xib는 우리가 만들어둔 UI의 형태를 xml 형태로 저장하고 있음!

이 저장된 형태를 우리의 화면으로 가져오기 위해서는 이 xml형태로 저장된 파일의 구성을 가져와야 하는데,

이 구성을 가져올 때 사용되는 것이 바로 init(coder: NSCoder)란 것임!!!

class SodeulView: UIView {
    
    // 코드로 뷰를 생성할 때를 위한 지정 생성자
    init() {
        super.init(frame: .zero)
    }
    
    // 위 지정 생성자가 생김에 따라 부모 클래스 이니셜라이저 상속이 불가하여 구현해줘야하는 Interface Builder용 생성자
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}
 

따라서 UIView / UIViewController 에서 storyboard나 xib를 통해 뷰를 생성할 때

required init(coder: NSCoder)는 반드시 필요한 것임!!

따라서 저 NSCoding 안에 requred init으로 선언되어 있다고 봤음..(아마도.. ?)

근데 xib, storyboard로 화면을 그릴 땐

서브 클래스에서 지정 초기화를 따로 생성할 필요가 없으니 생성하지 않으면,

required init(coder: NSCoder)를 자동으로 상속받아 굳이 서브 클래스에서 구현해줄 필요가 없지만,

나는 xib / storyboard 말고 코드로 직접 뷰를 생성하고 싶은데요?! 할 때는

새로 지정 생성자를 구현해야 하고

(이때 새로 구현하건, 오버라이딩 받던 새로 만든 생성자는 당연히 부모의 지정 생성자를 호출 해줘야 함),

새로 지정 생성자를 직접 구현한다는 것 자체가 부모의 생성자를 상속받지 않는단 것이기 때문에

이땐 required init(coder: NSCoder)을 직접 구현해주어야 하는 것임

근데 required init의 내용이 자동으로 fatal error인 이유는,

너 코드로 작성한다며!!!!! 그래서 지정 생성자 만들었자나!!!!!!!!!

그래서 코드로 이 뷰를 만든다면 xib, stroyboard일 때만 불려야하는 이 생성자는 절대 불리면 안 돼!! 앱 종료!!!!!

라는 느낌이지만

사실 난 그래서 저렇게 fatal error보단,

required init?(coder aDecoder: NSCoder) {
    super.init(coder: coder)
}
 

이렇게 super.init으로 명시해주는 편이긴 함 ..:D

required init에 대해 알아봫ㅆ는데용...

음.. 뭔가 설명이 명확하지 않은거 같아서 음.....

나중에 보충... 할...... ㄱ..ㅓ..임...ㅠ..

이해가 안되거나 잘못된 내용이 있으면 반드시 피드백 주세용!!

Swift) 초기화(Initializers) 이해하기 (4/6) - 클래스의 2단계 초기화 및 상속

소들이 — Tue, 4 Oct 2022 20:09:28 +0900

안녕하세요 :) 소들입니당

오늘부터 저는 일찍 일어나는 새가 일찍 졸리다..를 시전할 예정

난 파워 P인데 분명..

인생 계획만큼은 늘 J로 세우는.. 사람 이랄까..?

쨌든 이번 포스팅은 지겨운 Initializer 4번 째!!!!

클래스의 Initializer에 대해 좀 더 자세하게 알아볼 것입니당 :)

그래도 점점 끝이 보여가서 기분이 좋네여!!!

한두편 정도 더 늘어날 수.. 도 ..? 내용이 어려워

얼른 이거 다쓰고 프로토콜 써야지~~

저는 문법 시리즈를 쓸 때 항상 이전 포스팅을 완벽하게 이해 하고

공부 했단 것을 전제로 깔고 공부 해보도록 하겠습니당 :)

모든 포스팅은 편의 말투로 합니다~!!

생각해보니 영어로 Designated / Convenience 쓰기 겁나 귀찮은데

난 걍 한글로 쓰면 될 걸 왜.. 그런.. 짓..을 ..?

따라서 앞으론 지정 / 편의 초기화라 하겠음..

1. Swift 클래스의 2단계 초기화

Swift에서 초기화는 두 단계 과정을 거칩니다

첫 번째 단계에서 저장된 각 프로퍼티는 해당 클래스에 의해 초기값이 할당 됩니다

첫 번째 단계로 인해 모든 프로퍼티의 초기값이 할당되면,

두 번째 단계로 해당 인스턴스를 사용할 수 있는 상태로 간주하기 전에 프로퍼티 값을 사용자 정의할 수 있는 기회가 제공 됩니다

두 단계 초기화는 초기화를 안전하게 만들도록 진행합니다

ㅋㅋ;; 먼데;;

나 빼고 다 이해했냐!?! 나 빼고 다 이해했냐고!!!

라고 생각했는데.. 제가 이해한 내용을 토대로 적어 보겠습니당

틀릴 수 있으니 잘못된 내용은 꼭 피드백 바랍니다 :)

1-1. 1단계 초기화

1단계 초기화에선 클래스의 새로운 인스턴스를 위한 메모리가 할당되며, 이때 메모리는 초기화 전입니다

지정 초기화는 해당 클래스의 프로퍼티에 초기값이 있음을 확인하여 그 값으로 초기화 합니다

지정 초기화는 자신의 프로퍼티 값을 모두 초기화 시킨 후, 부모의 초기화 함수에 전달 됩니다

이 작업은 상속 고리의 최상단 부모 클래스에 도달할 때까지 계속 진행됩니다

이 작업으로 인해 최상위 부모의 프로퍼티까지 모두 기본 값으로 초기화 되면

이때 비로소 instance의 메모리가 완전히 초기화 되었다고 할 수 있으며,

1단계 초기화가 완료된 것입니다.

길..죠..? 그래서 어려워 보..이죠? 근데 사실 별 거 없음

자, 초기화의 가장 중요한 핵심은 뭐라 했음!?

바로 "모든 프로퍼티가 초기값을 가져야 한다" 였잖음?

따라서 지정 초기화를 생성할 경우, super 클래스의 지정 초기화를 반드시 호출해주어야 한다 했음

왜? 내가 내 클래스의 프로퍼티만 다 초기화 할 경우,

부모 클래스에 선언된 프로퍼티가 초기화 되지 않을 수 있기 때문에!

따라서 내 프로퍼티를 모드 초기화 하고,

super.init을 통해 부모 클래스의 초기화까지 모두 시켜버리는 것이

바로 이 1단계 초기화란 말임

class Human {
    var name: String
    
    init(name: String) {
        self.name = name
        
        print(name)
    }
}
 
class Developer: Human {
    var language: String
    
    init(language: String) {
        self.language = language
        super.init(name: "unknown")
        
        print(language)
    }
}
 
class Sodeul: Developer {
    var nickName: String
    
    init(nickName: String) {
        self.nickName = nickName
        super.init(language: "swift")
        
        print(nickName)
    }
}
 


 

자, 위와 같은 코드가 있다고 보셈!

Sodeul이란 클래스는 Developer란 클래스를 상속받고,

Developer는 Human 클래스를 상속 받음!!

이때 만약 다음과 같이,

Sodeul(nickName: "DeulSo")

 

Sodeul이란 클래스의 인스턴스를 생성하기 위해 생성자를 부르면,

이렇게, Sodeul 클래스의 init(nickName: String) 생성자가 호출되고,

이때 Sodeul 클래스 안의 모든 프로퍼티는 초기 값을 지니어야 함

그래야 그 값으로 초기화를 진행할테니까!

(물론 이때 옵셔널 타입의 변수이거나, 기본 값을 지닌 프로퍼티의 경우는 생성자에서 값을 지정해주지 않으면,

옵셔널 타입의 변수는 nil로, 기본 값을 지닌 프로퍼티는 해당 기본 값으로 알아서 초기화 됨!)

하여튼 이렇게 초기값을 갖지 않는 프로퍼티에 한해서 초기값을 지정해주고,

부모 클래스의 생성자를 호출하는 이 당연한 과정이 바로

Swift의 초기화 1단계임!!

이 과정을 거쳐 최상위 클래스에 도달해서 더이상 슈퍼 클래스의 생성자를 호출할 수 없을 때,

이때 1단계 초기화가 끝나면서, 비로소 인스턴스의 메모리가 완전히 초기화 되었다! 라고 볼 수 있음

당연히 인스턴스의 메모리가 완전히 초기화 되기 전엔,

해당 프로퍼티를 읽고 쓰기가 불가능하기 때문에(초기화 외에)

이렇게 슈퍼 클래스의 init을 호출하기 전에(1단계 초기화가 끝나지 않은 경우)

이때 이미 내 생성자에서 초기화가 진행된 self.nickName의 값을 읽어오는 것은 가능하지만,

아직 초기화가 되지 않은 슈퍼 클래스의 프로퍼티 name, language는 접근할 수 없는 것!!

1-2. 2단계 초기화

최상위 부모 프로퍼티의 생성자까지 모두 호출 되어 1단계 초기화가 완료된 경우,

이때부턴 지정 초기화로부터 인스턴스를 구체화 할 기회를 부여 받습니다

이 단계부터 self에 접근할 수 있으며, 프로퍼티의 값 수정 및 메소드 호출 등등의 작업이 가능합니다

부모 클래스의 저장 프로퍼티 값을 변경할 수 있다

모~든 프로퍼티가 기본 값을 가지게 되어 초기화가 완료 되었다면,

이제부턴 가장 마지막으로 호출됐던 제일 상위 클래스의 남은 작업부터 차례로 아래로 실행됨

(당연히 메서드 호출은 스택으로 이루어지니!!)

따라서 이때 만약 Human 클래스에서 name을 "sodeul"로 설정 했더라도,

이는 Human 클래스의 2차 초기화 과정에서 "deulso"로 덮어씌어지고,

최종적으로 Sodeul 클래스의 2차 초기화 가정에서 "unknown"으로 덮어 씌어짐

따라서 Sodeul의 초기화가 끝난 후 name의 값을 찍으면 가장 마지막에 덮어씌어진 "unknown"이 나옴!!

따라서 부모, 조상 클래스의 저장 프로퍼티 값을 변경하는 것이 2차 초기화 과정에서 가능한 것임!!

앞서 말 했듯

1차 초기화가 끝난 이후, 인스턴스가 생성되기 때문에

위처럼, sayHello란 메서드를 1차 초기화가 끝나기 전엔 호출하지 못하지만,

2차 초기화 지점에 호출할 수 있음!!

1-3. 2단계 초기화는 왜 있는 걸까?

지정 초기화는 상속받은 프로퍼티에 접근하기 전에, 부모의 초기화를 먼저 호출(위임) 해야 함

이로 인해 부모의 초기화에 의해 내가 설정한 겂이 덮어지는 문제를 방지할 수 있음

편의 초기화 또한 어떤 프로퍼티든 접근하기 전에 다른 초기화를 먼저 호출(위임) 해야 함

전에 편의 초기화 공부할 때 말했잖음!?

Convenience Initializers에서는 프로퍼티 값 설정 못하나여?ㅠ

설정하려고 하면 'self' used before self.init call or assignment to 'self' 에러 뜨는데염 ㅠ

위 처럼 에러가 뜰 때는 다른 Initializer가 불린 후에 접근해주면 됨!!

이런 식으루!! :)

다른 초기화를 부르기 전에 값을 설정하면,

다른 초기화에 의해 값이 덮어씌어지는 문제가 발생할 수 있기 떄문에 이를 방지하는 것임!!!

이제는 이해할 수 있겠군요!!!!!!!! XD

이처럼, 초기화를 보다 "안전"하게 진행하기 위해

(초기 값이 설정되기 전에 해당 프로퍼티에 접근하거나, 부모 생성자에 의해 값이 덮어씌여지거나 하는 일이 없게!!)

2단계 초기화를 통해 초기화를 진행 함 :)

2. Initializer의 상속

우린 클래스의 생성자가 총 2단계를 걸쳐 초기화를 진행한다는 것을 알게 됐잖음!?

근데 이번엔 이 클래스의 생성자의 상속에 대해 알아볼 것임

클래스의 Initializer는 총 두 가지 조건에 의해 상속이 됨

Swift 서브클래스는 기본적으로 슈퍼클래스 이니셜라이저를 상속받지 않기 때문에 생긴 조건임!!

옵젝씨와 다르니 헷갈리지 마셈!!

2-1. 서브 클래스에서 지정 초기화를 직접 구현하지 않았다면, 슈퍼 클래스의 모든 지정 초기화가 상속 된다

자, 열어분 생각을 해보셈

클래스에서 지정 초기화를 직접 구현하지 않아도 되는 경우는 언제였음!??!!

바로 생성자를 작성하지 않아도 모든 프로퍼티가 기본 값을 가질 경우에 한해서였음

어떻게?

옵셔널 타입의 변수로 설정되어 자동으로 nil로 초기화 되거나,

아니면 생성과 동시에 초기값을 갖거나!!!

class Human {
    var name: String
    
    init(name: String) {
        self.name = name
    }
}
 
class Sodeul: Human {

    // 1. 서브 클래스의 모든 속성이 기본 값으로 초기화
    var nickName: String = "Sodeul"
    var age: Int?
    
    // 2. Designated Initializers를 직접 구현 X
}
 

요롷게!!! 따라서 첫번 째 상속 조건인,

서브 클래스에서 지정 초기화를 구현하지 않았다는 건

당연히 먼저

생성자를 작성하지 않아도 모든 프로퍼티가 기본 값을 가질 경우

란 전제 조건이 따름!!!

따라서, 이렇게 지정 초기화를 직접 구현하지 않을 경우엔,

이때는 슈퍼 클래스인 Human의 지정 초기화가 모두 상속됨

이렇게!!

Sodeul 클래스는 생성자를 정의해주지 않았으나,

Human에 정의된 Initializers를 상속받아서 쓸 수 있음!!

자, 생각을 해보자 :)

우리는 앞서 공부할 때 모든 프로퍼티가 기본 값을 가질 경우,

그 경우에 한해서만 Initializers를 필수로 작성하지 않아도 된다고 했음!

자, 그러면 만약 기본 값을 갖지 않는 프로퍼티가 있어서 생성자를 만들어야 한다면??

혹은 난 모든 프로퍼티가 기본값을 갖지만, 생성자를 굳이 굳이 만들어야 겠어!!! 한다면!?!?

이땐 당연히 지정 초기화를 직접 선언 했으니,

부모 클래스의 init(name:) 생성자가 상속되지 않음!!!

2-2. 서브 클래스가 1번 조건에 의해 모든 지정 초기화를 상속 받거나 / 또는 모든 지정 초기화를 오버라이딩 했다면, 자동으로 부모의 모든 편의 초기화가 상속 된다

1번 조건에 의해 모든 지정 초기화를 상속 받는단 말까진 이해 했잖음?

근데 오버라이딩이라니?ㅎㅎ;;

슈퍼 클래스의 지정 이니셜라이저와 일치하는 이니셜라이저를 만약 서브 클래스에서 작성해야 된다고 해보셈,

이때 우린 당연하게 override를 생각할 거잖음??

class Human {
    var name: String
    
    init(name: String) {
        self.name = name
    }
}
 
class Sodeul: Human {
    var nickName: String = "Sodeul"
    var age: Int?
    
    override init(name: String) {
        super.init(name: "")
    }
}
 

이땐 당연히 생성자 앞에 override를 사용해서 오버라이딩을 사용할 수도 있음 :)

물론 이때도 당연히 super.init을 호출해줘야 에러 안남^^;;;;

쨌든 이런 식으로 부모 클래스의 모든 지정 초기화를 상속받거나,

위처럼 부모 클래스의 모든 지정 초기화를 오버라이딩 해서 구현 했다면

이땐 부모의 모든 편의 초기화 메서드가 상속됨!!!

class Human {
    var name: String
    
    init(name: String) {
        self.name = name
    }
    
    convenience init(unknown: String) {
        self.init(name: unknown)
    }
}
 
class Sodeul: Human {
    var nickName: String
    
   override init(name: String) {
      nickName = name
       super.init(name: name)
    }
}
 

예로,

위 코드처럼 Sodeul이란 클래스는 슈퍼 클래스의 모든 지정 초기화를 오버라이딩 했잖음!?

근데 이런 경우엔, 지정 초기화 외에도

Human 클래스의 편의 초기화인 init(unknown:) 도 상속받는단 말임!!

이렇게!!! 편의 초기화도 상속된 것을 볼 수 있음 :)

참고로, 편의 초기화는 오버라이딩 개념이 적용되지 않음

어차피 편의 초기화 자체는 동일 계층으로 수평으로 호출되기 때문에

super.편의 초기화를 호출할 수 없기 떄문에

편의 초기화는 상속은 되지만, 오버라이딩은 안 된 다아아아아아아

호..호.. 저는 이해했는데.. 여러분은 이해.. 하 셨나 ..?

틀린 게 있다면 대왕 지송.;;

피드백 대환영 ;;;..

Swift) 초기화(Initializers) 이해하기 (3/6) - Initializer Delegation

소들이 — Mon, 26 Sep 2022 22:15:50 +0900

안녕하세요 :) 소들입니당

이번 포스팅은 초기화(Initializers) 이해하기 3편~~!!!!

Initializer Delegation에 대해 이해해보려고 합니당

초기화가 처음에 공부하면 어려운 만큼 Delegation을 이해하기 어려울 수도 있는데...!!!

이전 포스팅을 완벽하게 이해 했다면 정말 별 거 없습니당 ㅎ_ㅎ

모든 포스팅은 편의 말투로 합니다~!!

1. Initializer Delegation

Initializer Delegation이란,

생성자에서 또 다른 생성자를 호출하여 초기화 코드의 중복을 최대한 제거하고,

모든 프로퍼티를 효율적으로 초기화 하기위해 사용하는 것입니다

값 형식(구조체)와 참조(클래스) 형식이 다릅니다

을 말 한답니다~

응 이론은 갱장히 쉬워~~

먼저 값 형식과 참조 형식이 다르다고 했는데,

이는 바로 "상속"의 여부가 갈리기 때문임!!

먼저, 값 타입(구조체) 형식부터 보겠음!!

예제로 공부해보쟈 :)

1-1. 값 타입에서의 Initializer Delegation

값 타입의 Initializer Delegation는 엄청 단순함

왜냐? 상속이 없거등!!

자, 먼저 다음과 같은 코드가 있다고 보셈

struct Position {
    var x: Int
    var y: Int
    
    init(xPos: Int, yPos: Int) {
        x = xPos
        y = yPos
    }

    init(pos: Int) {
        x = pos
        y = pos
    }
}
 

이렇게 작성해도 문제는 아님!

근데 위 두개의 Initializer의 경우,

모든 프로퍼티 x, y 값을 초기화 하는 코드를 두 곳 모두에서 작성하고 있으니, 이는 중복된 코드임!!

따라서, 만약 Initializer에서 y는 무조건 0으로 초기화 해줘!! 하고 초기화 구문이 바뀌어야 한다면

struct Position {
    var x: Int
    var y: Int
    
    init(xPos: Int, yPos: Int) {
        x = xPos
        y = 0
    }

    init(pos: Int) {
        x = pos
        y = 0
    }
}
 

이렇게 모든 초기화에 손을 대어, 해당 프로퍼티의 값을 바꿔주어야 한단 말임!!

이는 Initializer Delegation을 따르고 있지 않는 것임

그럼 이는 Initializer Delegation를 따르려면 어케 해야함??

초반에 정의 때 말했잖음!?

생성자에서 "또 다른 생성자"를 호출하여 초기화 코드의 중복을 최대한 제거하자!

따라서 다음과 같이

struct Position {
    var x: Int
    var y: Int
    
    init(xPos: Int, yPos: Int) {
       x = xPos
        y = yPos
    }

    init(pos: Int) {
       self.init(xPos: pos, yPos: pos)
    }
}
 

모든 프로퍼티를 초기화 하는 Initializer를 먼저 하나 만들고,

다른 Initializer가 이 Initializer를 사용하게 만드는 것임!!

이럴 경우, 초기화 코드의 중복도 제거 할 수 있고

만약 초기화 코드를 수정할 일이 있다고 하더라도,

struct Position {
    var x: Int
    var y: Int
    
    init(xPos: Int, yPos: Int) {
       x = xPos
       y = 0
    }

    init(pos: Int) {
       self.init(xPos: pos, yPos: pos)
    }
}
 

위처럼 모든 프로퍼티를 초기화 하는 Initializer 하나만 수정해도 됨!!

Initializer Delegation를 통해서 유지보수가 쉬워진 것임

이것이 바로 구조체에서의 Initializer Delegation임ㅎㅎ

별 거 없음!!

1-2. 참조 타입에서의 Initializer Delegation

참조 타입에서의 Initializer Delegation은 구조체보단 살짝 복잡함

이전에 우리가 공부 했단 내용 몇 가지만 복기하고 가겠음!!

클래스의 생성자는 총 두 가지의 종류가 있다!

Designated Initializers

우리가 아무렇지 않게 init 하고 썼던 초기화로

init 함수가 끝나기 전엔 모든 프로퍼티의 값이 초기화 되어 있어야 한다!

(모든 프로퍼티가 기본 값을 갖거나 옵셔널 타입의 변수로 선언된 경우엔 작성하지 않아도 됨!)

서브 클래스인 경우, super 클래스의 init 메서드를 반드시 호출 해줘야 한다!

Convenience Initializers

Designated Initializers의 초기화를 "보조"해주는 역할의 초기화다!

Designated Initializers의 파라미터 중 일부를 기본값으로 설정해서 호출할 수 있다!

이 Convenience Initializers는 반드시 다른 초기화 메서드를 호출시켜주어야 하는데,

이때 다른 초기화 메서드란,

Convenience / Designated든 상관 없이 같은 클래스 내에 있는 초기화 메서드기만 하면 된다

다만!!!!!! 최종적으론 반드시 같은 클래스(계층) 내에 있는 Designated Initializers가 호출되어야 한다!

위 개념만 기억한다면 정말 별 거 없음

클래스의 Initializer Delegation는 다음과 같은 총 3가지 규칙을 따라야 함

1️⃣ Delegate Up

Designated Initializer는 반드시 슈퍼 클래스의 Designated Initializer를 호출해야 합니다

(슈퍼 클래스의 Designated Initializer를 호출하는 다른 이니셜라이저를 호출하는 것도 안 됩니다)

저번에 공부한 내용이라 어렵지 않음 :)

만약 내 프로퍼티만 모두 초기화 시키는 init 함수를 작성할 경우,

내 부모(슈퍼) 클래스의 프로퍼티 중 만약 기본값이나 옵셔널 타입의 변수가 아니라서

초기값을 가지지 않았다면 초기화 안 되는데 어쩔거임

따라서,

슈퍼 클래스의 모든 프로퍼티를 초기화 시키는 Designated Initializer를 반드시 호출 해야함

2️⃣ Delegate Across (1)

Convenience Initializer는 반드시 동일한 계층(클래스)의 initailizer를 호출해야 합니다

이또한 이전 포스팅에서 자세히 공부 했잖음!?ㅎㅎ

convenience Initializers의 가장 큰 핵심은

반드시같은 클래스(슈퍼 클래스X)에 있는 "다른 초기화" 놈을 또 호출시켜야 한단 것임

그것이 convenience든 Designated든!!

3️⃣ Delegate Across (2)

Convenience Initializer는 최종적으로 동일한 계층(클래스)의 Designated initialize를 호출해야 합니다

근데 이제 뭐다?

Convenience Initializers는 Designated Initializers를 "보조"하는 역할이기 때문에

최종적으로는, 같은 클래스 내에 있는 Designated Initializers를 호출 시켜야 함

정리하자면,

Convenience Initializers는 "보조" 생성자이기 때문에, 굳이 모든 프로퍼티를 초기화 할 필요가 없어

그럼 초기화 안 된 프로퍼티가 있으면 어케?

어차피 최종적으로는 같은 클래스 내에 있는 Designated Initializers를 호출 시키기 때문에 문제 없어!

왜냐? Designated Initializers는 모든 프로퍼티를 초기화 시킬테니까!!

Convenience init은 지네끼리 호출하고 난리쳐도

결국 마지막엔 Designated로 귀결 된다!! 하하!

라고 저번 포스팅에서ㅓ 말했삼

정말 어렵지 않죠!?!?!

이렇게 볼 수 있다 :)

저는 처음에 Swift를 딱 공부 할 때

이 망할 Initializer 때문에 정말 머리가 깨지는 줄 알았었어여

처음 접하면 개념이 어렵기도 하구,

네이밍도 어렵고(Designated, Convenienceㅋ) 등등

걍 첨 공부할 때 델리게이션은 뭐 어쩌라고 나중에 공부해라 급

최대한 이해하기 쉽게 쓴 것 같은데,

저도 사람이라 혹시 틀린 내용이 있거나 피드백줄 내용은 꼭 댓글 바랍니다!!

도움이 되셨길 바라며 :)

Swift) 초기화(Initializers) 이해하기 (2/6) - 클래스의 초기화(Designated / Convenience)

소들이 — Thu, 15 Sep 2022 10:33:14 +0900

안녕하세요 :) 코들입니다..

코로나에 걸려 죽다 살아 돌아온 소들이라 볼 수 있습니다

아직도 마지막 잎새마냥 기침하며 포스팅 적는 중..

...뭐야

위 세 줄 쓴 뒤로 3주지남.. 진짜 죽었었나..

쨌든

저번 포스팅에서 구조체의 초기화에 대해서 공부했다면,

이번 포스팅에선 클래스의 초기화에 대해 공부를 해보려고 합니당!!

이전 포스팅에서 초기화가 무엇인지, 어떤 식으로 진행하는지까지 모두 공부 했으니

그것을 안다는 가정 하에 공부해보겠습니당

모든 포스팅은 편의 말투로 합니다~!!

1. 클래스(Class)를 초기화 하는 방법

이전 포스팅에서 초기화의 개념에서 가장 중요한 것이 뭐라고 했음!??!

바로바로

초기화 시점에 모든 프로퍼티들은 기본 값을 가지고 있어야 한다

만약 기본 값이 없는 프로퍼티가 있을 경우, 초기화에 실패하여 인스턴스가 생성되지 않는다

라고 했잖음!?

위 말은 정말 중요하니 생각하며 가봅시당

클래스를 초기화 하는 방법은 구조체랑 똑~~~~~~~같으니

대충 복붙점 해봄

1-1. 선언과 동시에 프로퍼티에 기본값 넣어주기

class Human {
    let name: String = "Sodeul"
    let age: Int = 28
}

위처럼 name이란 프로퍼티에 Sodeul이란 값을, age란 값엔 28이란 값을

직접 선언과 동시에 기본값을 넣어주며 초기화를 해줘버리는 것임

이렇게 선언과 동시에 기본값으로 초기화를 시킬 수 있음!!!

2-2. 프로퍼티 타입을 옵셔널(Optional) 타입의 변수로 설정한다

class Human {
   var name: String?
   var age: Int?
}

위처럼 name, age 값을 옵셔널 타입의 변수로 설정하는 것 또한

초기화를 진행해준 것임

따라서 만약 값이 있을지도 없을지도 모를 경우에는 위처럼 옵셔널 타입으로 설정하면 됨

그러면 초기화를 할때 옵셔널 타입인 name과 age는 자동으로 nil로 초기화가 됨

근데 왜 "변수" 인가요?? "상수"는 안되나염?

class Human {
    let name: String?
    let age: Int?        // error! Class 'Human' has no initializers 
}
 

넹 안 돼염

위 코드처럼 let으로 선언하고 기본값을 안 주면 에러가 뜸

초기값이 없는 name, age를 initializers를 통해 초기화 해야 하는데 initializers가 없어!!! 라고 뜨는 것임

생각해보면 당연한 것 같음

let으로 선언할 경우 옵셔널 타입 프로퍼티 age는 생성자가 불릴 때 nil로 초기화 될텐데,

age란 값은 상수기 때문에 더이상 nil 외에 값을 가질 수 없어서 에러가 나는 것.. 아..닐까..?

(당연하다 해놓고 의문문으로 끝내기ㅎ;; 아니면 피드백 주세여)

따라서 var로 선언하면 문제 없이 nil로 초기화 됨!!!

1-3. init 함수에서 값을 설정해주기

class Human {
    var name: String?
    let nickName: String = "Sodeul"
    let age: Int
    
    init(name: String) {
        self.age = 28
    }
}
 

만약 하나의 프로퍼티라도 기본 값을 지니지 않거나, 옵셔널 타입의 변수가 아니라면

이땐 우린 초기화를 진행하는 함수인 init 함수(생성자)를 통해 나머지 놈들도 초기화를 진행 해줘야 함!

따라서 위처럼 생성자 안에서 해당 프로퍼티들을 초기화 시킬 수도 있음

(만약 모든 프로퍼티가 기본값을 지니거나 옵셔널 타입의 변수거나 해서 초기값을 갖는다면

그땐 생성자를 따로 선언해줄 필요가 없음!)

중요한 건 뭐라구!?!?

init(초기화) 함수가 종료되기 전까진 모든 프로퍼티가 기본 값을 가져야 한다!!!

뭐 위처럼 init 함수에서 파라미터를 직접 받아서 초기화를 진행할 수 있음

쨌든 기본 값을 지정하든, 옵셔널 타입의 변수로 설정하든, init 함수에서 작성하든 셋을 짬뽕해서 쓰든

결론은 모든 프로퍼티는 초기화 시점에 초기값을 갖고 있어야 한다

2. 구조체는 기본값 초기화도 안 하고, init 함수도 안 만들어도 에러 안 나던데 클래스는 에러 나네여?

struct HumanStruct {
    let name: String
    let age: Int
}
 
class HumanClass {         // Class 'HumanClass' has no initializers
    let name: String
    let age: Int
}
 

분명 똑같이 프로퍼티 name, age를 초기화 하지 않은 구조체와 클래스를 만들었을 경우,

클래스만 initializers를 갖지 않는다면서 에러가 남

이 이유에 대해서 이전 포스팅에서 공부 했잖음?

구조체의 경우 초기화되지 않은 프로퍼티를 초기화 시킬 수 있도록

"자동으로" 제공하는 생성자가 있는데, 그것이 바로 Memberwise Initializers 라고 했었음

그러면 클래스는 Memberwise Initializers 제공 안하나요?

넹ㅜ 안 합니다.

따라서 프로퍼티의 초기값를 위에서 공부한 방식으로 지정시켜 주어야 함

3. 클래스의 Initializers

클래스는 initializers를 총 두 가지로 나누어서 볼 수 있음

여기서부터 살~짝 어려울 수 있으니 차근차근 이해해봅시당

3-1. 지정 생성자(Designated Initializers)

클래스의 모든 프로퍼티를 초기화 하는 생성자

엥 우리가 지금껏 init 키워드만 갖고 쓰던 게 모든 프로퍼티를 초기화 하려고 쓴 거 아닌가여?

맞음!! 우리가 그렇게 썼던 모든 생성자의 풀 네임은 지정 생성자(Designated Initializers임!

class Human {
    let name: String
    let age: Int
    
    init(name: String) {
        self.name = name
        self.age = 28
    }
}
 

이런식으로 썼던 위 init 함수를 우린 그냥 init 함수! 초기화 함수! 생성자! 하고 불렀지만

실제 이름은 바로 Designated Initializers임!

이 Designated Initializers의 핵심은 두 가지임

1️⃣ 해당 생성자 메서드가 종료되기 전까지, 생성자 안에 모든 프로퍼티는 "초기값"을 지니고 있어야 한다

한 100번 말한 듯ㅎㅎ;

옵셔널 변수로 선언 되지 않았거나, 기본 값을 갖지 않는 프로퍼티가 있을 경우엔

생성자를 추가하여 초기값을 지정 해줘야 된다고 했음!

2️⃣ 반드시 super 클래스의 생성자를 호출해야 한다

class Human {
    let name: String
    
    init(name: String) {
        self.name = name
    }
}
 
class Sodeul: Human {
    let alias: String
    
    init(alias: String) {             // error! 'super.init' isn't called on all paths before returning from initializer
        self.alias = alias
    }
}
 

Designated Initializers의 핵심 중 또 한가지는,

상속 받은 서브 클래스에서 Designated Initializers를 작성할 경우,

반드시 슈퍼 클래스의 Initializers를 호출해주어야 함!!!

만약 위처럼 내 프로퍼티만 모두 초기화 시키는 init 함수를 작성할 경우,

내 부모(슈퍼) 클래스의 프로퍼티 중 만약 기본값이나 옵셔널 타입의 변수가 아니라서

초기값을 가지지 않았다면 초기화 안 되는데 어쩔겨!!!

class Human {
    let name: String
    
    init(name: String) {
        self.name = name
    }
}
 
class Sodeul: Human {
    let alias: String
    
    init(alias: String) {       
        self.alias = alias
        super.init(name: alias)
    }
}
 

따라서 이렇게 super 클래스의 생성자를 init에서 직접 호출해줘서

부모 클래스의 초기화도 진행해주어야만 에러가 사라짐!

3-2. 편의 생성자(Convenience Initializers)

모든 프로퍼티를 초기화 할 필요 없 는 생성자로, 반드시 다른 초기화를 호출시켜야 한다

이때 슈퍼 클래스의 생성자는 호출 시킬 순 없고,

같은 클래스 내에 있는 Convenience Initializers나 Designated Initializers를 호출 시켜야 한다

최종적으론 같은 클래스 내의 Designated Initializers가 호출되어야 한다

정의 참 어렵다 ㅎㅎ;;

자 좀 더 쉽게 얘기해봅시당

Convenience Initializers란 단어 뜻대로 이해를 해보자면 편의 초기화라는 거잖음?

따라서 이 Convenience Initializers는,

위에서 말했던 모든 프로퍼티를 초기화 해주는 Designated Initializers를 "도와주는 역할"임!!!!!

어떻게!?! Designated Initializers의 파라미터 중 원하는 값을 기본값으로 설정해서!!!

class Sodeul {
    var name: String
    var nickName: String
    
    init(name: String, nickName: String) {
        self.name = name
        self.nickName = nickName
    }
    
    convenience init(name: String) {
        self.init(name: name, nickName: "unknown")
    }
}
 

이런 식으루!!!

convenience Initializers의 가장 큰 핵심은

반드시 같은 클래스(슈퍼 클래스X)에 있는 "다른 초기화" 놈을 또 호출 시켜야 한단 것임

그것이 convenience든 Designated든!!

근데 이제 뭐다?

Convenience Initializers는 Designated Initializers를 "보조"하는 역할이기 때문에

최종적으로는, 같은 클래스 내에 있는 Designated Initializers를 호출 시켜야 함

위 그림과 같이!!

여기까지 정리하자면,

Convenience Initializers는 "보조" 생성자이기 때문에, 굳이 모든 프로퍼티를 초기화 할 필요가 없어

그럼 초기화 안 된 프로퍼티가 있으면 어케?

그건 최종적으로 같은 클래스 내에 있는 Designated Initializers를 호출 시키기 때문에 문제 없어!

왜냐? Designated Initializers는 모든 프로퍼티를 초기화 시킬테니까!!

Convenience init은 지네끼리 호출하고 난리쳐도

결국 마지막엔 Designated로 귀결 된다!! 하하!

따라서 위와 같은 코드를 작성할 수 있는 것!!

convenience init이 또 다른 convenience init을 호출하고,

그 convenience init에선 결국 최종적으로 designated init을 호출함!!

따라서, Convenience init을 사용하려면,

그 전에 먼저 Designated initializers가 필히 구현 되어 있어야 함!

그래야 최종적으로 부를 수 있으니께..

만약, Convenience initializers에서 최종적으로 Designated Initializers를 호출하지 않으면,

에러낭요

+ Convenience Initializers에서는 프로퍼티 값 설정 못하나여?ㅠ

설정하려고 하면 'self' used before self.init call or assignment to 'self' 에러 뜨는데염 ㅠ

위 처럼 에러가 뜰 때는 다른 Initializer를 먼저 불른 후에 접근해주면 됨!!

이런 식으루!! :)

이 이유는 다른 초기화를 부르기 전에 값을 설정하면,

다른 초기화에 의해 값이 덮어씌어지는 문제가 발생할 수 있기 떄문인데

이는 다다음 포스팅 클래스 생성자의 2단계 초기화를 공부할 때 다시 보겠음!!

3. 어려우니께 간단하게 정리

개념이 어려웠을 수 있응께

가장 중요한 핵심 몇 가지만 정리 하고 가겠음

생성자의 역할은, 모든 프로퍼티의 값들을 초기화 하는 것이다!

따라서 하나라도 초기화 되지 않은 프로퍼티가 있으면 안된당! 인스턴스 생성 안 됨!

이때, 클래스의 생성자는 총 두 가지의 종류가 있다!

Designated Initializers

우리가 아무렇지 않게 init 하고 썼던 초기화로

init 함수가 끝나기 전엔 모든 프로퍼티의 값이 초기화 되어 있어야 한다!

(모든 프로퍼티가 기본 값을 갖거나 옵셔널 타입의 변수로 선언된 경우엔 작성하지 않아도 됨!)

Convenience Initializers

Designated Initializers의 초기화를 "보조"해주는 역할의 초기화다!

Designated Initializers의 파라미터 중 일부를 기본값으로 설정해서 호출할 수 있다!

이 Convenience Initializers는 반드시 다른 초기화 메서드를 호출시켜주어야 하는데,

이때 다른 초기화 메서드란,

Convenience / Designated든 상관 없이 같은 클래스 내에 있는 초기화 메서드기만 하면 된다

다만!!!!!! 최종적으론 반드시 같은 클래스(계층) 내에 있는 Designated Initializers가 호출되어야 한다!

으 꽤 기네

길고 길었던 처음 접하면 생각보다 꽤 이해하기 힘든

클래스의 생성자 포스팅 끝!!

근데 아직 클래스의 생성자는 상속이 언제 되냐에 대한 더 어려운 다음 글이 남아있답니다^^

잘못된 내용 및 오타/피드백은 댓글로 달아주세요~~!!

Swift) 초기화(Initializers) 이해하기 (1/6) - 구조체(Struct)의 초기화

소들이 — Tue, 2 Aug 2022 19:50:42 +0900

안녕하세요, 소들입니다! :)

제 포스팅의 시작은 Swift / iOS 기초를 깊게 다지자!! 였는데,

아직 다루고 싶은 글이 너무 많은데 언제부턴가 기초에 대해서는 안 썼더라구요 T.T

그래서 다시 Syntax 관련 포스팅 좀 하려고 합니당!!

뭐 초기화, 프로토콜, 에러 핸들링 등등이 있겠네요!

기초라 생각 하겠지만, 생각보다 우리는 잘 모르고 쓰는 기초의 내용이 많답니다!! :>

먼저는 크게 구조체 / 클래스 초기화에 대해 나눠서 공부할 거예요!

둘은 초기화에 대한 방식이 조금씩 다르거든요!

그리고 나서 failable / required 초기화에 대해 다뤄보겠습니당

제 포스팅을 iOS를 막 시작하신 초보분들이 많이 보시는 만큼

쉽게 풀어쓰려 노력 해보겠습니다 :)

모든 포스팅은 편의 말투로 합니다~!!

1. 초기화(Initializers)란?

구조체 / 열거형 / 클래스의 인스턴스를 생성하는 것이 초기화로,

초기화의 역할은 모든 프로퍼티를 기본값으로 초기화 하는 것이다

인스턴스 내 기본값이 존재하지 않는 프로퍼티가 있을 경우, 초기화에 실패하고 인스턴스는 생성되지 않는다

일단 초기화의 정의부터 보자면 위와 같음!!

가장 중요한 말은 "모든 프로퍼티를 기본 값으로 초기화" 한다는 것임

따라서 만약, 초기화가 끝나는 시점에 모든 프로퍼티가 기본 값을 가지고 있지 않다면

그것은 초기화 실패로, 즉 인스턴스가 생성되지 않음

엥? 초기화도 실패가 될 수 있나여? 라고 생각 하겠지만,

이는 다다음쯤에 공부할 failable 초기화에 대한 얘기니 이건 잠시 접어두고

기본적으로 우리가 선언할 초기화는 failable이 아니기 때문에 초기화가 절대 실패해선 안됨

고로, 초기화 될 때 모든 프로퍼티는 기본 값으로 초기화가 되어 있어야 함

이 말을 염두에 두고 구조체(Struct)의 초기화에 대해 보러가자~~!!

2. 구조체(Struct)를 초기화 하는 방법

2-1. 선언과 동시에 프로퍼티에 기본값 넣어주기

struct Human {
    let name: String = "Sodeul"
    let age: Int = 28
}

위처럼 name이란 프로퍼티에 Sodeul이란 값을,

age란 값엔 28이란 값을 직접 선언과 동시에 기본값을 넣어주며 초기화를 해줘버리는 것임

이렇게 선언과 동시에 기본값으로 초기화를 시킬 수 있음!!!

2-2. 프로퍼티의 타입을 옵셔널(Optional) 타입으로 설정하기

struct Human {
    let name: String?
    let age: Int?
}

위처럼 name, age 값을 옵셔널 타입으로 설정하는 것 또한

초기화를 진행해준 것임

따라서 만약 값이 있을지도 없을지도 모를 경우에는 위처럼 옵셔널 타입으로 설정하면 됨

그러면 초기화를 할때 옵셔널 타입인 name과 age는 자동으로 nil로 초기화가 됨

2-3. init 함수에서 값을 설정해주기

struct Human {
    let name: String
    let age: Int
    
    init(name: String) {
        self.name = name
        self.age = 28
    }
}
 

초기화를 진행 하는 함수를 바로 init 함수라고 함!!!(앞으론 생성자라고도 부름)

따라서 위에서처럼 프로퍼티를 선언할 때 어떤 값을 지정해줄 수도 있지만,

생성자 안에서 해당 프로퍼티들을 초기화 시킬 수도 있음

중요한 건 뭐라구!?!?

init(초기화) 함수가 종료되기 전까진 모든 프로퍼티가 기본 값을 가져야 한다!!!

뭐 위처럼 init 함수에서 파라미터를 직접 받아서 초기화를 진행할 수 있음

3. 저는 지금껏 구조체 만들 때 기본값 초기화도 안 하고, init 함수 안 만들고 썼는데요?

자, 이정도 읽었다면

구조체를 어느정도 좀 칠 줄 아는 분이라면 위 같이 의문이 들어야 정상임

분명 처음에 초기화는 모든 프로퍼티가 값을 가져야먄 초기화에 성공해서 인스턴스를 생성한다고 했는데!!

struct HumanStruct {
    let name: String
    let age: Int
}
 
class HumanClass {              // Class 'HumanClass' has no initializers
    let name: String
    let age: Int
}
 

분명 똑같이 프로퍼티 name, age를 초기화 하지 않은 구조체와 클래스를 만들었을 경우,

클래스만 initializers를 갖지 않는다면서 에러가 남

(클래스는 다음 포스팅에서 공부할 거지만 대충 에러 난다고만 보셈)

앞서 공부할 때 머라고 했음!?

초기값을 갖기 위해선 선언과 동시에 기본값을 갖거나, 혹은 옵셔널 타입으로 선언되어야 한다고 했음

근데 위에서 name, age는 기본 값을 갖거나 옵셔널 타입도 아니네!?!?

따라서 이 경우에는 init 함수를 직접 작성해서, 해당 함수 안에서라도 반드시 프로퍼티 초기화를 지정했어야 했음

근데 그 과정마저 없으니, 당연히 클래스처럼 너 초기화(initializers) 없는데요? 하고 에러가 나는 것이 정상임

근데 왜 클래스만 에러가 날까? 구조체는 왜 안 나!?

이에 대한 답은,

구조체는 Memberwise Initializers 라는 초기화를 기본으로 제공하기 때문임

4. 구조체(Struct)에서만 제공하는 Memberwise Initializers

구조체가 자동으로 제공하는 생성자로,

파라미터를 통해 모든 프로퍼티의 초기화를 가능하게 한다

이게 무슨 말이냐면,

구조체의 경우에는 프로퍼티의 초기화를 따로 지정하지 않을 경우,

초기화되지 않은 프로퍼티를 초기화할 수 있는 init 함수를 자동으로 제공해버리는 것임

이런 식으로!!

인스턴스를 생성하기 위해 init을 할 때 무조건 name과 age를 설정할 수 있도록

위처럼 프로퍼티를 모두 초기화할 수 있는 Initializers를 자동으로 제공하는 것임!!

이해 가져!?!?

근데 이 memberwise initializers에 몇 가지 성질이 있는데 이에 대해 공부해보겠음 :)

4-1. memberwise initializers로 제공되는 생성자의 파라미터는, 프로퍼티가 선언된 순서와 갯수에 맞추어 생성된다. 이때 파라미터의 이름은 프로퍼티의 이름으로 설정된다

struct Human {
    let name: String
    let age: Int
}

Human.init(name: "Sodeul", age: 28)
Human.init(age: 28, name: "Sodeul")          //error!!!
 

초기화되지 않은 프로퍼티의 갯수가 2개(name, age)이니 파라미터로 2개의 값을 받는 것이고,

내가 프로퍼티를 선언할 당시 순서가 name을 먼저 선언하고, 그 뒤에 age를 선언했기 때문에

이때 생성자의 파라미터는 프로퍼티의 선언된 "순서"를 지키기 때문에

age를 name 보다 먼저 파라미터로 가져선 안 됨

또한 내가 name, age란 이름으로 프로퍼티를 선언했기 때문에

파라미터 이름 또한 name, age로 생성됨

4-2. 프로퍼티가 let으로 선언 되어 있고, 이미 초기화가 되어있는 상태면 생성자 목록에서 제외된다

struct Human {
    let name: String = "Sodeul"
    let age: Int
}
 
Human.init(age: 28)

만약 위처럼 name이란 프로퍼티가 let으로 선언되어있고,

초기값을 가지고 있는 경우에는 생성자의 파라미터에서 제외됨

왜냐??

let으로 선언될 경우, 이미 초기값을 가진경우 값을 수정할 수 없기 때문에

어차피 memberwise initializers를 통해 파라미터로 값을 받아도 name이란 프로퍼티의 값을 변경할 수 없기 때문임!!

4-3. 프로퍼티가 var로 선언 되어 있고, 이미 초기화가 되어있는 상태면 해당 프로퍼티를 초기화 하는 생성자와, 제외된 생성자 두 개를 제공한다

struct Human {
    var name: String = "Sodeul"
}
    
Human.init()                    // name이 제외된 생성자
Human.init(name: "Sodeul")      // name을 초기화 시킬 수 있는 생성자

name이란 프로퍼티 하나로 예를 보자면,

name이란 프로퍼티가 var로 선언되어 있기 때문에

초기값을 갖더라도 이니셜라이저를 통해 값을 변경할 수 있어서

이때는, name이란 프로퍼티를 초기화 할 수 있는 생성자 한 개와 초기화 하지 않아도 되는 생성자 한개가 각각 제공됨!

struct Human {
    var name: String = "Sodeul"
    var age: Int
    var alias: String = "Deulso"
}
    
Human.init(age: 28)
Human.init(name: "Sodeul", age: 28)
Human.init(age: 28, alias: "Deulso")
Human.init(name: "Sodeul", age: 28, alias: "Deulso")
 

만약 위와 같이 프로퍼티를 선언할 경우,

저렇게 다양한 memberwise initializers가 제공 된답니당 :)

4-4. 중요 생성자를 "직접" 생성한 경우, memberwise initializers는 더이상 제공되지 않는다

위처럼 내가 구초제 안에 init 함수를 직접 선언해줄 경우,

이땐 더이상 memberwise initializers는 제공되지 않음!!! 중요함!!!

memberwise initializers는 구조체 안에 init 함수를 직접 구현하지 않은 경우에만 제공됨

그럼 나는 만약 직접 init 함수도 구현하고 싶고,

memberwise initializers도 사용하고 싶어ㅠㅠ 하면 어떻게 해야할까?

이때는 extension을 활용하면 됨!!!

struct Human {
    var name: String
    var alias: String
}
 
extension Human {
    init(name: String) {
        self.name = name
        self.alias = name
    }
}
 
Human.init(name: "Sodeul")
Human.init(name: "Sodeul", alias: "Deulso")

이렇게 직접 구현한 init 함수를 extension으로 뺄 경우,

이때는 내가 정의한 init과 memberwise initializers 모두 사용할 수 있음 :)

4-5. 중요 프로퍼티 중 하나라도 private일 경우, memberwise initializers의 접근제어자 또한 private이다

이처럼 선언된 프로퍼티 중 하나라도 private 접근 제어자를 가질 경우,

해당 memberwise initializers 또한 접근 제어자가 private이 됨!!

따라서 내부에서만 사용할 수 있고, 외부에서 더이상 사용할 수 없음

구조체에서의 초기화 포스팅 끝!!

memberwise initializers에 대해 잘 알아둡시당 :)

오타, 잘못된 내용, 궁금증 있다면 댓글 남겨주세요~

아무튼 밴드 연습

소들이 — Mon, 1 Aug 2022 19:26:06 +0900

안녕하세요! 소들이에요 :)
정말 오랜만에 TMI 글을 쓰네요..! 8개월만인가...!?

뭔가 나의 작고 귀여운 블로그였을 땐
어차피 아무도 안 읽는단 생각으로 무지성 글을 썼는데
요즘엔 (살짝?) 부담이 되어 TMI 글은 특히 더 안 쓰게 됐네여 ㅎㅎ

TMI 글 올리면 개발이나 올리지 왜 이딴 글 올려?
하시는 분들이 있을까 해서 많이 참는 중 ㅎ..;;

그래도 다시 나의 소중한 기록장을 만들기 위한 시작!!!
쨌든 오랜만에 연말정산 글에 게시 했던 음악을 좋아하는 6명의 친구들의
엉망진창 밴드 도전기
에 대해 글을 써보려고 합니다

개발 글 아니고 나의 추억, 지금의 기억을 위한 기록이니
자, 여기까지 읽고 나가시면 됩니다!
이제부턴 평어체로 말할거니께!!

.
.

지금 우리 밴드는... ‍♀️
6명 중에 2명이 탈주했다..;; (이것들을 죽여 살려..;;)
대학생 때 친했던 동기들과 술 먹다가? 수다 떨다가? 술 먹고 수다 떨다가?
급작스레 만든 밴드인 만큼 사실 동기도 목적도 정확하지 않았다

그러다보니 회사 이슈, 연습 부족 이슈 같은 문제로 두 명은 보내드렸고..
우린 지금 4인 체제가 되었다
(음악을 좋아하지만 잘하진 못해~!)

문제는 사라져봐야 소중함을 알 수 있는 베이스가 나갔다
개 큰 일이야 정말..
그래서 어떤 사태가 생겼나면, 보컬이 베이스를 메고 노래를 부른다..
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
신개념 밴드~~~~신난닥~~~!!!

ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ
ㅠㅠㅠㅠ 우리 밴드 베이스 구해요 ㅠㅠㅠㅠ
ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

쨌든 다들 한 가지 곡을 오래하는 것을 못해서 (질림 이슈)
여러 가지 곡을 맛만 보고 그냥 졸업 해버리는 사태가 발생
거의 밴드계의 역마살

연습 시작한지 반 년이 넘었는데
내가보기에 한 13910곡 정도 했다..;;
그래서 우리 진득하니 뭐 하나 해보자 하고 정한 곡이 바로

스물 다섯, 스물 하나

우리 밴드가 엉망진창이긴 해도
우리 보컬만큼은 내로라 할 수준이다 이말이야!!
이런 연주에 노래 부르게 해서 미안할 정도..? 다른 곳 가면 행복할텐데..
다른 밴드 가선 말 잘 듣고 건강해야 한다~~!

근데 사실 밴드의 메은은 보컬아님?ㅋㅎㅎ 그럼 된 거 아님?ㅋㅎㅎ

아니 근뎅 뭐 연습 영상이라고 올리지만
3번 째 트라이 영상이라
예.. 뭐 .. 엉망진창입니다

처음 올린 다쓰러져가는 고백보다 더 심할지도?
https://youtu.be/HBOwUApaHqs

스물다섯, 스물하나 뭐 그 언저리

일단 내가 치는 피아노부터 걍 대놓고 틀린다
근데 틀리는 건 둘째치고 초반에 피아노+보컬 부분에서
박자가 도대체 무슨 일인지 모르겠다

난 내가 박치인 줄은 알았지만 이 정도일 줄은 몰랐지~
드럼하는 애가 귀에 메트로놈 좀 심으라 한 게 사실일 줄은 몰랐지~

중후반에 다들 박자 개무시하고 제멋대로 치는 건 그냥 모두의 잘못이라 하자
그건 아마 우리의 잘못일 거야

근데 이런 영상일지라도 올리는 이유는..
잘은 못하지만 우리의 즐거운 20대 후반의 추억을 기록하기 위해?
아님 우리 보컬 개쩐다고 자랑하기 위해?

뭐 다 맞다
근데 사실 가장 큰 이유는 이 노래조차 고이접어 보내드렸기 때문이다ㅋ
우리에게 진득하게 라는 말은 어울리지 않아 (단호)
내가 추천 했던 곡이고, 하는 동안 너무 좋았어서 올려본다

난 요즘 여러 가지 취미 활동을 정말 생산적으로 하려고 노력 중인데
출근 > 퇴근 > 공부 > 운동 > 피아노10% + 게임 90% > 꿀잠
이렇게 하고 있었는데
이젠 게임 시간과 피아노 시간의 비율을 바꿔볼 생각이다
왜냐? 8, 9, 10월 동안 빡세게 원하는 곡을 완성하고 난 후
난 포지션 변경을 할 거니까 ^^ 통기타로!!

우리 집 주변 기타 학원 시세도 다 알아봤다
아주 멋진 곡을 선사해주겠다 다 죽었다

마지막으로..
밴드랑은 좀 동떨어진 얘기 하자면, 처음 블로그 시작할 때..
패기롭게 피아노 곡을 많이 올리고 싶었지만... 그러지 못했다ㅠㅠ
내가 피아노를 전문으로 배운 게 아니라
아 뭐.. 전문.. 으로 8살까지..?
그래서 너무 많이 틀리고 박자도 난리나서 잘 안 올리고 있긴 했는데

이번 만큼은 정말 열심히 연습한 곡이라!!!!!

https://youtu.be/DdQEoW-uMkA

너무너무 좋아하는 곡이기도 하고..

물론 미완성버전이라 엄청 틀리고.. 밴드 하다가 중간에 찍은거라

옆집 밴드 둥둥탁 소리 다 녹음됨ㅋㅋㅋㅋㅋㅋㅋㅋ

그리고 심지어 패달도 망가져서 안 멈춰졌음..ㅎㅎ;; 피아노가 웅웅댄다..

그래도 너무너무 좋아하는 곡이라 중간 완성 버전을 올려본다!!!
(로스트 아크 게임 자체는 사실 캐릭터 1시간 만들고 지쳐서 끔)
완벽하게 치는 날에 꼭 개별 포스팅으로 올릴 예정이다

쨌든 오랜만에 올릴 우리 밴드 글은 이만해서 줄이고
완벽한 곡이 완성되는날 다시 돌아올 것이다 (비장)
이쯤에서 다시 상기시키는

<우리 (엉망진창) 밴드 베이스 구해요>
애들만은 참 착하답니다..

Swift) 범위 연산자( a...b / a..<b / ...a / ~= )

소들이 — Wed, 27 Jul 2022 21:00:37 +0900

안녕하세요~ 소들입니다!!

오늘은 간단한 Swift 문법에 대해 다뤄보려고 합니다

그있잖아여 for-in 반복문 돌리다 보면 보이는

0..<1

0...1

0...

이런 것들에 대해서!

또한 ~= 라는 범위 (확인?) 연산자에 대해서 다루려고 합니당

모든 포스팅은 편의 말투로 합니다~!!

1. 범위 연산자

1-1. 닫힌 범위 연산자(Closed Range Operator)

a...b

a 이상 b 이하

위처럼 시작과 끝이 정해져 있는 범위 연산자로,

그 가운에 ... (점 세개)를 표시함!!

이렇게 할 경우, 위에서 설명한대로 a 이상 b 이하의 범위가 잡힘

만약 1...5 이라는 범위를 정할 경우,

이는

이렇게 양 끝 범위인 1, 5를 포함한 범위연산자란 것!!!

1-2. 반 닫힌 범위 연산자(Half-Open Range Operator)

a..<b

a 이상 b 미만

반 닫힌 범위 연산자처럼 시작과 끝이 정해져 있는 범위 연산자로,

그 가운에 ..< 를 표시함!!

이렇게 할 경우, 위에서 설명한대로 a 이상 b 미만의 범위가 잡힘

만약 1..<5 이라는 범위를 정할 경우,

이는

보통 배열의 마지막 인덱스까지 순회할 때, 배열의 크기 -1 만큼 돌아야 하잖음?

배열은 인덱스가 0부터이기 때문에!!

따라서, 반 닫힌 범위 연산자는 배열을 다룰 때 용이 함

let array: [Int] = [1, 2, 3, 4, 5]
 
for index in 2..<array.count {
    print(array[index])                // 3, 4, 5
}
 

요런 식으루!!

1-3. 단방향 범위(One-Side Ranges)

...a

a...

..<a

단방향 범위 연산자는 앞서 공부했던 닫힌 범위 연산자 / 반 닫힌 범위 연산자를 쓸 때

시작과 끝 범위 중 하나만 정해주는 연산자임

이건 배열로 이해하는 게 훨 쉬울듯!!

let array: [Int] = [1, 2, 3, 4, 5]
 
for element in array[...3] {
    print(element)                    // 1, 2, 3, 4
}
 
for element in array[3...] {
    print(element)                    // 4, 5
}
 
for element in array[..<3] {
    print(element)                    // 1, 2, 3
}
 

위처럼 단방향으로 범위를 정해준 경우,

...3 / ..<3 일 때는

배열에선 최소 범위로 지정할 수 있는 0번 째 인덱스부터 지정된 인덱스(3 or 2)까지 범위가 잡히는 거고

3... 일 때는

지정된 인덱스(3)부터 배열에서 최대 범위로 지정할 수 있는 마지막 인덱스까지 범위가 잡히는 것임!

요런 식으로!!!

왜 이아이만 배열로 예를 드냐면,

위처럼 설정할 경우,,,,,, 시작 범위가 없기 때문에

어디서부터 범위가 시작되어야 할지를 알 수가 없엉...

(배열의 경우는 무조건 0번이 시작 범위이기 때문에 가능했던 것)

.. 뭐 그에 따라서 에러가 뜸

반대로,

시작범위가 다음과 같이 양수로 정해진 경우에 단방향 범위를 쓰면

시작 범위는 잡혀서 에러가 뜨진 않지만..

끝 범위가 정해져 있지 않아, 범위 자체가 5 ~ 무한대로 잡히기 때문에,,

몇초 사이에 5785번 실행해버림;;

위처럼 사용한느 것은 미친짓입니다.. 하지마십셔,,,;;

2. ~= : 범위 안에 값이 속하는지 확인하는 연산자

~= 연산자는 범위 안에 해당 값이 속하는지 확인하는 연산자로,

리턴 값은 Bool이다

나는 생각보다 위의 연산자를 사용하는 것을 많이 본 적이 없는데,

예로 보여드리자면

let range = 1..<5
 
range ~= 1      // true
range ~= 5      // false

위처럼 쓸 수 있따

~=는 잘 몰랐던 연산자인데, 사용할 일이 있으면 유용할듯 합니당 :)

잘못된 내용 및 피드백 댓글 대환영!!

Swift) closure와 @escaping 이해하기

소들이 — Mon, 18 Jul 2022 19:13:54 +0900

안녕하세요? :> 오랜만입니다

오랜만인 이유는 5, 6월 현업이 매우매우x100 바쁘기도 했고,

그에 따른 번아웃이 온 건지,, 한 달정도 공부에 대한 반항을 좀 해서,, ㅎㅎ;;

쨌든 다시 정신 차리고 돌아왔습니당

우리 블로그,, 정상영업 합니다,,

오늘 포스팅은 오랜만에 Swift에 관련된 거예요!

closure와 escaping은 예전 closure 포스팅에서 다룬 적이 있지만,

이 파라미터로 전해지는 closure가 optional로 감싸지는 순간 얘기가 달라지거등여

이 부분에 대해 공부를 해볼 예정입니당!!

먼저, closure와 @escaping이 무엇인지,

@escaping을 왜 쓰는지에 대해서는 적어도 사전 지식이 있어야 해요!

모르신다면 이 포스팅과 이 포스팅을 꼭 보고 오시길 바라곘습니당

그럼 안다는 가정 하에 공부하러 가봅시당 :D

모든 포스팅은 편의 말투로 합니다~!!

1. 클로저에서 @escaping은 언제 붙일까?

사실 위에서 포스팅 읽고 오라고 했지만 ㅎ^ㅎ

안 읽고 온 누군가를 위해 덧붙이자면,

다음과 같은 코드가 있음

func sodeul(completion: () -> ()) {
    completion()
}
 

이때 위 코드에서 completion이라는 매개변수의 타입은

매개변수가 없고, 리턴 타입도 없는 () -> () 이라는 함수 타입임

어떻게 파라미터로 클로저를 받을 수 있는 걸까?

Swift에서 클로저는는 1급 객체니까!!ㅎㅎㅎ

변수나 상수에 대입 가능! 파라미터 인자로 넘겨주기도 가능!

실제로 사용할 땐 이렇게 하잖음?

sodeul {
    print("hungry ")                         // hungry 
}
 

이렇게! 매개변수로 함수를 넘겨줄 수 있고,

실제로 그 매개변수로 넘겨준 함수가

sodeul이란 함수 내부에서 completion이란 매개상수로 저장되어 사용 되잖음!?

(위 문법이 어렵다면 trailing closure를 공부해주세영)

자, 근데 다시 함수 선언부로 돌아가서

내가 매개변수로 받은 completion에 저장된 클로저를 3초 후에 실행시키고 싶음

따라서 다음과 같이 코드를 짜주면

func sodeul(completion: () -> ()) {
    DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
        completion()
    }
}
 

이렇게 짤 경우,

이런 에러가 뜸

왜 이런 에러가 뜨냐!?!?

우리가 일반적으로 위처럼 아무런 키워드 없이 파라미터로 받는 클로저는

모두 non-escaping closure임!!

이름 그대로 탈출이 블가능한 클로저임

함수의 "흐름"을 탈출하지 않는 클로저란 뜻으로,

한 마디로 함수가 종료되고 나서 클로저가 실행될 수 없다는 말임

함수가 종료될 때 클로저의 사용도 같이 종료되어서 같이 ㅃㅃ 해야하는 것임

근데 위 함수 같은 경우는 asnyc로 3초뒤에 클로저를 실행되게끔 해버렸음

그러면 어떻게 되느냐

당장 completion은 에러가 뜨니, 위처럼 print 함수로 예를 보자면,

함수 내부에서 3초 뒤에 실행되는 Async Task( )를 줘버렸기 떄문에

이론상 함수의 생애주기가 완전 끝나버렸지만, 그 이후에 해당 작업이 실행되게 됨

이것이 바로 함수의 흐름을 탈출한 상황인데,

3초 뒤에 실행되는 Async Task( )를 completion으로 다시 바꾼다 생각해보셈

completion은 함수가 끝나기 전에 실행이 모두 종료되어야 하는데,

함수의 흐름을 벗어나 호출되어야 하기 때문에 이는 non-escaping parameter가 아니야!

하고 에러가 생긴 것임 오키!?

따라서 non-escaping closure의 경우

함수 내부에서 직접 실행하기 위해서만 사용한다

따라서 파라미터로 받은 클로저는 변수나 상수에 대입할 수 없고,

중첩 함수 내부에서 클로저를 사용할 경우, 중첩함수를 리턴할 수 없다

함수의 실행 흐름을 탈출하지 않아, 함수가 종료되기 전에 무조건 실행 되어야 한다

이런 특징들을 가지고 있음

그럼 파라미터로 받은 closure는 비동기로 사용못해!?? 함수 흐름 탈출 못해!?!?

할때 사용하는 키워드가 바로

@escaping

임!! :)

func sodeul(completion: @escaping () -> ()) {
    DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
        completion()
    }
}
 

이런 식으로 함수의 타입 선언하기 전에

@escaping이란 키워드를 붙여주면,

이 클로저는 함수의 실행 흐름에 상관 없이 실행되는 클로저다!라고 알려주는 것임

따라서 실행해보면 에러 없이 completion이 잘 실행됨!

가 먼저 실행되고, 3초 뒤에 가 실행 될 것임!

이것이 바로 @escaping 이랍니다 :)

2. 클로저를 Optional Type으로 선언하면 말이죠

근데 있잖음 파라미터로 받을 클로저가 있을 수도, 없을 수도 있잖음?

따라서 다음과 같이 클로저를

func sodeul(completion: @escaping (() -> ())?) {
    DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
       completion?()
    }
}
 

위처럼 옵셔널 타입으로 감싸서 선언해주면 말이셈

클로저가 이미 escaping이니 @escaping을 삭제하라 함

따라서 fix 버튼을 누르면 말이셈

func sodeul(completion: (() -> ())?) {
    DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
       completion?()
    }
}
 

???

분명 똑같이 함수의 흐름을 탈출해서 3초뒤에 실행되는 클로저임에도 불구하고

@escaping이 사라짐!! 왜 이난리 ㅎㅎ;

따라서 이 난리의 이유에 대해 알아보기 위해 쓴 글임!

3. 파라미터 타입이 Optional Closure일 경우, 더이상 Closure 파라미터 타입이 아닌 Optional 파라미터 타입이다

이게 무슨 말인지 알아보기 위해,

먼저 Optional Closure가 아닐 경우의 파라미터 completion의 타입을 보겠음!!!

이때 completion이라는 매개상수의 파라미터 타입은

() -> ()로 함수 타입 즉, "클로저 타입"임

근데 옵셔널을 붙이면 어떻게 될까?

optional을 붙이는 순간 completion의 타입은

(() -> ())?가 되며, 이는 더이상 클로저 타입이 아님

() -> ()라는 함수 타입을 제네릭 함수의 Type Parameter로 받은 "옵셔널 타입"임!!

이해가 안 갈 수도 있을 것 같은데,

가장 대표적인 제네릭인 Array를 생각해보셈!!!

Int와 Array<Int>는 서로 완전히 다른 타입이잖음??

그와 마찬가지로 함수 타입인 ()->()와,

이 함수 타입을 옵셔널로 감싼 (() -> ())?는 서로 완전히 다른 타입임!!!!

예전에 옵셔널을 공부할 때 Optinal을 선언하는 순간,

Optional이라는 "포장지"가 씌워지는 것이기 때문에

더이상 String 타입이 아닌, Optional<String> 타입이라고 말 했음!!

따라서 사용할 때도 Optional Binding을 통해 포장지를 벗겨줘야 했잖음??

이런 관점에서 보면 이제 이해가 감?

함수 타입을 제네릭 타입인 옵셔널로 감싸버렸기 때문에,

더이상 함수(클로저) 타입이 아니여서

기본적으로 파라미터로 받는 "클로저"는 함수 흐름을 탈출하지 못한다

위 조건에서 "클로저"조건이 벗어나버린 것임!!!!

근데 이렇게 함수 파라미터의 클로저가 Optional Type인 경우엔

자동으로 escaping으로 동작하나봄!! 따라서 @escaping을 지우라는 듯..?

(제가 잘못 이해한거라면 말씀.. 주세.. 여..)

4. 자동으로 escaping으로 동작하기 때문에, @escaping을 붙이지 않아도 정상 작동합니다

제목이 즉 결론임!!

위에서 completion이란 클로저는 함수의 흐름을 탈출하여 실행되지만,

Optional Type으로 된 Argument이기 때문에

@escaping이란 키워드를 붙여주지 않아도, 자동으로 escaping으로 동작 된답니당 :)

너무 오랜만에 글을 써서 마음에 들진 않지만.. :)

앞으로는 다시 회사의 등대가 되어 열심히 공부하며 글을 써보도록 하겠습니다!

아마 디자인 패턴에 관한 글도 많이 올라올 것 같은데 ㅎㅎㅎㅎ

쨌든 만약 잘못된 내용이나 피드백 있으면 댓글 주세요!!

SwiftUI) VStack에 Spacer 썼을 때 Safe Area까지 확장되는 이슈

소들이 — Sun, 29 May 2022 20:42:07 +0900

안녕하세요 소들입니다~.~

이번 포스팅은 매우 간단하게 하려고 합니당!!

저번 포스팅에서 Spacer에 대해 공부를 해보고 몇 번 사용해봤다면,

이거 왜 이모양이야? 싶은 의문이 들 부분이 있기 때문에

그 의문에 대해 해결해보려고 합니다!

Spacer가 아닐 때에도 혹시 이런 모습이 나타난다면..(?) 언젠진 모름

쨌든 그럴 때도 사용해보셈

모든 포스팅은 편의 말투로 합니다~!!

1. VStack에서 Spacer를 추가하면...

넹,,, 이렇게 사용 가능한 공간을 다 띄워버리는 Spacer는

Safe Area는 개나 줘버린답니다..~~~

근데 애플의 가이드라인에는 Safe Area를 준수하라고 돼있잖음?

따라서 View를 배치할 때 Safe Area까지 확장되지 않는 두 가지 방법을 보여주겠음!!!!

2. Safe Area로 확장되지 않는 방법

2-1. Safe Area를 침범하는 영역에 높이가 1인 Spacer를 추가한다

이게 무슨 말이냐면,

이렇게 가장 위 / 아래에 height가 1인 Spacer를 추가해주면,

Safe Area까지 확장되지 않음!!

참고로 frame height 0주면 주나 안 주나 똑같이 Safe Area까지 확장됨!!!

0이 아닌 값으로 알아서 주세영 :)

2-2. VStack에 padding을 추가해준다

이런 식으로 VStack에 padding modfier를 추가해주면,

top, leading, bottom, trailing 모두에 한해서 Safe Area를 지켜 줄 수 있음!!!

회전 해보면,

leading / trailing에 대해서도 잘 들어감!!!!

오늘은 간단한 포스팅 끝 :)

오타나 틀린점 지적 대환영입니다~

SwiftUI) Spacer(스페이서)를 알아보자

소들이 — Sat, 28 May 2022 22:47:32 +0900

안녕하세요, 소들입니다 ...

글을 오랜만에 쓰네요...

일주일에 1개는 꼭 쓰겠다고 다짐해놓고 무슨 일이냐고 하면,

뭐,, 네,, 회사 재택이 끝났습니다..ㅎ;;

사실 그거도 그거지만, 5월에 지금 현업 하는 게 너~~무 바빠서ㅜㅜ 정신이 없네요...;;;;

쨌든 이번 포스팅에서는 SwiftUI의

Spacer

라는 객체에 대해 알아볼 거예요!!!!

어렵진 않으나,, 처음엔 헷갈릴 수 있으니 차근차근 이해해 봅시당!! :)

모든 포스팅은 편의 말투로 합니다~!!

1. Spacer는 어떨 때 쓰나요?

자, Spacer의 애플의 정의를 먼저 보자면,

포함하는 스택 레이아웃의 주요 축을 따라 확장되거나,

스택에 포함되지 않은 경우, 두 축 모두에서 확장되는 유연한 공간

나는 리얼 애플 정의가 세상에서 제일 어려워

여러분 우리가 타자칠 때 글자 사이를 띄우고 싶을 때 스페이스 바를 치잖음??

마찬가지로, View 간의 간격을 "띄우고 싶을 때" 사용하는 것이 바로 Spacer임!

바로 사용법부터 보자!!

자, 만약 위처럼 두 개의 Text의 HStack안에 들어 있음

이미 두 Text 사이에 일정 간격이 존재하는데요? 라 생각 할 수 있지만,

이는 이전 공부할 때 배웠듯이

HStack이라는 스택이 View를 배치할 때 사용하는 자체 Spacing이 있다고 했음!

(따로 설정하지 않을 시 default 값으로 설정 되지만, 그게 0일 수도 아닐 수도 있음)

따라서 만약 Spacing을 0으로 주면 이 두개의 Text가 붙어버림

이렇게!!!!

자, 근데 이렇게 둘이 챱! 붙어 있는 상태에서

나는 저 두 Text 사이에 스페이스바를 누르고 싶어! 둘 사이를 띄어주고 싶어! 란 생각이 들면,

이렇게 두 개의 Text 사이에 Spacer()라는 것을 써주면 됨!!!

그러면 Preview에 나온 것처럼 저 둘은 저렇게 완전 띄어지게 됨

으아니 나는 스페이스바 한번처럼 조금만 띄우고 싶은데?

할 수도 있겠지만, 이렇게 띄워버리는 것이 바로 Spacer의 특징임

Spacer는 기본적으로 사용 가능한 전체 공간을 띄워버림

무슨 말이냐면, 현재 Text가 갖는 크기가 있을 거 아님?

그 크기를 제외하고 남은 여백을 다 띄워버린단 말임

그래서 저런 모양이 나와버린 것!

일단 Spacer가 무엇인지에 대해 대충 감이 왔길!

2. Spacer를 중복해서 사용하면

자, 위 예제에서 만약 blue Text 뒤에도 Spacer를 써봤음

그럼 어떠케 되냐면

이렇게 됨

자 어떻게 이해를 하면 되냐면

아까 Spacer는 기본적으로 "사용 가능한 전체 공간을 띄움"이라고 했잖음?

근데 지금 HStack 안에 총 Spacer가 몇 개 있음? 2개 있잖음!!!

따라서 사용 가능한 전체 공간을 2등분을 해버리고,

각각 yello Text 뒤에 그 공간만큼 여백 하나, blue Text 뒤에 그 공간만큼 여백 하나

이렇게 사이좋게 같은 크기의 여백들이 붙어버린 것임

따라서,

Spacer를 n개 선언한다면, Spacer가 띄우는 크기가 n등분 되어버리는 것임

만약 yello Text 앞에도 Spacer를 붙인다면?

Spacer가 총 3개가 되었으니, 띄울 수 있는 공간을 3등분 하여

각각 Spacer가 선언된 위치에 들어가게 된 것임!!!

(yellow Text 앞 / 뒤에 하나씩, blue Text 뒤에도 하나!)

3. Spacer의 여백 크기를 바꾸는 방법

자, 위에서 공부한 걸로 봤을 때 Spacer는

사용 가능한 전체 공간을 띄워버리기 때문에

사용 가능한 공간이 얼마나 있냐에 따라 / 또 Spacer를 몇 개 선언했냐에 따라

Spacer로 인해 띄워지는 여백의 크기가 유동적이었음

그래서 이번에 공부할 것은

Spacer의 여백 크기를 내가 지정한는 방법임

3-1. minLength 파라미터 사용하기

Spacer를 생성할 때 위에서 썼던 것처럼 파라미터를 전달하지 않아도 되지만,

위처럼 파라미터로 minLength라는 값을 지정할 수 있음!!!

만약 다음과 같이

두 Text의 사이의 Spacing의 minLength 값을 100으로 줘버리면,

ktx타고 가면서 봐도 100보단 커보이는 듯한 여백

리신이 봐도 minLength 주든 안 주든 똑같아 보이는 여백

그 이유라 함은 파라미터 이름부터 "minLength"인 것처럼

이때 설정하는 값은 "Spacer가 가지는 여백의 최소 보장되는 크기"임!!!

따라서 위처럼 Spacer의 여백이 100보단 클 경우엔 무시되어 버리고,

이렇게 만약 여백의 크기가 100보다 작아야 하는 경우,

이때는 Spacer의 여백이 최소 100은 보장됨!!

자 Spacer의 최소 여백을 설정하는 것이 minLength라고 했잖음?

Spacer의 minLength를 지정하지 않고 넣어도

blue Text의 뒤를 보면, 아주 살짝의 여백은 들어감!!

Spacer의 minLength를 설정하지 않았다 하더라도,

확장될 공간이 없다고 해서 아예 안 들어가지는 않고, System의 기본 여백인 저만큼은 들어감

3-2. frame modifier를 이용하여 Spacer 여백의 크기를 지정

만약 유동적인 Spacer의 여백이 맘에 안들어! 직저 지정해줄래!!! 한다면

위처럼 Spacer에 대고 frame modifier를 호출하면

지정된 크기의 여백을 줄 수 있답니당 :)

도움이 돠었길 바라며 :)

오타 및 피드백 대환영~!!

SwiftUI) Stack을 알아보자(HStack / VStack / ZStack)

소들이 — Tue, 19 Apr 2022 18:23:54 +0900

안녕하세요! 소들입니당!! XD

이번 포스팅은 SwiftUI에서 정~~말 많이 사용하는 Stack에 대해서 공부해볼 거예요!

참고로 정말 어렵지 않습니다!!!!!!!! 예전 스택뷰와 비슷한점이 많아서 :)

그럼 얼른 공부하러 가봅시다!!!

왜냐면 얼른 공부 끝내고 운동하러 가야하니께!!!

모든 포스팅은 편의 말투로 합니다~!!

1. Stack은 어떨 때 쓰나요?_?

이전 포스팅들을 보신 분들이라면 알 수 있는 답이겠지만..ㅎㅎ

복습한번 하고 갑시당

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
            .padding()
    }
}

이렇게 View 프로토콜을 채택한 경우,

최상위 View 역할을 할 body라는 연산 프로퍼티를 필수적으로 구현해줘야 하는데,

이때 body라는 프로퍼티의 타입이 some View, 즉 불투명타입(Opaque Type)이라서

내부에서 View를 준수하고 있는 객체면 어떤 객체든 리턴이 가능하지만,

"단 한개의 View"만 리턴을 해야된다고 했음 ㅎㅎㅎ

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
        Text("Hello, world!2")
    }
}

만약 이렇게 body 안에 두개의 Text를 위처럼 써버린다는 것은,

Text라는 두 개의 View를 리턴한다는 말이 되고

시뮬레이터로 돌릴 땐 알아서 잘 나오지만,

whyrano..

프리뷰가 쌍둥이 되는 문제가 있었음

(예전엔 아예 빌드도 안 됐다고 함 ㅎ;;)

따라서!! 만약 한 개 이상의 View를 리턴하고 싶을 경우,

SwiftUI에선 이 View들을 하나로 컨테이너(?)로 감싸주어야 함

그럴 때 사용하는 게 머다??

Stack

Group

...

등등이다!!!

따라서 한 개 이상의 View를 묶어서 배치할 때 사용할 수 있는 것 중에 하나가

바로 Stack이라는 것임!!!

근데, 이 Stack엔 총 3가지가 있어서 이제 그 3가지 종류에 대해

알아보도록 할 것임 ㅎ^ㅎ

(Lazy Stack이란 것도 있는ㄷ ㅔ요건 나중에 따로 포스팅!)

2. HStack / VStack / ZStack

2-1. HStack

내부에 선언된 View들을 Leading에서 Trailing으로 배치한다

자 H에서 Horizontal의 냄새가 나지 않음?ㅎㅎ

HStack은 View를 "수평"으로 배치해주는 View임!!

근데 이제 배치 방향이 Leading -> Trailing 순인..

위에서 Text를 두개 리턴해서 문제가 된 코드를

HStack을 이용해서 어떻게 바꿔주면 되냐면,

struct ContentView: View {
    var body: some View {
        HStack {
            Text("소들")
                .background(.red)
            Text("추운 소들")
                .background(.yello)
            Text("춥고 배고픈 소들")
                .background(.blue)
        }
    }
}

이렇게 HStack이란 것으로 한번 감싸주기만 하면 됨!!!

그러면 프리뷰가 더이상 멍청해지지 않고,

이렇게 내가 내부에 선언해준 Text를

Leading에서 Trailing으로 순서대로 수평으로 배치해줌!!!

2-2. VStack

내부에 선언된 View들을 Top에서 Bottom으로 배치한다

자 V에서 Vertical의 냄새가 나지 않음?ㅎㅎ

VStack은 View를 "수직"으로 배치해주는 View임!!

근데 이제 배치 방향이 Top -> Bottom 순인..

struct ContentView: View {
    var body: some View {
       VStack {
            Text("소들")
                .background(.red)
            Text("추운 소들")
                .background(.yello)
            Text("춥고 배고픈 소들")
                .background(.blue)
        }
    }
}

이또한 마찬가지로 이렇게 VStack으로 감싸주면,

이렇게 내가 내부에 선언해준 Text를

위에서 아래로 순서대로 수직으로 배치해줌!!!

2-3. ZStack

내부에 선언된 View들을 겹쳐서 두 축으로 배치한다

??ㅋ

쉽게 말해 내가 보고 있는 화면의 방향으로 뷰를 배치한단 것임

예제로 보는 게 훨씬 쉬우니

struct ContentView: View {
    var body: some View {
      ZStack {
            Text("소들")
                .background(.red)
            Text("추운 소들")
                .background(.yello)
            Text("춥고 배고픈 소들")
                .background(.blue)
        }
    }
}

이또한 마찬가지로 이렇게 ZStack으로 감싸주면,

엥?? 마지막 Text밖에 안 나오는데요?? 싶지만

자, 여기서 사라진 두 개의 Text들의 크기를 더 키워준다면

이런 모양이 됨!!

겹쳐서 배치한다는 게 이해가 가나연??

Text 크기가 다 똑같았을 땐 "춥고 배고픈 소들"이 가장 긴 길이를 가져버려서

좀 더 뒤에 배치되어 있던 "소들", "추운 소들" 두 Text를 "가려버렸던 것"임

참고로 먼저 선언해주는 View일 수록 겹쳐졌을 때 뒤에 배치됨

(그 키노트 쓸때 맨뒤로 보내기 그런 느낌)

3. Stack에서 사용할 만한 modifier

3-1. Stack의 크기 변경하기

Stack의 크기는 내부 뷰를 표시하기 위한 최소한의 크기로 표시된다

이런 식으로!!!

내부 뷰의 크기가 다를 경우,

너비 or 폭이 가장 큰 놈에 의해서 프레임이 맞춰짐!!

(이에 대한 정렬 내용은 바로 다음에 다룰테니 좀만 기달)

따라서 만약, Stack의 Frame을 직접 지정해주고 싶을 경우

이렇게 .frame이라는 modifier를 이용해서 직접 설정해줄 수 있음!!

3-2. Stack 내의 정렬 방식(alignment) 변경하기

위에서 프레임의 경우,

내부 뷰의 너비 or 폭이 가장 큰 놈에 의해서 프레임이 맞춰진다 했잖음!?

따라서 다음과 같이 VStack이 있다고 할 때

"춥고 배고픈 소들" Text의 너비에 의해 스택의 너비가 결정되어,

나머지 Text들이 모두 "가운데 정렬" 되어버린 것임

왜냐? Stack들은 기본 정렬이 .center이기 때문임!!!

따라서 이를 만약 바꿔주면, 실제 정렬도 바뀌게 되는데,

Stack을 생성할 때 파라미터 값으로 alignment를 직접 설정해 줄 수 있음!

참고로 VStack의 경우 trailing / leading / center 총 세가지가 있는데,

이를 만약 trailing으로 바꿔주면,

이렇게 나머지 Text들의 정렬이 .trailing쪽으로 바뀜!!

이건 Stack의 종류에 따라 정렬 방식이 각기 달라지는데,

이런 식으로 있으니 상황에 맞게 잘 정렬 해보셈!!

3-3. Stack 내의 여백(spacing) 크기 변경하기

Stack 내부 뷰 간격 간의 여백을 지정하는 spacing이란 파라미터의 기본 값은 nil인데,

이때 nil은 0이 아니라 기본 값이다

아까 예제를 보자면, Stack에 대한 여백 값을 따로 지정해주지 않으면,

VStack의 경우

이렇게 여백, 즉 spacing이 없어보게 나와서

기본 spacing 값이 0이다!! 라고 생각할 수 있지만,

HStack을 보면,

이렇게 기본 spacing 값이 0이 아님!!!

따라서 만약 여백을 직접 설정하고 싶거나, 아예 없애고 싶으면 정렬과 마찬가지로

Stack을 생성할 때 파라미터 값으로 spacing을 설정해 줄 수 있음!

이런 식으로!!

(0을 전달하면 여백이 없어진답니다!!!)

잘못된 내용이나 궁금증은 피드백 바랍니다 :)

SwiftUI) ContentView 이해하기 (2/2) - ContentView 사용하기

소들이 — Mon, 11 Apr 2022 20:42:31 +0900

안녕하세요!! 소들입니다 :D

이번엔 ContentView 이해하기 2편입니당!!!

1편이 생각보다 되게 내용이 깊고 어려웠어서.. 이해하기 힘들었을 거 같은데

(Opaque Types에 대해 아직 내용 추가할 게 산더미;;)

그 산만 잘 넘었다면 이번 포스팅은 매우 간단하고 쉽고 짧습니다! :)

가볍게 읽어주세요!!

모든 포스팅은 편의 말투로 합니다~!!

1. ContentView는 뭐 하는 애일까?

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
            .padding()
    }
}

맨 처음 프로젝트를 생성하면 나오는 구조체잖음?

우리가 지금껏 ViewController 혹은 View에서 화면을 그리고

변수를 생성하고 어쩌고 하던 작업들을

이 ContentView라는 구조체의 부에서 한다고 생각하면 됨!!!

다만, 이때 View라는 것은 이전 포스팅에서 공부 했듯이,

프로토콜로 구현되어 있고, body라는 프로퍼티를 갖고 있음!!

(상속이 안 되는 구조체에서 채택하는 것을 보면 당연히 프로토콜임!)

따라서 View를 채택하고 있는

ContentView 구조체 안에 body라는 프로퍼티는 당연히 있어야 되고,

이 body가 바로 ContentView의 최상위 View의 역할을 하는 것임!!!

참고로 이 body는 연산 프로퍼티(computed property)로 구현하면 됨!!

맨 첨에 봤던 코드처럼,

ContentView에서 최상위 View 역할을 하는 body 안에 Text라는 것을 넣을 경우,

(Text는 SwiftUI에서의 Label이라고 생각하셈)

이렇게 화면에 View가 그려지게 되는 것임!!

그럼이제 ContentView의 몇 가지 속성에 대해 알아보자 :)

2. ContentView 이해하기

2-1. body는 단 한개의 View만 반환해야 한답니다

body 연산 프로퍼티는 단 "한 개"의 View만 리턴해야 함!

따라서 만약 다음과 같이 Text를 두개 쓸 경우,

struct ContentView: View {
    var body: some View {
        Text("Hello, Sodeul!")
        Text("Hello, DeulSo!")
    }
}

시뮬레이터로 돌리면

아무 문제 없는데용?? 잘나오는데용??

싶겠지만,

프리뷰가 쌍둥이가 되고요

따라서, 만약 이렇게 여러 개의 배를 배치하고 싶을 땐

차근차근 포스팅 할 예정인

Stack / Group 등등..을 사용해서

여러 개의 뷰들을 하나의 뷰로 감싸줘서 하나의 View로 리턴해야 함!!!

이런 식으로!! :)

실제 위 코드에서 body의 타입은

VStack<TupleView<Text,Text>>으로 VStack이라는 하나의 View로 반환되는 것임!

다만 우린 위의 복잡한 타입에 대해 알 필요 없고 명시할 필요도 없다! 왜 와ㅏ이?

body가 some View 즉, 불투명 타입을 리턴하니까! 하하

2-2. ContentView에 변수나 상수를 추가하고 싶으면 어떻게 하나요?

원래 해주던 것 처럼 해주시면 됩니다ㅋㅎㅎㅋ

이런 식으루!!

body에서 물논 사용 가능 함 :)

2-3. View의 생애주기를 관리하고 싶다면 어떻게 하나요?

그.. UIKit으로 개발할 때 사용하는 View Controller의 생애주기 있잖음?

ViewDidAppear

ViewDidDisappear

...

등등.. 이런 거 어떻게 사용하냐면

onAppear

onDisappear

라는 modifier를 이용하면 됨!! :)

struct ContentView: View {
    var name = "Sodeul"
    var body: some View {
        VStack {
            Text("Hello, \(name)!")
            .onAppear {
                print("Text가 보입니다!!")
            }
            .onDisappear {
                print("Text가 사라집니다!!")
            }
        }
    }
}

위와 같이 modifier를 이용해서

onAppear / onDisappear를 달아줄 수 있음!!

실제 시뮬레이터로 실행시켜 보면,

이렇게 잘 작동 한답니다 :)

+ 참고로

위의 body 프로퍼티는 View가 생성되고 한 번만 만들어지는 게 아니라

View의 Life Cycle 동안 필요할 때마다 여러 번씩 새로 만들어져서 리턴됨

(이 부분에 대해선 나중 포스팅에서 볼게욥!)

그럼 성능에 ㄱㅐ문제있는 거 아닌가요? 싶겠지만,

SwiftUI에선 View 자체가 클래스가 아닌 구조체로 매우매우 가볍기 때문에

말단 개발자인 우리가 걱정할 문제가 아니라고 한다^^;;

SwiftUI ContentView에 대해 이번엔 아주 가볍게 기본에 대해 알아보았으빈다

다음엔 어떤 내용일지 하하 고민좀 해보겠음

오타 및 잘못된 내용 피드백 대환영입니다!!

SwiftUI) ContentView 이해하기 (1/2) - some View가 뭔가요?

소들이 — Thu, 7 Apr 2022 21:57:45 +0900

안녕하세요~ 소들입니다 :>

아침형 인간이 되기 위한 주니어 개발자의 발악 1일차

출근(재택)시간보다 2시간 전에 일어나 운동도 하고 공부도 하는 중이다 이말입니다 하하

1일차 느낀점

일찍 일어나는 새가 일찍 졸리다

아우 졸려 zZ..

쨌든 오늘은 SwiftUI 프로젝트를 생성하면 가장 먼저 보이는

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
            .padding()
    }
}

이 코드에 대해서 살펴보려고 해요!!

저번 포스팅에서는 대충 화면을 그리는 코드라고만 설명하고 넘어갔기에,

이번엔 이 코드가 어떻게 구성되어 있고

저 some이 뭐하는 놈인지, body가 무엇인지에 대해 알아보겠읍니다

모든 포스팅은 편의 말투로 합니다~!!

이번 포스팅은 뭔가 내가 쓰면서도 좀 이해가 잘 안가는 부분이 있어서리..

절대 이 포스팅을 맹신하지 마시고,,, 피드백은 꼭 바랍니다,,

1. some은 뭐 하는 애야?

자 처음에 SwiftUI를 공부해보자 하고 야심차게 프로젝트를 생성하면

가장 먼저 막히는 부분이 바로 이 some이라는 키워드일 것임

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
            .padding()
    }
}

some의 정의에 대해서 말해보면,

some이라는 키워드는 Swift 5.1에서 등장한 새로운 기능으로,

해당 키워드가 반환 타입 앞에 붙을 경우,

해당 반환 타입이 불투명한 타입(Opaque Type)이라는것을 나타낸다

히히 정의는 더 어려워졌네

자, 불투명한 타입(Opaque Type)이란 게 도대체 뭔데? 싶겠지만,

불투명한 타입이란 것을 보통 "역 제네릭 타입(reverse generic types)"이라고 표현한다고 함

역 제네릭이요..?

내용이 살짝 어려울 수 있으니 차근차근 제네릭에 대해서부터 간단하게 다시 보자 :)

1-1. 제네릭 타입(Generic Types)

func swap<T>(a: inout T, b: inout T) { }

자, 위와 같은 함수가 바로 제네릭 함수잖음!?

타입에 의존하지 않는 범용 코드를 만들 떄 사용하는!

다만, 제네릭을 사용할 경우

함수를 작성할 당시엔 실제 어떤 타입이 들어올지에 대해서는 당연히 알 수 없음

당연히 함수 본문에서 매개변수로 많은 작업을 할 수 없음

(매개변수 타입이 어떤 게 들어올지 모르니까)

따라서 만약 제네릭 타입에 대한 제약이 필요할 경우,

프로토콜 정도로 다음과 같이 제한을 할 수 있었음

func swap<T>(a: inout T, b: inout T) where T: Equatable { }

요롷게!

함수 내부에선 a, b 매개변수가 어떤 타입일진 모르지만,

Equatable을 채택하고 있으니 a,b에 한해서 == 연산 정도는 사용 가능하겠거니만 알고 작업할 수 있음

따라서 제네릭의 경우

함수 구현 내에서는 값의 실제 타입에 대해서 알 수 없음(숨겨짐)

그렇다면 제네릭 함수의 실제 타입에 대해서는 어디서 알 수 있을까!?

바로 제네릭 함수를 호출하는 "외부"에서임

var a: String = "so"
var b: String = "deul"
swap(a: &a, b: &b)

이렇게! 실제로 호출하는 곳인 외부에서

나는 제네릭 타입의 함수를 String으로 호출하는구나!란 것을 알 수 있음

1-2. 불투명한 타입(Opaque Types)

아까 불투명한 타입이 역 제네릭 타입이라고 불린다고 했잖음!?

위에서 제네릭이 함수 "외부"에서 해당 타입에 대해 알 수 있는 반면,

불투명한 타입의 경우, 외부에서 함수의 반환 값 유형을 정확하게 알 수 없음

다만 함수 내부에서는 어떤 타입을 다루는지 정확히 알고 있음

왜 역 제네릭 타입이란지 알겠음?

아직 모를 거 알기에 예제를 보며 이해를 해보자 :)

자, 우리가 만약 다음과 같은 선물 상자를 하나 만든다고 가정 해보셈

근데 이 상자 안엔

사과

체리

두 가지 중 하나가 들어 있음!!!

근데 겉모습으로 봤을 땐 똑같이 노란 상자기 때문에

겉으로는 해당 상자가 어떤 과일(타입)을 갖고 있는지 알 수 없음

자, 이를 프로토콜로 구현해보면,

struct Apple {}
struct Cherry {}
 
protocol GiftBox {
    associatedtype giftType
    
    var gift: giftType { get }
}

이런 식으로 associatedtype을 이용해서 구현할 수 있음

(참고로 associatedtype은 Protocol 내의 Generic Type이라고 생각하면 됨)

실제 선물인 gift의 타입이 사과인지 체리인지는 알 수 없으니,

associatedtype(giftType)으로 만들고,

이제 선물을 포장하는 곳에서 다음과 같이 구현 할 것임

struct AppleGiftBox: GiftBox {
    var gift: Apple
}
 
struct CherryGiftBox: GiftBox {
    var gift: Cherry
}

뭐 자주 보던 Protocol 패턴이잖음?_?

실제 GiftBox를 채택하는 사과/체리 선물 상자들은 위처럼 만들어서 쓰겠징

자, 내가 만약 선물을 포장하는 사람이라고 생각을 해보셈

GiftBox를 만들기 위한 작업을 makeGiftBox라는 함수로 구현할 것임

func makeGiftBox() -> GiftBox {
    return AppleGiftBox.init(gift: .init())
}

근데 나는 오늘은 체리를 선물하고 싶고, 내일은 사과를 선물하고 싶은데

리턴 타입을 AppleGiftBox / CherryGiftBox라고 지정해버리면 범용적으로 쓸 수 없으니

위와 같이 그냥 GiftBox를 리턴하는 함수를 만들어 버렸음

오늘은 사과로 선물을 만들테지만, 내일은 만약 체리를 선물 하고 싶다면,

외부에서 보여질 함수 모양은 건들 필요 없고,

함수 내부의 return 구문만 AppleGiftBo를 CherryGiftBox로 수정해주면 끝이잖음?

근데 위처럼 짜주면 다음과 같은 에러가 발생함

Protocol 'GiftBox' can only be used as a generic constraint because it has Self or associated type requirements

위 에러가 발생하는 이유는,

반환 타입이 GiftBox인데, 받는 사람은 GiftBox 안에 사과가 있을지 체리가 있을지 알 수 없어!

하고 에러를 뱉는 거임

ㅋㅋ...;; 근데 생각해보면 당연한 거셈 ㅋㅋ;;

나는 선물 만들 때 분명 사과를 담았지만

선물을 받는 입장에서는 안에 들은 게 어떤 것인지 알 수 없는 것임

말 그대로 GiftBox라는 프로토콜을 냅다 받은 거라고 생각할 수 있음

왜 이런 문제가 생겼냐?

gift라는 프로퍼티의 타입이 GiftBox란 프로토콜 내에 지정된 타입(String / Int 등)이 아닌,

associatedtype(or Self) 이기 때문임

(실제 타입이 해당 프로토콜을 준수하는 객체에서 지정될테니!)

자,

나는 분명 함수 "내부"에서 "사과"로 만들었는데!?!?(억울) 할 수 있지만

근데 여기서 문제는 이 사실을 바로 "함수 내부"만 알고 있단 것임!!

외부에선 GiftBox로 나오는데,

GiftBox의 gift 프로퍼티가 associatedtype으로 선언되어 있어서,

"외부"에선 해당 GiftBox 안에 어떤 타입의 gift가 들어있는지를 알 수 없음

아까 불투명 타입이 왜 "역 제네릭 타입"이란지 좀 알겠음?

실제 타입을 함수 "내부"에서 알 수 없고, "외부"에서 결정 짓는 게 제네릭 타입이었다면,

실제 타입을 함수 "외부"에선 알 수 없고, "내부"에서 결정 짓는 게 불투명 타입인 것임

여기서 중요한 건,

함수 내부(선물 주는 사람)의 단순 변심에 의해

함수 내부의 내용을 바꿔버리면(AppleGiftBox->CherryGiftBox) 리턴 타입이 바뀐다는 것임!!

따라서, 이때

내 함수는 반환타입이 내 변심에 의해 바뀔 수는 있지만,

항상 특정 타입만 반환할 거야!!

라고 컴파일러(받는 사람)에게 알릴 때 사용하는 것이 바로 some이라는 키워드임

func makeGiftBox() -> some GiftBox {
    return AppleGiftBox.init(gift: .init())
}

위처럼 some이란 키워드를 추가하면 에러가 사라지면서

반환 타입인 GiftBox가 "불투명 타입"이 된다는 것임..!

하하하 갑자기 위에 한 5줄 정도가 이해 안 갈 것 알아요

흐음 어려운 내용이라 생각해서.. 다시 천천히 봐봅시다 :)

위에서 웬 갑자기 특정 타입만 반환?? 이라고 생각하잖음?

자, 함수를 짜는 입장(선물하는 사람 입장)에서 나는 "사과"를 포장하는 코드를 짰음

이 경우, 받은 사람의 GiftBox가 "체리"로 바뀔 일은 절대 없고,

특정 타입(사과)가 든 GiftBox만 항상 반환한다는 것을 알리는 것임

언제까지?

내가 직접 함수 내부에서 체리로 포장하는 코드로 고치기 전까진!!!

만약 내가 내일 "체리로 포장하는 코드로 함수 내부를 수정 했다면,

특정 타입(체리)가 든 GiftBox만 반환한다는 것을 알리는 것이 바로

some, 즉 불투명 리턴 타입 인 것임!

정리하자면,

some이란 것은

명확하지 않은 타입(associatedType or Self)이 프로토콜 내에 정의되어 있고,

이 프로토콜을 함수(및 연산 프로퍼티)의 반환 타입으로 가질 때

반환 타입을 "불투명 타입"으로 만들어주기 위해 사용하고,

some이라는 것을 통해 반환 타입을 "불투명 타입"으로 만든단 것은,

반환 타입이 어떤 타입인지 컴파일러(및 함수 외부)는 1도 모르겠지만

함수 내부에선 어떤 타입을 반환하는지 명확히 알고 있고,

따라서 내 함수는 정해진 "특정 타입만 반환"된다고 컴파일러에게 알려주는 것임

위 예제에서 "특정 타입"은 함수 내부에서 어떻게 구현하냐에 따라 달라지겠지만,

GiftBox 프로토콜을 준수하고 있는 AppleGiftBox / CherryGiftBix 중 하나가 될 것임

조금 이해가 갔으려나?ㅠㅠ..

이해한대로 정리해봔쓴데 만얃 틀린 설명이면 말해줘요..ㅠㅠㅠ

그럼 이 불투명 타입을 썼을 때의 이점..!?은 다음 some View를 보면서 확인 해보겠음 :)

2. 그래서 some View 구만..

돌고 돌아 온 것 같은데, 위 내용을 정확히 이해 했다면

금방 이해할 수 있음~!!

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
            .padding()
    }
}

여기서 body라는 것은 View라는 프로토콜에 정의된 프로퍼티인데,

이 프로퍼티는 연산 프로퍼티(Computed Property)로

위 코드에선 Text라는 것을 return 하고 있다고 보면 됨

자, 근데 위에서 배운 것을 토대로 한다면

some은 언제쓴다??

명확하지 않은 타입(associatedType or Self)이 프로토콜 내에 정의되어 있고,

이 프로토콜을 반환 타입으로 가지고 싶을 때 쓴다!!!

오홍 그럼 View는 프로토콜일 것이고!!! 속성 중 하나는 associatedtype(or Self)로 선언되어 있겠네!?

호옹이.. 진짜잖어?

그럼 body라는 연산 프로퍼티는 View라는 프로토콜 타입을 반환하지만

View라는 프로토콜 내에 명확하지 않은 타입이 정의되어 있으니

some을 통해 불투명 타입이라고 밝혀준 것이구나!

따라서 body 내부에 내가 작성하는 코드에 따라 리턴 타입이 달라지겠지만,

View 프로토콜을 준수하는 타입만 리턴이 가능하겠군!

라고 이해했는데^^;;

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
            .padding()
    }
}

자, 위 코드는

컴파일러(및 함수 외부)에서는 View라는 프로토콜을 준수하는 객체가 나올 것은 알지만,

정확히 어떤 타입이 나올지는 모름

다만 위에서 body는 특정 타입(현재는 내가 Text를 리턴 했으니 Text)만

항상 반환된단 것을 알려주는 것이 some(불투명 타입)임

엥 갑자기 기획자가 내부 디자인을 Text가 아닌 버튼으로 바꿔달라네?

struct ContentView: View {
    var body: some View {
        Button {
        } label: {
            Text("Hello, world!")
    }
}

이렇게 Button으로 바꾸면 컴파일러 및 함수 외부에선

여전히 정확히 어떤 타입이 나올지는 모름

다만 위에서 body는 특정 타입(현재는 내가 Button를 리턴 했으니 Button)만

항상 반환된단 것을 알려주는 것이 some(불투명 타입)임

2-1. some을 사용하는 이유? 이점?

이렇게 불투명한 타입을 사용할 경우,

함수 내부에서 내가 짜는 코드에 따라 시시각각 리턴 타입이 변경 되었지만 (Text -> Button)

ㅇㅣ거에 대해 따로 내가 리턴 타입을 바꿔줄 필요가 없음!!!

좀 더 극단적으로 보자면, 다음과 같은 코드가 있을 때

struct ContentView: View {
    var body: VStack<TupleView<Text,Image>> {
       VStack {
          Text("Hello, world!")
           Image(systemName: "sodeul!")
        }
    }
}

만약 some을 통해 불투명 타입으로 선언하지 않았다면 우린

이런 식으로 body의 타입을 저렇게 다 끔찍하게 명명해줬어야 했을 거임

한마디로 불필요한 타입에 대해 우리가 알 필요가 없음! 컴파일러가 알아서 함

내용이 별로 맘에 안 들어서...;

만약 더 쉬운 설명이 생각나면 언제든 뜯어 고칠 생각 10000%

혹은 잘못된 내용이 있으면 꼭!! 피드백 주세요ㅠㅠㅠㅠ

최ㅐ대한 이해하려고 노력하고 쉽게 풀어 쓰려 노력했는데

생각보다 쉽지 않네요,,,,,,;;;;;

https://medium.com/@PhiJay/whats-this-some-in-swiftui-34e2c126d4c4

What’s this “some” in SwiftUI?

An Intuitive Explanation of The New Opaque Return Type

medium.com

이 포스팅을 참고 했으니 이해 안가는 점이 있다면 위 포스팅을 보시길 바랍니다..!

SwiftUI) SwiftUI 시작해보기

소들이 — Thu, 31 Mar 2022 21:44:29 +0900

안녕하세요! 소들입니다

SwiftUI를 드디어 포스팅을 하게 됐네요

지금 임시저장에 있는 발행되지 못한 포스팅만 몇 개 인지^^;

쨌든 이번 포스팅에선 SwiftUI 프로젝트는 어떻게 생성하고,

Preview가 무엇인지! 어떻게 동작하는지!!!

이런 식으로 아주 "기본"적인 것에 대해 알아볼 거예요!!!

(SwiftUI를 처음 시작하는 분들을 위한 포스팅이 될 예정)

참고로 처음 공부할 땐 매우 재밌고 신기하다고 한다 하하

모든 포스팅은 편의 말투로 합니다~!!

1. SwiftUI 프로젝트 생성하기

기존 App 실행 시와 똑같이!!! 만들어주면 되는데,

이렇게 Interface를 기존 Storyboard가 아닌

SwfitUI로 선택 해주셔아 함!!

그렇게 생성을 해주시면 이제 무슨 일이 일어나냐

이렇게 ContentView라는 것이 생성되면서,

생소한 화면이 나타남 하하하

이게 SwiftUI로 프로젝트를 만들었을 때의 기본 화면?이라고 보시면 됨!

화면이 위처럼 반쪽으로 나뉘어져 있는데,

자, 왼쪽은 대충 코드를 작성하는 곳이라는 것을 알겠음

근데 오른쪽 저 선물 포장지 같은 빈 공간은 뭘까?

그건말이셈

SwiftUI의 개짱 기능 중 하나인 Preview라는 기능이셈

Preview인 말 그대로, 미리보기 아닌가요? 뭐가 보인다는 거죠?

저 Resume이란 버튼을 누르면 말이죠

짜잔 - 이렇게 Preview가 나타난답니다!!

일단 저녀석이 Preview라는 것을 알고 가셈

(+ 아 만약 Preview가 비활성화 되거나 바로 갱신이 안 될 땐 Resume 버튼을 눌러주면 됨)

2. ContentView 파일 살펴보기

이번 포스팅에선 ContentView가 무엇을 하는 녀석인지,

body가 어떤 녀석인지에 대해선 다루지 않을 것임!

다만 ContentView 파일 안이 어떻게 구성되어 있고,

왼쪽 코드와 오른쪽 Preview와 어떤 식으로 서로 동작하는지에 대해 봐보겠음

먼저, ContentView란 파일은 총 두가지 구조체로 구성되어 있는데,

위에 생긴 ContentView는 화면을 그리는 구조체고,

아래 생긴 ContentView_Previews는 Preview를 그리는 구조체임

이렇게 생각하면 됨!

그러면 화면을 그리는 코드에 지금 Hello, world라 써있는 Text의 글자를바꾸면 어떻게 될까?

(참고로 body안에 있는 Text는 Label이라고 보면 되는데, 지금은 맛뵈기니 넘기셈)

gif 짤임

보임?? 옆에 Preview가 실시간으로 바뀜!!! O0O

역으로, Preview에서 글자를 바꿔도 무려 "코드"가 "자동"으로 수정되는데,

gif 짤임

위 짤 저 인스펙터 영역(이름 뭐더라?)에서 마치 스토리보드처럼 수정할 수 있음!

(참고로 해당 객체 클릭한 상태에서 shift + command + option 누른 상태로 클릭하면

수정할 수 있는 팝업창 뜸)

옆에서 속성을 바꿔줄 때마다 왼쪽 Text 안에 코드가 실시간으로 추가되는 것 보임??

이것이 바로 Preview임! 미리보기 뿐 아니라,

마치 스토리보드처럼 원하는 기능을 추가할 수도 있음

물론 당연히 위 기능들은 직접 코드로도 추가할 수 있음

(코드도 자동으로 추가되는 점에서 스토리보드와 매우 다름)

근데 ContentView 안에 추가되는 코드를 보면,

struct ContentView: View {
    var body: some View {
        Text("Hello, Sodeul!")
           .font(.body)
           .fontWeight(.bold)
           .padding()
    }
}

이런 식으로 Text라는 것 밑에 .을 통해서 속성을 나열하는데,

(.font, .fontWeight, .padding 등등)

SwiftUI에선 이것을 modifier라고 부름!!

당연히 아래 ContentView_Previews는

Preview를 그리는 코드이기 때문에, 이를 주석 처리 하면,

Preview는 사라짐

3. Preview의 기능 훑어보기

마지막으로, Preview라는 것에 기능 몇 가지에 대해 알아보고 끝내겠음

Preview를 보면 위에 5가지 기능이 있딴 말임

3-1. 라이브 활성화 / 비활성화

이 버튼은 라이브 버튼으로,

짤임

만약 위같이 DatePicker를 Preview에 추가했을 때,

실제 어떻게 동작하는지 위처럼 미리보기 상태인 프리뷰에선

DatePicker를 아무리 눌러도 아무런 반응이 없음

왜냐? 미리보기 상태이기 때문에, 실제 동작까지 확인할 순 없음

당연히 원래 같으면 시뮬레이터나 디바이스로 돌려봐야 하잖음?

근데 이때 이 라이브 버튼을 활성화(클릭) 시키면,

짤

엄머;; 화질구지 무슨일이야;;

쨌든 이렇게 배경 색깔이 바뀌면서 실제 시뮬레이터를 돌리듯이 확인해볼 수 있음!!

따라서 SwiftUI에선 시뮬레이터를 직접 돌리며 확인할 일이 많지 않음ㅎㅎ

확인이 끝나면 다시 버튼 클릭해서,

미리보기 상태로 돌려놔주셈

3-2. 디바이스에서 실행하기

이 버튼은 실제 디바이스에서 실행할 때 사용하는 버튼임!

지금은 디바이스가 연결되지 않아서 위처럼 비활성화 상태이고,

만약 실제 디바이스를 연결해주면 저 버튼이 활성화됨

참고로 위 버튼은 iOS15라는 신생아급 폰에서만 동작한답니다

iOS14.8인 내 핸드폰에서 돌려보면

에러를 맞이할 수 있어요

핸드폰 화석은 눈치껏 하지 마셈

3-3. 회전하기

생긴 모양 그대로 회전인디

이게 말이요

누르는 순간 Previews 구조체에

.previewInterfaceOrientation.(.landscapeLeft)라는 modifier가 추가되는데,

사실 이녀석 또한 iOS 15 이상만 동작하기 때문에

이런 식으로 분기 코드를 작성해주어야 함!!

(참고로 else 구문에도 ContentView() 추가해 주어야 Preview가 잘 동작함)

3-4. Preview 설정 팝업

이 버튼은 누르면 Preview의 설정창을 팝업으로 띄워줌

뭐 Device 종류.. Orientation, Light / Dark Mode 등등 설정할 수 있음

만약 원래 설정으로 돌리고 싶으면 옆에 ●를 클릭해주면 됨

(내가 커스텀한 것은 ●로 설정됨)

3-5. 미리보기 복사하기

말 그대로 미리보기 하나를 똑같이 복사함

이런 식으로!!!

참고로 옆에 코드에 ContentView가 Group으로 묶여서 두 개 생긴 것까지 같이 보셔야됨!!!

왜냐??

복제된 미리 보기를 삭제할 땐 저 ContentView() 라는 코드를 삭제해야 하거드!!

(preview에선 삭제 불가능함. 코드로만 삭제 가능)

이런 식으로 Light / Dark 모드를 같이 보고 싶다거나

이런 식으로 가로 / 세로 모드에서 확인하고 싶을 때 사용하면 됨!!

(iPad / iPhone 확인 등등..)

이번 포스팅에선 SwiftUI에 대한 정말 기본 동작에 대해 알아봤어요!!!

다음 포스팅에선 SwiftUI가 어떻게 구성되어 있고, 저 ContentView가 도대체 무엇인지 등등에 대해

공부해보도록 하겠습니다!!

처음 공부할 때 되게 재밌어서 신났던 기억이 있는데 XD

잘못된 내용이나 오타 피드백 대환영입니다!!!!

iOS) Auto Layout - Constrain to margins는 뭐할 때 씀

소들이 — Wed, 23 Mar 2022 21:04:25 +0900

안녕하세요~ 소들입니당!! :>

저는 요즘 swiftUI를 공부하고 있어서!!

아마 4월쯤부턴 이 아이의 포스팅이 자주 올라올 거 같네요 :D

hm.. 제가 제 포스팅에 대한 정체성을 찾아 꽤나 생각을 해봤는데

제 블로그를 읽고 댓글을 달아주시거나, 제 블로그를 알아봐주시는 거의 대~~부분은

iOS 공부를 막 시작한 개발자분들이더라구요! 기본에 대해 많이 다뤄서 그런가 ㅎㅎ

그래서 뭐 어쩌라고 싶겠지만,

결론부터 말하자면 저는 계속 iOS 개발 시작이 어려운 개발자들을 위해,

"기본"에 관한 글에 대해 꾸준히 작성할 거예요.

(TableView / CollectionView가 지금 다음 포스팅 대기 queue에 있따 이말임)

뭔데 이리 비장하냐면

누군가 2.7년차 개발자가 뭐이런 쉬운 글을 작성하고 있어?
라고 생각하실까바 하하 어쩔티비요?라고 미리 말하고 있는겁니다 하하

오늘 포스팅을 마지막으로 당분간 AutoLayout과는 작별할 것이고,

스토리보드로 Constraint 설정할 때

사용처도 잘 모르면서 무지성 체크 해제했을 옵션에 대해 하나 알아보고 가려고 합니다!

모든 포스팅은 편의 말투로 합니다~!!

1. 스토리보드에서 보이는 Constrain to margins ☑️의 의미

Constrain to margins가 뭐냐면 ㅎㅎ

스토리보드로 Constraints를 설정하다 보면,

이렇게 Constrain to margins라는 것이 체크되어 있음!!!

근데, AutoLayout에 대해 설정 해보신 분은 알겠지만,

이 체크는 보통!!!! 하지 않고(□), 비워두고 Constraint를 설정함

그러면 만약 체크 한다면 뭐가 바뀔지에 대해 님들은 아셈? 난 몰랐음ㅋ

결론부터 말하자면 Constrain to margins는

내 View의 내부 뷰(SubView)들을 배치할 때 마진을 주기 위함

임ㅎㅎ

머라는겨 ㅎㅎ 예제로 보자

이렇게 위처럼! 평소처럼! 우린 노란 뷰를 하나 만들었음!!

(참고로 노란 뷰는 Constrain to margins를 체크하지 않음)

자, 이상태에서 나는 노란 뷰의 SubView를 배치할 때 마진을 주고 싶어!! 한다면,

다음과 같이 Layout Margins라는 것을 이용해 내부 뷰에 대한 마진을 설정해줄 수 있음

해당 View의 Layout Margin에 보면, 기본 값이 Default로 설정되어 있는데

우리는 마진을 넣고 싶으니 이 값을 Fixed로 바꿔줘보셈!!

먼저 두번째 Language Directional과 Fixed의 차이점은 무엇이냐면

AutoLayout 첫 시간에 공부한 Leading / Left와 Trailing / Right의 차이임!!

(글자가 시작되는 시점 어쩌고라 했었잖음?)

기본값이 8로 다 설정되어 있는데요??

맞음!! 기본 마진 값이 8임!!!

그럼 기본 마진 값 8을 줬으니, 노란 뷰에도 어떤 변화가 있을까?

없음!!

왜냐?? 계속 설명했듯이,

노란 뷰 안에 배치되는 SubView에 대한 마진을 주는 것이라고 했음!!

따라서, 다음과 같이 SubView인 초록 뷰를 하나 추가해서

노란 뷰에 꽉 채우도록 Top/Leading/Trailing/Bottom을 모두 0으로 채워보겠음

뭐야 내 마진 8 돌려줘요

SubView를 채워도 초록 뷰에 마진이 들어가지 않는데 어캄!?!?

자, 이때 Constrain to margins가 등장하는 것임

SubView를 추가할 때 비로소 Constrain to margins를 체크해줘야 함!!

(당연히 Constrain to margins를 체크하지 않으면,

노란 뷰의 Layout Margins는 ㅃㅃ됨)

이렇게!!! ㅎㅎㅎㅎ

그럼이제 위처럼 초록 뷰를 채울 때 분명 노란 뷰를 기준으로 모두 0으로 설정 했어도

노란 뷰의 내부 마진이 8로 설정되어 있기 때문에,

초록 뷰가 채워질 때 그만큼의 마진이 들어감!!!

(초록 벽 뒤에 노란 마진 공간 있어요)

참고로 마진이 들어갔다고 해서,

초록 뷰의 Constraints의 constant 값이 바뀌는 것은 아님!!

다 SuperView로 고정되어 있음에도,

노란 뷰의 Constrain to margin에 의해고정 마진이 들어가는 것임

이해가 갔을랑가

참고로 저 마진 값을 바꾸고 싶다면,
당연히 초록 뷰의 마진 값이 아니라노란 뷰의 마진 값을 바꿔야 함

(노란 뷰 내부 배치되는 SubView의 마진을 지정하는 것이니!)

정리해서

내부 뷰에 마진을 주고 싶은 SuperView의 AutoLayout을 설정할 땐

Constrain to margins를 체크할 필요 없는 대신

주고싶은 마진 만큼 Layout Margins를 설정해주고,

SuperView의 Constrain to margins 값을 따르고 싶은 SubView들이

AutoLayout을 설정할 때 Constrain to margins을 체크해줘야하는 것 같음!

2. 언제 쓰려나?

난 음 약간 이 Cosntraint to margins를 이해했을 때

CollectionView의 Section Insets의 느낌이 강했는데..

만약

내 View에 그려질 SubView는 내 테두리에 닿을 때 무조건 이만큼의 마진이 필요해!!

라고 판단될 때 사용하면 유의미 할 수도..?

사실 Constraints로도 충분하기 때문에..

알아서.. 잘 쓰시길..

꺄악 공부가 길어져 운동 늦어서 이만 ㅌㅌ

오타 및 잘못된 내용 피드백 대환영!

iOS) Auto Layout 정복하기 (5/5) - 코드로 Auto Layout 설정하기

소들이 — Tue, 15 Mar 2022 20:51:30 +0900

안녕하세요! 소들입니당 ☺️

드디어 AutoLayout 정복하기의 끝을 보려고 합니다!!!

저는 오늘부터 바른생활맨이 되기 때문에,,

운동도, 공부도 모두 다 죽었다 이말입니다 후후,,

쨌든

마지막 포스팅은 코드로 AutoLayout을 설정하는 방법에 대해 알아볼 거예요!

사실 Storyboard로 View를 그리는 것이 처음 iOS를 개발할 땐 매우 당연해보이고

아니 저렇게 좋은 스토리보드를 외않써? 할 수도 있지만,

협업을 해보시면요,, 스토리보드와 xib 무한 로딩에서 못나올 수도 있기에..^^

혹은 한문철도 못막는 무지성 충돌..^^

따라서 코드로 화면을 그리는 방법에 대해서도 꼭 숙지를 하고 계셔야 해요!

뭐 여러가지 방법이 있는데 저는 제일 많이 사용하는 방법에 대해 다뤄볼 거예요!

모든 포스팅은 편의 말투로 합니다~!!

1. 코드로만 View를 그려보자

1-1. Frame-Based Layout

override func viewDidLoad() {
    super.viewDidLoad()
    
    let sodeulButton: UIButton = .init(frame: .init(x: 100, y: 100, width: 200, height: 200))
    sodeulButton.backgroundColor = .yellow
    sodeulButton.setTitle("바른생활 소들맨", for: .normal)
    
    self.view.addSubview(sodeulButton)
}
 

꺄하하 소들님 이렇게 frame 설정해주면 버튼 잘 나오는데요?

하하하하

ㅇㅖ.. 물론 위처럼 해당 View의 frame을 직접 지정해주면,

(Button은 물론 View의 하위클래스입니당)

위처럼 내가 원하는대로 Button을 그릴 수 있긴 함!

AutoLayout 첫 포스팅때 뭐라했음 ㅎㅎ??

View의 위치나 크기를 설정할 때는 주어진 frame 그대로 그려버리는

Frame-Based Layout이 있다고 했잖음?

우리가 view를 만들 때 frame을 지정해주면 위처럼

Frame-Based Layout로 그려버림

하지만 우린 뷰들간의 관계로 위치와 관계를 설정하는 AutoLayout을 설정하고 싶은 거잖음!?

위에 예제는 치워버리고 AutoLayout으로 그리는 방법 보러가자~~

1-2. AutoLayout(오토 레이아웃)

AutoLayout을 설명할 때 뭐라 했냐면,

위치나 크기를 다른 객체를 이용해 "상대적"으로 제약을 주는 것이라 했음

따라서 우리가 만약 다음과 같은 제약조건을 가진 Button를 만들고 싶다면,

이를 코드로 짠다면 몇 가지 과정이 필요함 :)

1️⃣ addSubView로 뷰 추가해주기

override func viewDidLoad() {
    super.viewDidLoad()
    
    let sodeulButton: UIButton = .init(frame: .init())
    sodeulButton.backgroundColor = .yellow
    sodeulButton.setTitle("바른생활 소들맨", for: .normal)
    
    self.view.addSubview(sodeulButton)
}
 

코드로 AutoLayout을 설정하기 전에, 먼저 SuperView를 설정하는 addSubView작업이 선행되어 있어야 함

만약 addSubView 과정을 맨 마지막에 한다던가, Constraint 설정(3번 과정) 이후에 한다면

크래시나용~~~~!!!!!!!!!!!!!

2️⃣ translatesAutoResizeingMaskIntoConstraints를 false로 설정하기

override func viewDidLoad() {
    super.viewDidLoad()
    
    let sodeulButton: UIButton = .init(frame: .init())
    sodeulButton.backgroundColor = .yellow
    sodeulButton.setTitle("바른생활 소들맨", for: .normal)
    
    self.view.addSubview(sodeulButton)
   sodeulButton.translatesAutoresizingMaskIntoConstraints = false
}
 

translatesAutoResizeingMaskIntoConstraints 너가 뭔데 false로 설정해야 되나!!! 싶겠지만

일단 해주셈(뭔지에 대해선 다다다다~~음에 포스팅 할 거임)

기본 값이 true인데 일단은 대충

true - AutoLayout을 따르지 않고 frame을 따르겠다(Frame-Based Layout)

false - AutoLayout을 따르겠다(AutoLayout)

이렇게 알면 됨

따라서

AutoLayout을 설정하고 싶다면 해당 뷰의 이 값을 false로 무조건 설정 해주어야 함

3️⃣ 제약조건(Constraints) 설정하기

override func viewDidLoad() {
    super.viewDidLoad()
    
    let sodeulButton: UIButton = .init(frame: .init())
    sodeulButton.backgroundColor = .yellow
    sodeulButton.setTitle("바른생활 소들맨", for: .normal)
    
    self.view.addSubview(sodeulButton)
   sodeulButton.translatesAutoresizingMaskIntoConstraints = false

    sodeulButton.topAnchor.constraint(equalTo: self.view.topAnchor, constant: 100).isActive = true
    sodeulButton.leadingAnchor.constraint(equalTo: self.view.leadingAnchor, constant: 100).isActive = true
    sodeulButton.trailingAnchor.constraint(equalTo: self.view.trailingAnchor, constant: -80).isActive = true
}
 

위처럼 설정하면 되는데!!!!!

위의 코드가 이해가 안갈까봐 trailing constraint로 대충 설명 갖고옴

먼저 AutoLayout을 설정하고 싶은 View의

topAnchor / leadingAnchor / trailingAnchor / bottomAnchor 등등..

에 대고 constraint라는 메서드를 호출해주면 되는 것임

뒤에 Anchor가 붙긴 했지만, Anchor를 빼고 생각해도 무방함!!!

이때, 제일 중요한 건 마지막 isActive 상태를 true로 바꿔주어야 함

코드로 설정할 경우 해당 constraint는 기본이 비활성화기 때문에, 활성화를 시켜줘야 함

이렇게 해줄 경우, 나는 아무런 frame을 설정하지 않았지만,

코드로 설정해준 AutoLayout에 의해

이렇게 잘 나옴!! :>

근데 의문. 나는 trailing을 80만큼 띄우고 싶은데, 왜 constant 설정을 -80으로 해줘야 함!?!?

에 대한 의문 풀어dream

2. 코드로 AutoLayout 설정할 때 알아두면 좋은 내용 모음

"모음" 집으로 내가 헷갈렸거나 누군가 헷갈려서 질문을 한다면

계속 추가될 수 있음

2-1. trailingAnchor, bottomAnchor constant 설정 시 주의점

지금껏 스토리보드로 AutoLayout을 설정할 때 분명

이렇게 trailing, bottom에 각각 80을 주면

trailing에서 80떨어진 만큼, bottom에서 80 떨어진 만큼 위처럼 당연히 그려졌잖음?

(참고로 bottom은 SafeArea에 걸림!)

근데 이게, 코드에서도 마찬가지로 80씩 줘버리면 어케 되냐면

sodeulButton.trailingAnchor.constraint(equalTo: self.view.trailingAnchor, constant: 80).isActive = true
sodeulButton.bottomAnchor.constraint(equalTo: self.view.bottomAnchor, constant: 80).isActive = true
 

이렇게 ㅔ 멀리 멀리 사라진답니다...ㅎ

그 버튼.. 좋은 버튼이었어..

따라서 코드로 constant를 설정할 때, trailingAnchor / bottomAnchor에 한해서

storyboard와 달리 -(minus)를 붙여주어야 한다는 사실 잊지 마셈

(일단 생각나는 건 이 둘인데 더 있으면 추가하겠음)

당연히 -80으로 설정하면

sodeulButton.trailingAnchor.constraint(equalTo: self.view.trailingAnchor, constant: -80).isActive = true
sodeulButton.bottomAnchor.constraint(equalTo: self.view.bottomAnchor, constant: -80).isActive = true
 

원하는 모양으로 잘 나옴!!!

2-2. self.view(rootView)에 붙일 경우, SafeAreaLayoutGuide를 사용하자

사실 위 예제처럼 constraint의 기준이 되는 view를 self.view로 잡아도 되지만

혹여나 이 난리를 피하고 싶다면,

다음고 ㅏ같이 SafeAreaLayoutGuide에 잡는 게 바람직함

sodeulButton.topAnchor.constraint(equalTo: self.view.safeAreaLayoutGuide.topAnchor, constant: 20).isActive = true
sodeulButton.leadingAnchor.constraint(equalTo: self.view.safeAreaLayoutGuide.leadingAnchor, constant: 20).isActive = true
 

그러면 다음과 같이 잘 나옴

safeArea를 사용하지 않는 화면의 경우 상관 없겠지만,

보통 애플이 safeArea 사용을 권장하기 때문에!!!!

self.view에 붙일 경우, self.view가 아니라 self.view.safeLayoutGuide 를 사용합시다!!

2-3. .isActive = true 를 매번 하기 귀찮다면 이렇게도 쓸 수 있다

NSLayoutConstraint.activate([
    sodeulButton.topAnchor.constraint(equalTo: self.view.safeAreaLayoutGuide.topAnchor, constant: 20),
    sodeulButton.leadingAnchor.constraint(equalTo: self.view.safeAreaLayoutGuide.leadingAnchor, constant: 20)
])
 

이렇게 NSLayoutConstraint.activate를 이용해서

위처럼 activate 메서드 안에 []로 Constraints를 나열해주면,

각각 isActive = true를 해줄 필요 없이 전체 활성화로 설정이 가능함!!!!

2-4. widthAnchor, heightAnchor 같이 기준 뷰 없이 constant만 설정하고 싶은데요

cosntraint를 설정하는 함수는 매우 다양하고 많지만

이처럼 기준 뷰가 없을 경우 constraint(equalTo: constant:) 메서드를 쓰는게 아니라

sodeulButton.widthAnchor.constraint(equalToConstant: 200).isActive = true
sodeulButton.heightAnchor.constraint(equalToConstant: 200).isActive = true

constraint(equalToConstant:) 를 사용하면 됨니당

드디어 AutoLayout에 대한 포스팅이 끝났네요 :)

어우 끝맺고 나니까 속시원한데 Snapkit같은 거 사용법도 나중에 포스팅 할게요 ~.~

도움을 받고 가는 사람이 많길 바라며!!!

오타나 잘못된 내용 피드백은 환영입니다!!!