Mabataki Developer

짧은인사, 하루의 사건, 나의 행동

목요일날 면접이 예정되어있어 다시금 개념을 정리하는 시간을 가졌습니다...

하하 다시보니 또 새롭군군요 ㅋ 대답을 잘할수있을런지...ㅋ

화이또~

배운점

Struct와 Class와 Enum의 차이를 설명하시오.

Class

단일상속, 참조타입 이기에 데이터를 전달할때 메모리의 위치를 전달함, 주소를 복사하여 이에 존재하는 인스턴스의 위치를 가르킵니다. 참조하는 값이 존재하는 위치를 stack 영역에 참조되는 값을 heap에 저장합니다.

Struct

값 타입 이기에 데이터를 전달할때 값을 복사하여 전달, 값이 복사되어 새로운 인스턴스가 생성되고 이 인스턴스가 stack 메모리 영역에 저장, Swift의 대부분 큰 뼈대는 모두 Struct로 구성, 언제사용? -> 참조가 아닌 복사를 원할때

Enum

열거형, 유사한 값을 유의미한 이름으로 한곳에 모아 정리, 상속 불가, 열거형 자체가 하나의 프로퍼티, 기존 프로퍼티는 값을 저장하지만 연산 프로퍼티는 특정한 값을 리턴

차이 -> Class는 참조타입, Struct와 Enum은 값타입 / Class는 상속가능, Struct와 Enum은 상속 불가

공통점 -> extension이 가능

Class의 성능을 높일수 있는 방법은?

1. 상속이나 오버라이딩이 필요없는 클래스나 메서드, 프로퍼티에 final을 선언

final이 붙은 메서드나 프로퍼티는 하위 클래스에서 이들을 오버라이딩 할 수 없고, class에 final이 된다면 상속 자체가 불가능 해져 Static Dispatch 방식으로 동작하게 된다.

2. 파일 내에서만 접근하는 경우엔 private를 선언.

private로 선언하게 되면 참조 가능한 범위가 private로 선언된 파일 혹은 블록 내에서 가능, 컴파일러는 private가 붙은 프로퍼티에 대해서 오버라이딩 될 수 있는지 판단해 오버라이딩 하는곳에 없다면 final 키워드로 추론.

class 앞에 private가 붙으면 클래스 내부의 모든 프로퍼티, 메서드에 private가 붙은것으로 동작

그래서 final, private, Dispatch가 뭔데..?

Dispatch

- Static Dispatch

컴파일 시점에 호출할 함수 결정.

( 컴파일 시점? 앱을 동작 시키기 전 개발자가 작성한 코드들이 컴퓨터가 읽을수 있게 만들어서 앱실행을 준비하는 과정)

앱 실행전, 어떤 상황에서 이 함수가 실행될 것인지 결정이 나기 때문에 성능이 좋습니다.

- Dtnamic Dispatch

런타임 시점에 호출할 함수를 결정.

( 런타임 시점? 컴파일이 끝난 후 앱을 실행하는 동안 일어나는 과정)

이 경우 하위 클래스가 상위 클래스의 메서드를 호출할 때 해당 메모리 배열을 참조하여 호출하는 함수를 결정하는 과정을 런타임 시점에 결정하여 성능이 떨어짐.

∴

참조타입 -> Static Dispatch

값타입 -> Dynamic Dispatch

-> Dynamic Dispatch 메커니즘 으로 작동하는 class를 Static Dispatch로 작동하게 한다면 성능이 좋아짐.!

접근 제어자

: 코드를 작성하는 한 파일에서 다른 파일에 있는 코드에 대한 접근을 명시적으로 작성하게 관리,

module과 source file에 따라 다른 접근을 할 수 있음.

(module은 하나의 프레임워크, 즉 import 키워드로 추가되는것. ex)UIkit, Foundation...

 souece file은 module 안에있는 파일들 xxx.swift)

5가지의 접근제어자.

( 접근 제어자가 적용되는 대상 = "Entity")

1. open, public : 프로젝트의 모든 module entity에 접근 가능

2. internal : default 접근 제어자로 entity가 작성된 module에서만 접근 가능

3. file private : entity가 작성된 source file 에서만 접근 가능. 서로 다른 클래스가 같은 파일 안에 file private로 선언된다면 둘은 서로 접근 가능.

4. private : 특정 객체에서만 사용될 수 있도록 하는 가장 제한적인 접근 제어자. file private와 달리 같은 파일 안에 있고 private로 선언되었다면 이 둘은 서로 접근할 수 없음.

-> 왜써? : 외부로 부터 데이터를 보호하기 위해, 외부에는 불필요한, 내부적으로만 사용되는 부분을 감추기 위해 (= 은닉화)

생각과 감정

말하는 감자에 물을 줍니다... 새싹아 자라나렴....

https://im-babycoder.tistory.com/61

https://hcn1519.github.io/articles/2018-01/Swift_AccessControl

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ 운동은 못함 ㅋ (헬스장 쉼)
✅ 함께자라기 정독

어제는 과 선배와 동기와 함께 술자리를 가졌슴당 ㅎㅎ

문래는 공장단지 맞는거죠,,? 내부는 상당히 힙하고.. 크리스마스 기분이 물씬 ㅎㅎ

신나게 놀고 오늘은 "함께 자라기"를 읽었슴당 ㅎㅎ (카페왔는데 노트북 충전기를 안가져왔다 ㅋ)

그리고 토이프로젝트를 깃에 업로드 하였습니다 ^_^

https://github.com/jjwon2149/TodoApp

배운점

🐣🐥🐓 자라기

애자일에서 학습은 소프트웨어 개발에 큰 병목 중 하나이다. 그 이유는 일반 프로젝트에서 피드백의 주기가 느려서 결정을 내리고 학습을 한 후 다시 피드백을 받응ㄹ 시기에 이전에 내린 결정에 대한 이유를 기억하기 어렵다.

하지만 애자일 프로젝트에서는 당장 한 행동에 대한 피드백을 10분, 한시간, 하루 주기로 빠르고 지속적으로 받아 다음 주기에 교정할 수 있다.

피드백을 짧은 주기로 얻는 것, 실수를 교정할 기회가 있는 것이 학습에 중요한 요소이다.

실력이 좋은 사람은 당시에 어떤 결정을 어떠한 이유로 내렸는지 자세히 기록하고 나중에 다시 확인하여 피드백을 반드시 얻는다.

1. 자신이 이미 가지고 있는 것들을 잘 활용하라
   • 새로운 것을 유입하기보다 이미 가지고 있는 것을 연결하여 시너지 효과가 나게 한다.
   • 새로운 것은 이미 가지고 있는 것과 연결하도록 해라
2. 외부 물질을 체화하라
   • 하지만 내부 순환만 하면 수렴할 위험이 있기 때문에 외부 자극을 받으면 좋다.
   • 하지만 외부 자극을 빨리 자기화 해야 한다.
3. 자신을 개선하는 프로세스에 대해 생각해 보라
   • A를 돌아보는 회고/반성 활동을 주기적으로 해라.
   • 나를 개선하는 과정을 어떻게 개선할지 고민해라.
4. 피드백을 자주 받아라
   • 사이클 주기를 짧게 두어서 작은 실험을 해 순환율을 높여라.
   • 일찍, 자주 실패해라. 실패에서 학습하라
5. 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라.
   • 완벽한 환경에서 시작하기 보다 점진적으로 자신의 환경을 개선시켜라.
   • 완벽한 환경은 어느날 갖추어지기는 어렵다.

생각과 감정

함께자라기는 저를 되돌아볼수 있는 시간을 주는것 같습니다 ^_^ 한번 정독한 후 두번째 정독이라 조금더 이해가 빠르고 와닿습니담ㅁ..다디...

저번주 평일에 머리를 싸맨 TodoApp 그냥 기본 라이브러리 사용하면 되는걸 구지비 커스텀을 해서 ㅎㅎ,,, 그래도 유튜버가 친절하게 알려주더군요 ㅎㅎ 다음에 또 할 진 모르겠지만 좋은 경험이였습니다...

앞으로의 계획선언

"꾸준히 자기계발에 시간을 쏟으면 그것이 1년, 2년 뒤에 성장해서 돌아온다. 지식이나 능력은 복리로 이자가 붙는다." 

꾸준히 자기계발에 시간을 쏟아 보겠슴담,,,,다,,,디...

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ 간단한 Toy App만들기
✅ 운동 ㅋ
✅ 자존감지키기 ㅋㅋ

벌써 11월도 별로 안남았군요... 이제 남은건 크리스마스인가요~~ ㅋㅌㅋ

일찍 일어난겸 오전 운동을 다녀와서 의자에 앉아있습니다.

배운점

오늘은 iOS Academy에 있는 간단한 앱을 제작했습니다~

코드를 둘러보던중 익숙하지 않은 친구가 있더군요 ^^

바로 UserDefaults입니다.

UserDefaults
An interface to the user’s defaults database, where you store key-value pairs persistently across launches of your app.

Key-Value를 저장하는 기본 데이터베이스에 대한 인터페이스 라고 하군요

값 저장하기

UserDefaults.standard.set("Hello", forKey: "greet")

set(_:forKey:) 메서드를 사용하여 "Hello"란 문자열을 "greet"라는 키로 UserDefaults에 저장합니다.

값 가져오기

if let greet = UserDefaults.standard.string(forKey: "greet") {
    print(greet)
}
//Hello

string(forKey:) 메서드를 사용하여 "greet"에 저장되어있는 "Hello"문자열을 가져와 출력합니다.

값 제거하기

UserDefaults.standard.removeObject(forKey: "greet")

removeObject(forKey:) 메서드를 사용하여 "greet"에 해당하는 값을 제거합니다.

데이터 타입별 저장

// 숫자 저장
UserDefaults.standard.set(123, forKey: "onetwothree")

// 부울 저장
UserDefaults.standard.set(true, forKey: "isEmpty")

// 배열 저장
let fruits = ["Apple", "Banana", "Orange"]
UserDefaults.standard.set(fruits, forKey: "fruits")

UserDefaults는 작은 규모의 데이터를 다룰경우 사용된다고 합니다. 큰 규모의 데이터를 다룰 경우 외부 라이브러리나 CoreData를 사용 해야겠죠..? 그럼 CoreData도 알아야겠죠...?

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ Udemy 컴공선배 강의
✅ 운동

✅ Swift DelegatePattern

이번주만 탈락의 고배를 여러번 느꼈는데요,,하하 그러던중 오늘 한 영상을 보았습니다.

침착맨의 "대충 동기 부여하는 영상" 인데요, 조금 울적하던중 위로를 받았습니다 ^_^

궤도님이 한 말이 가장 마음에 남습니다.

"50%확률일때 하지않으면 다음 성공확률도 50%이다. 무조건 시도를 해봐야 다음 성공 확률이 올라간다는 의미입니다."

계속 도전하면서 다음 성공 확률을 조금씩 늘려가겠습니다 ^_^

나를 위로해준 최고 침착맨 고마워🙏

배운점

오늘은 간단히 회원가입을 할때 유효성 검사를 하기 위한 정규표현식을 같이 알아보았습니다.

    func isValidPassword() -> Bool {
        //비밀번호는 대,소문자,특수문자,숫자 and 8자이상
        let regularExpression = "^(?=.*[A-Z])(?=.*[a-z])(?=.*[\\d])(?=.*[~!@#\\$%\\^&\\*])[\\w~!@#\\$%\\^&\\*]{8,}$"
        let passwordValidation = NSPredicate.init(format: "SELF MATCHES %@", regularExpression)
        
        return passwordValidation.evaluate(with: self)
    }
    
    
    func isValidEmail() -> Bool {
        // @ 2글자
        let emailRegEx = "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,64}"
        let emailTest = NSPredicate.init(format: "SELF MATCHES %@", emailRegEx)
        
        return emailTest.evaluate(with: self)
    }

자주 쓰는 정규식

대문자만

"^[A-Z]*$"

소문자만

"^[a-z]*$"

숫자만

"^[0-9]*$"
"^[\\d]*$"

// 반대 (숫자 제외)
"^[\\D]*$"

알파벳 + 숫자

"^[0-9a-zA-Z]*$"
"^[\\w]*$"

// 반대 (알파벳, 숫자 제외)
"^[\\W]*$"

숫자, 알파벳, 특수문자 (~!@#$%^&*)

"^[0-9a-zA-Z~!@#\\$%\\^&\\*]*$"
"^[\\w~!@#\\$%\\^&\\*]*$"

최소 하나 이상 something

"(?=.*[something])"

최소 하나 이상의 대문자, 하나 이상의 소문자, 하나 이상의 숫자

"(?=.*[A-Z])(?=.*[a-z])(?=.*[\\d])"

최소 하나 이상의 대문자, 하나 이상의 소문자, 하나 이상의 숫자, 하나 이상의 특수문자(~!@#$%^&*), 그 외 불포함

"^(?=.*[A-Z])(?=.*[a-z])(?=.*[\\d])(?=.*[~!@#\\$%\\^&\\*])[\\w~!@#\\$%\\^&\\*]{8,}$"

생각과 감정

위로해준 침착맨에게 감사해🙏

앞으로의 계획선언

인스타그램 클론한후 기능 붙이기에 돌입해보겠습니다 ^_^ 빻쉬

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ udemy 완강 끄읕
✅ 패캠 강의
✅ 운동

가을은 어디갔죠...? 하ㅏㅎ... 날씨가 이리 추울 수 있나요ㅋㅋ 열어분 모두 감기 조심하세요~~
또 건조해져서 가습기가 없으면 안되는 계절이 왔네요...

오늘은 이것저것 자기소개서 쓰고 저를 밀어붙이기 위해 구매했던 강의를 들었습니다~~

(강의는 구매당시의 의지가 불타오르고 그이후엔 점점 불씨가 꺼지는건 저만그런가여...?)

배운점

SwiftUI Property Wrappers

@State

SwuftUI에서 상태를 처리하는 방법

뷰의 상태를 저장하는 프로퍼티로 상태 관리 주체는 해당 뷰

기본적으로 private 선언, 다른 뷰와 값을 소통하려면 Binding을 이용

값이 변경될 때마다 UI Update

@Binding

뷰와 상태를 바인딩 하는 방법

상위 @State 변수를 전달 받아 하위 뷰에서 캐치해 변화 감지 및 연결

Binding은 다른 뷰가 소유한 속성을 연결. 따라서 소유권 및 저장 공간이 없음

ObservableObject)프로토콜

클래스 프로토콜로 관찰하는 어떠한 값이 변경되면 변경사항을 알려줌

뷰에서 인스턴스 변화를 감지하기 위해 뷰모델 객체로 생성할 때 사용할 수 있음

@Published

ObservableObject를 구현한 클래스 내에서 프로퍼티 선언 시 사용

@Published로 선언된 프로퍼티를 뷰에서 관찰할 수 있음

ObservableObject에서 objectWillChange.send() 기능을 @Published 프로퍼티가 변경되면 자동으로 호출

@ObservableObject

뷰에서 ObservableObject 타입의 인스턴스 선언 시 사용

ObservableObject의 값이 업데이트되면 뷰를 업데이트함.

@StateObject

뷰에서 ObservableObject 타입의 인스턴스 선언 시 사용

뷰마다 하나의 인스턴스를 생성하며, 뷰가 사라지기 전까지 같은 인스턴스 유지

@ObservableObject의 뷰 렌더링 시 인스턴스 초기화 이슈 해결을 위한 방법

매번 인스턴스가 새롭게 생성되는것처럼 외부에서 주입 받는 경우가 아닌 최초 생성 선언 시에 @StateObject를 사용하는 것이 적절한 방법

@Enviroment

미리 정의되어 있는 시스템 공유 데이터

사용하려는 공유 데이터 이름을 keyPath로 전달하여 사용

시스템 공유 데이터는 가변하기에 var로 선언

뷰가 생성되는 시점에 값이 자동으로 초기화됨

@EnviromentObject

ObservableObject를 통해 구현된 타입의 인스턴스를 전역으로 공유하여 사용

앱 전역에 공통으로 사용할 데이터를 주입 및 사용

많이 의존하지 않기.

생각과 감정

오늘도 일찍 일어난 나에게 감사해🙏

급하게 말고 천천히 확실하게 가자🙏

나를 믿는 나에게 감사해🙏
감사함을 알려준 sAewoo에게 감사해🙏

앞으로의 계획선언

프로퍼티 래퍼를 간단하게 알아봤으니 Document를 보면서 공부를 해나가자 👏

짧은인사, 하루의 사건, 나의 행동

ToDo

✅ 운동
✅ Udemy Angela강의
✅ 패캠 강의
✅ 개인 프로젝트

다시는 게을러 지지 않는다 했지만.. 한달간 작성글이 없네요..하하... 반성하겠습니다..
공부는 자주 하지 않으면서 자기 합리화만 해왔던것 같네요... 공부는 잘 하지 않았어도 인턴 지원은 계속 하고있었습니다~ 하하 합격을 못해서 그렇지만요... 

저 혼자 감사 챌린지를 진행하고 있었습니다. 의욕이 없어지면서 당장 졸업을 해야하니 기분이 푹 꺼지더라구요..
그러던중 세우 라는 스트리머의 영상을 보면서 마음을 다잡았던것 같아요. 모든일에 감사를 붙이면 조금 힘이 된다구 하더라구요.. ㅋㅋ
무슨소리인줄 처음엔 감이 안잡혔지만 뭐 예를 들어 "아침에 늦잠 안잔 나에게 감사해🙏" 같이 모든 활동에 감사를 붙이니

머리속에 부정적인 생각이 사라지더라구요 하하 

의미는 찾지 않았지만 항상 긍정적이라고 생각해왔던 제가 요근래 부정적인 생각이 머리속을 가득 차있었어서

감사해 챌린지를 하니 부정적인 생각이 씻겨내려갔어요 캬캬 

여러분 모두 부정적인 생각에서 벗어나는 감사챌린지를 추천해드립니다 bb

오늘은 강의를 중점적으로 들었던것 같습니다. 델리게이트 패턴을 조금 맛봤는데요!! 아직 반숙도 아니니... 완숙이 될때까지 공부해보도록 하겠습니다.

앞으로의 계획선언

조금더 부지런히 살아야죠 지난달을 돌이켜보면 조금은 시간을 허투루 쓴것같습니다.. 강의 구매도 하였으니 매일 수강하고, 포트폴리오를 위한 개인 프로젝트를 진행해야겠습니다!! 

강의를 듣고 개인프로젝트를 진행하면서 델리게이트 패턴또한 파해쳐 보겠습니다!

미숙하고,, 완전하지않고,, 게을러진 나를 반성하며,, 화이팅...!!
(강의늪에 빠지지 않도록 주의하며 다 내꺼로 만들자)

다시 한번 마음을 잡은 나에게 감사해🙏

짧은인사, 하루의 사건, 나의 행동

흐 마지막으로 TIL을 작성한지가 언제지... Zzz ㅋㅌ 그동안 공부를 조금 소홀히 하긴 했지만 하루도 안한적은 옶습니다!!(주말 제외)

그.. 유데미의 엘런님 강의를 듣고 따라하고 다시보느라 TIL을 작성하는 시간이 없었네요!!
하지만~~ 이강의도 거의 끝나가니 패캠에서 새로운 강의를 구매해서 보는중입니다!!

앨런님의 강의는 UIkit 이지만  패캠 강의는 스유라는 사쉴 굉장히 익숙하지 않지만 UIkit보단 접근하기

편한것,,,, 같기도,,?? 아닌가~~

델리게이트 패턴에 대해서 한번 정리 하고자 왔습니다!~

(10/14에 밴드 공연을 해서 이번주와 다음주는 조금 바쁠 예정인것 같네요.. 그래도 짬내서 해야지...)

뭐라도 해야지.....

배운점

 UITableViewDataSource, UITableViewDelegate를 사용했지만 정확하게 이해를 하진 못하고 사용을 해왔습니다..

항상 아는 듯 모르는 듯한 Delegate Pattern을 공부 해보도록 하겠습니다..

Delegation

위임은 클래스 또는 구조체가 책임의 일부를 다른 타입의 인스턴스에 넘겨주거나 위임할 수 있도록 하는 디잔인 패턴입니다.

이 디자인 패턴은 위임된 기능을 제공하기 위해 준수하느느 타입이 보장되도록 위임된 책임을 캡슐화 하는 프로토콜을 정의하여 구현합니다.

예제를 보면서 이해하겠습니다!

protocol DiceGame {
    var dice: Dice { get }
    func play()
}
protocol DiceGameDelegate: AnyObject {
    func gameDidStart(_ game: DiceGame)
    func game(_ game: DiceGame, didStartNewTurnWithDiceRoll diceRoll: Int)
    func gameDidEnd(_ game: DiceGame)
}

DiceGame 프로토콜은 dice변수와 play라는 함수를 가집니다. 주사위와 관련된 모든 게임에서 채택될 수 있는 프로토콜 입니다.

프로토콜은 강력한 참조 순환을 방지하기 위해 위임자는 약한 참조로 선언됩니다.

//Example
weak var delegate: SecondViewControllerDelegate?

class SnakesAndLadders: DiceGame {
    let finalSquare = 25
    let dice = Dice(sides: 6, generator: LinearCongruentialGenerator())
    var square = 0
    var board: [Int]
    init() {
        board = Array(repeating: 0, count: finalSquare + 1)
        board[03] = +08; board[06] = +11; board[09] = +09; board[10] = +02
        board[14] = -10; board[19] = -11; board[22] = -02; board[24] = -08
    }
    weak var delegate: DiceGameDelegate?
    func play() {
        square = 0
        delegate?.gameDidStart(self)
        gameLoop: while square != finalSquare {
            let diceRoll = dice.roll()
            delegate?.game(self, didStartNewTurnWithDiceRoll: diceRoll)
            switch square + diceRoll {
            case finalSquare:
                break gameLoop
            case let newSquare where newSquare > finalSquare:
                continue gameLoop
            default:
                square += diceRoll
                square += board[square]
            }
        }
        delegate?.gameDidEnd(self)
    }
}

위의 코드는 Snake and Ladders의 게임 버전 입니다.

제가 이 보드게임은 처음이라... 코드만 확인 하겠슴다 ㅎㅎ

SnakesAndLadders의 클래스는 DiceGame의 프로토콜을 채택 합니다. 상속으로 표시됩니다.

weak var delegate: DiceGameDelegate?

위에서 말했듯이 강력한 참조 순환을 방지하기 위해 위임자는 약한 참조로 선언됩니다.

프로토콜을 준수하기 위해 dice프로퍼티와 play() 메서드를 제공합니다.

class DiceGameTracker: DiceGameDelegate {
    var numberOfTurns = 0
    func gameDidStart(_ game: DiceGame) {
        numberOfTurns = 0
        if game is SnakesAndLadders {
            print("Started a new game of Snakes and Ladders")
        }
        print("The game is using a \(game.dice.sides)-sided dice")
    }
    func game(_ game: DiceGame, didStartNewTurnWithDiceRoll diceRoll: Int) {
        numberOfTurns += 1
        print("Rolled a \(diceRoll)")
    }
    func gameDidEnd(_ game: DiceGame) {
        print("The game lasted for \(numberOfTurns) turns")
    }
}

위의 예제는 DiceGameTracker클래스가  DIceGameDelegate 프로토콜을 채택합니다.

......계속 Document를 읽는데 무언가 확 와닿게 이해가 되지 않았습니다.. 

개발 블로그를 참고하여 이해를 도왔습니다 ㅎㅎ

Delegate pattern??

"객체가 자신의 책임을 다른 객체에게 위임 하는 디자인 패턴"

그럼 왜 "위임"을 하는거지??

UI의 Delegate Pattern

// Delegate Protocol
protocol UITableViewDelegate: AnyObject {
    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath)
}

// Delegating Object
class UITableView {

    weak var delegate: UITableViewDelegate?

    func didSelectedRowAt(indexPath: IndexPath) {
        delegate?.tableView(self, didSelectRowAt: indexPath)
    }
}

// Delegate Object
class ViewController: UITableViewDelegate {

    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        print(indexPath)
    }
}

UITableView의 내부 코드를 수정할 수 없기에 다른 객체에게 위임을 하는 것이다!!

셀이 탭되었을때 어떤 행동을 할지는 상황마다 다르기에 개발자가 코드를 작성한다. 하지만 숨겨진 TableView의 코드를

수정할 수 없기에 다른 객체에게 해당 코드를 작성한 뒤, TableView가 그 객체의 코드를 호출해줘야 한다.

이 때 테이블 뷰와 객체를 연결해주는 방식이 DelegatePattern이다!!

Delegate Pattern의 핵심은 두 객체를 연결하는 것, 두개의 객체가 효율적으로 소통하도록 도와주는 것이다!

생각과 감정

많이 쓰던 내용인 Delegate를 깊게 들어가보진 않았지만,, 이제야 깨닫네요 하하.. Document는 저랑 맞지 않는건지 아직 이해가 완벽히 되지 않는것인진 몰겠지만,, 한국인이 정리한 개발블로그 너무 감사드립니다... 으아ㅏ.... 덕분에 이해가 잘됐습니다!!

앞으로의 계획선언

앞으로의 계획 ㅋ 살아남아야한다....

https://docs.swift.org/swift-book/documentation/the-swift-programming-language/protocols/

https://velog.io/@nala/iOS-Delegate-%ED%8C%A8%ED%84%B4%EC%9D%84-%EC%9D%B4%ED%95%B4%ED%95%B4%EB%B3%B4%EC%9E%90

짧은인사, 하루의 사건, 나의 행동

사람이 나태해지면 안됩니다... 여러분... 

어제밤인지 엊그제 밤인지 자기전에 문득 의심이 들었네요. 내가 가는 이 길이 어디로 가는지~ 어디로 날 데려가는지~ ㅋㅋ

잠깐 의심했습니다. 하하 자기전에 생각이 많아지는건 저뿐인가요~? 

요즘 OPIC을 공부하는중인데 쉬운거 하나없죠~~ 유튜브에선 "선생님 강의 듣고 첫 시험부터 IL 받았어요~~" 라는 글밖에 보이지 않더라군요 하하

매년 영어를 접하였지만 실상 할지는 못하는 이 현실 ㅋ 입으로 뱉어보려 하면 밈 잔치가 일어납니다.. (다 힙플밈 때문이야 ㅈㅅㅋ)

여튼 이런 저런 생각을 접어두고 하던거를 계속 하려 합니다~

어제는 강의를 들어서 TIL을 못적었네요 (핑계) 

네 강의에서 MVC패턴에 대해서 공부를 하였는데 인터넷엔 없는것이 없죠?? 아주 정리를 잘한 여러 블로그에서 공부를 하였습니다.

배운점

디자인 패턴?

디자인 패턴은 보편적인 문제에 대한 증명된 해결책일 뿐입니다.

Xcode를 처음 접했을땐 ViewController에 모든 코드가 채워져 있습니다.

하지만 다른 View들이 만들어진다면 더욱 힘들어 지기 마련입니다.

MVC?

MVC 는 Model View Controller 의 약자 입니다.

Model : 어플리케이션이 "무엇"을 할것인지 정의합니다. 내부 비즈니스 로직을 처리하기 위한 역할을 할 것 입니다, 

앱에 포함 되어야 하는 데이터를 정의합니다.

View : 화면에 "무엇"을 "보여주기 위한 역할"을 합니다. 컨트롤러의 하위에 종속되어, 모델이나 컨트롤러가 보여주려 하는 모든 필요한 것을 보여줄 것입니다. 또한 사용자가 보는 화면이죠.

앱의 데이터가 표시되는 방법을 정의합니다.

Controller : Model과 View가 각각 무엇을 해야 할 지 알고 있고, 통제합니다. 비즈니스 로직을 처리하는 Model과 완전히 UI에 의존적인 View가 서로 직접 이야기 할 수 없게 합니다.

앱 사용자의 입력에 응답하여 모델, 뷰를 업데이트 하는 로직이 포함되어 있습니다.

생각과 감정

아직 비기너라 처음부터 나누어서 코드를 작성하는 것에 대해 감은 가져지지 않습니다.. 하지만 채용공고에서 늘상 보는 MVC, MVVM 패턴 항상 나오죠! 저도 찬찬히 알아가야 합니다!!

앞으로의 계획선언

다은은 MVVM패턴에 대해 알아 볼 것 입니다!

짧은인사, 하루의 사건, 나의 행동

금, 토, 일요일을 신나게 쉬었습니다.. 하하 금요일은 어머니 생신을 같이 보냈구요, 토요일은 여자친구와 함께 시간을 보냈습니다~ 
일요일은 늑연골염 덕분에 거의 누워있었던것 같습니다...

이정도면 많이 쉬었군요. 어제 장수상회를 보며 눈물을 질질 흘렸습니다.. 얼마나 슬프던지 배우분들을 보면서 할머니랑 할아버지 생각이 나 눈물이 더 많이 났던것 같네요.. 여러분들도 한번쯤은 보면 좋은 영화입니다 가족애 뿜뿜 ㅎㅎ 

흐 계속 쉬고싶지만.. 누워만 있는건 조금 찔리는것 같네요 하하하...흐...ㅎ...ㅡ....ㅠㅠ,,,,

배운점

저번에 다하지 못한 미소유 참조 와 약한참조를 공부해보겠습니다!

약한 참조

약한 참조는 참조하는 인스턴스를 강하게 유지하지 않는 참조이므로 ARC가 참조된 인스턴스를 처리하는것을 중지하지 않는다고 합니다.

이 동적운 참조가 강한 참조 사이클의 일부가 되는 것을 방지합니다!

프로퍼티나 변수의 선언 앞에 weak 키워드를 위치시켜 약한참조를 나타냅니다.

약한 참조는 참조하는 인스턴스를 강하게 유지하지 않기 때문에 약한 참조가 참조하는 동안 인스턴스가 할당 해제 될 수 있습니다!

따라서 ARC는 인스턴스가 해제되면 nil 로 약한 참조를 자동으로 설정합니다.

따라서 nil 로 바뀌는 것을 허락 해야하므로 옵셔널 타입의 변수로 선언됩니다.

다른 옵셔널 값과 같이 약한 참조에 값의 존재를 확인할 수 있고, 더이상 존재하지 않는 유효하지 않은 인스턴스에 참조하는것으로 끝나지 않습니다 (????) -> 약한 참조는 옵셔널 값과 유사하지만, 옵셔널 값처럼 유효하지 않은 인스턴스를 참조할수 없다는 것을 의미하는것 같네요..

class Person {
    let name: String
    init(name: String) { self.name = name }
    var apartment: Apartment?
    deinit { print("\(name) is being deinitialized") }
}

class Apartment {
    let unit: String
    init(unit: String) { self.unit = unit }
    weak var tenant: Person?
    deinit { print("Apartment \(unit) is being deinitialized") }
}

위의 코드는 Apartment 클래스의 tenant 프로퍼티는 약한참조로 선언되었습니다.

var john: Person?
var unit4A: Apartment?

john = Person(name: "John Appleseed")
unit4A = Apartment(unit: "4A")

john!.apartment = unit4A
unit4A!.tenant = john

이전과 같이 john과 ubut4A는 강한참조로 연결됩니다.

Person 인스턴스는 Apartment 인스턴스에 대해 강한 참조를 가지고 있지만 Apartment 인스턴스는 Person 인스턴스에 대해 약한참조를 가지고 있습니다. -> john 변수에 nil 을 할당하여 강한참조를 끊으면 Person 인스턴스에 대해 더이상 강한참조가 아님을 의미합니다.

john = nil
// Prints "John Appleseed is being deinitialized"

더이상 Person 인스턴스에 대해 강한 참조를 가지고 있지 않기 때문에 할당 해제되고 tanant 프로퍼티는 nil 이 됩니다.

Apartment 인스턴스에 대한 유일한 참조는 unit4A 변수에서 가져온 것입니다. 강한참조를 끊으면 Apartment 인스턴스에 대한 강한참조는 더이상 없습니다.

unit4A = nil
// Prints "Apartment 4A is being deinitialized"

Apartment에 대한 강한참조가 없으니 할당 해제 됩니다.

미소유 참조

미소유 참조는 약한 참조와 같이 인스턴스를 강하게 유지하지 않습니다. 하지만 약한 참조와 다르게 미소유 참조는 다른 인스턴스의 수명이 같거나 더 긴 경우에 사용됩니다.

프로퍼티 선언 앞부분에 unowned 키워드를 붙여 미소유 참조를 나타냅니다.

약한 참조와 달리 미소유 참조는 항상 값을 갖도록 예상됩니다. 따라서 미소유로 만들어진 값은 옵셔널이 아니고, ARC는 미소유 참조의 값을 nil로 할당하지 않습니다.

class Customer {
    let name: String
    var card: CreditCard?
    init(name: String) {
        self.name = name
    }
    deinit { print("\(name) is being deinitialized") }
}

class CreditCard {
    let number: UInt64
    unowned let customer: Customer
    init(number: UInt64, customer: Customer) {
        self.number = number
        self.customer = customer
    }
    deinit { print("Card #\(number) is being deinitialized") }
}

위의 예제는 Customer 와 CreditCard의 관계입니다. 고객은 신용카드를 가지고 있거나 아닐수 있지만, 신용카드는 항상 고객과 연관되어 있습니다.

신용카드의 인스턴스는 참조하는 고객보다 오래 지속되지 않습니다. -> 고객 클레스는 옵셔널 card를 가지지만, 신용카드 클래스는 미소유와 옵셔널이 아닌 customer 프로퍼티를 가집니다.

신용카드는 항상 고객을 가지고 있으므로 강한 참조 사이클을 피하기 위해 customer 프로퍼티에 미소유 참조로 정의합니다.

var john: Customer?

john = Customer(name: "John Appleseed")
john!.card = CreditCard(number: 1234_5678_9012_3456, customer: john!)

john에 Customer 인스턴스를 할당하고, card프로퍼티에 CreditCard 인스턴스를 할당합니다.

Customer 인스턴스는 CreditCard 인스턴스에 강한 참조를 가지고 있고, CreditCard 인스턴스는 customer에 대해 미소유 참조를 가지고 있습니다.

john변수에 의해 강한 참조를 끊을때 미소유 customer 참조 때문에 Customer 인스턴스에 대해 더이상 강한 참조를 가지지 않습니다.

john = nil
// Prints "John Appleseed is being deinitialized"
// Prints "Card #1234567890123456 is being deinitialized"

john에 nil을 설정하면 Customer과 CreditCard 인스턴스 모두 초기화 해제 됩니다.

(이해를 위한 덧붙임)

- 은행 고객 A가 신용카드 B를 가지고 있습니다.

Customer 클래스의 인스턴스 A가 생성됩니다.

CreditCard 클래스의 인스턴스 B가 생성됩니다.

A의 card 프로퍼티에 B를 할당합니다.

B의 customer 프로퍼티에 A를 할당합니다.

- 은행 고객 A가 신용카드 B를 해지 합니다.

A의 card 프로퍼티에서 B를 삭제합니다.

B의 customer 프로퍼티에서 A를 삭제합니다.

A의 인스턴스가 해제됩니다.

B의 인스턴스가 해제됩니다.

생각과 감정

한번 읽어서는 이해가 안되는 부분이 너무 많군요.. 미소유참조 약한참조 둘다 두번이상은 읽은것 같습니다... 

이해가 빠릿빠릿 하게 되었으면 하네요..ㅠㅠ

조금씩 정진합시다 정진!

앞으로의 계획선언

내일부터는 졸업을 위한 OPIC공부와 정보처리기사 준비를 같이 해야할것 같네요!! 문서는 짬나거나 궁금한것이 있을때

다시한번 보는걸로 하고,,,, 앱개발 인강을 들으며 내실을 쌓아야 하겠습니다!!

짧은인사, 하루의 사건, 나의 행동

안녕하세요~ >< 오늘은 앉아있기 어려운 관계로.. 대부분 쉬어야 겠습니다.. 저녁에 취미로 하는 밴드 합주도 가야하구요 하하

원래는 내일인 금요일에 합주가 예정이었는데 어머니 생신을 토요일로 알고있어서 금요일로 정하였지만, 알고보니 금요일이더군요!! 음력...익숙치않아..(사실 캘린더에 잘못 적음 ㅋ) 하튼 일자목으로 목도 아프고.. 늑연골염?으로 가슴이 매우 아픕니다 ㅋㅋ

운동을 쉬라고 하더군요... 하지만 쉴수 없기에 가슴을 제외한 운동을 진행할것입니다.. 저는... 언제나.. 방법을.. 찾을것입니다...

배운점 (자동 참조 카운팅 : Automatic Reference Counting)

Swift는 앱의 메모리 사용량을 추적하고 관리하기 위해 자동 참조 카운팅을 사용합니다!

참조 카운팅은 클래스의 인스턴스에만 적용됩니다. 구조체와 열거형은 참조 타입이 아니고 값타입이고 참조로 저장되거나 전달되지 않습니다!!

ARC의 작동 원리

클래스의 새로운 인스턴스가 생성될 때마다 ARC는 인스턴스에 대한 정보를 저장하기 위해 메모리의 청크에 할당합니다.
(메모리 청크 : 동적으로 메모리를 할당할 때 사용되는 일정한 크기의 메모리 블록)

이 메모리는 해당 인스턴스와 관련된 저장된 프로퍼티의 값과 함께 인스턴스의 타입에 대한 정보를 가집니다.

또한 인스턴스가 더이상 필요치 않을 때 ARC는 메모리가 다른 목적으로 사용될 수 있도록 인스턴스에 의해 사용된 메모리를 할당 해제합니다. (이렇게 하면 메모리를 효율적으로 관리할 수 있겠군요!)

하지만 ARC가 아직 사용중인 인스턴스의 할당을 해제하면 더이상 인스턴스의 프로퍼티에 접근할 수 없거나 인스턴스의 메모리를 호출할 수 없습니다. (인스턴스에 접근하려 하면 앱은 크래시가 발생한다고 합니다.)

ARC 동작

class Person {
    let name: String
    init(name: String) {
        self.name = name
        print("\(name) is being initialized")
    }
    deinit {
        print("\(name) is being deinitialized")
    }
}

위의 예제는 ARC의 동작에 대한 예제 입니다.

var reference1: Person?
var reference2: Person?
var reference3: Person?

Person에 여러개의 참조를 설정하기 위해 Person? 타입의 3개 변수를 정의합니다. 

옵셔널 타입이므로 nil 값으로 자동으로 초기화되고 현재는 Person 인스턴스를 참조하지 않고 있습니다.

reference1 = Person(name: "John Appleseed")
// Prints "John Appleseed is being initialized"

새로운 Person의 인스턴스는 reference1 변수에 할당되기 때문에 강한 참조가 있습니다.

하나의 강한 참조가 있기 때문에 ARC는 이 Person을 메모리에 유지하고 할당 해제하지 않습니다.

reference2 = reference1
reference3 = reference1

위의 예제로 이제 Person의 인스턴스에 3개의 강한 참조가 있습니다.

reference1 = nil
reference2 = nil

2개의 변수에 nil을 할당하여 강한 참조 3개중 2개가 중단되어 1개의 강한참조만 남고 Person 인스턴스는 할당 해제되지 않습니다.

reference3 = nil
// Prints "John Appleseed is being deinitialized"

마지막 강한 참조를 중단하여 Person 인스턴스는 할당 해제 됩니다.

클래스 인스턴스 사이의 강한 참조 사이클

ARC동작의 예제에선 Person 인스턴스를 생성하고 더이상 필요치 않을 때 Person 인스턴스 할당 해제하기 위해 참조의 수를 추적할 수 있습니다.

그러나 클래스의 인스턴스가 강한 참조가 없는 지점에 도달하지 않는 코드를 작성할 수 있습니다. 이는 두 클래스 인스턴스가 서로에 대한 강한 참조를 유지하여 각 인스턴스가 다른 인스턴스를 유지하는 경우 발생할 수 있습니다! 이를 강한 참조 사이클 이라고 합니다.

(예제를 보며 이해를 돕겠습니다~~)

class Person {
    let name: String
    init(name: String) { self.name = name }
    var apartment: Apartment?
    deinit { print("\(name) is being deinitialized") }
}

class Apartment {
    let unit: String
    init(unit: String) { self.unit = unit }
    var tenant: Person?
    deinit { print("Apartment \(unit) is being deinitialized") }
}

위의 예제에서 Person 인스턴스는 String 타입의 name 프로퍼티와 초기값인 nil 인 옵셔널 apartment 프로퍼티를 가지고 있습니다.

(사람이 항상 아파트를 가지고 있지 않기 때문에 apartment 프로퍼티는 옵셔널 입니다.)

Apartment는 Person과 비슷하기 String 타입의 unit 프로퍼티와 초기값이 nil 인 옵셔널 tenant 프로퍼티를 가지고 있습니다.

(아파트를 항상 보유하는 것은 아니므로 tenant 프로퍼티는 옵셔널 입니다. 아파트는 항상 거주자를 보유하지 않으니까 로 이해해도 괜찮은건지...)

var john: Person?
var unit4A: Apartment?

옵셔널 타입의 2개의 변수를 정의합니다.

이제 특정 Person 인스턴스와 Apartment 인스턴스를 생성할 수 있습니다.

john = Person(name: "John Appleseed")
unit4A = Apartment(unit: "4A")

다음은 강한 참조가 이 두 인스턴스를 생성하고 할당하여 어떻게 보이는지 나타냅니다.

john변는 이제 새로운 Person 인스턴스에 대한 강한 참조를 가지고 있고, unit4A는 Apartment 인스턴스에 대해 강한 참조를 가지고 있습니다.

john!.apartment = unit4A
unit4A!.tenant = john

이제 사람은 아파트를 가지고 아파트는 소유자를 가지도록 두 인스턴스를 연결했습니다.
위의 예제로써 강한참조가 밑의 그림처럼 바뀌었습니다.

불행히도? 이 두인스턴스 연결은 강한 참조 싸이클을 생성합니다. 따라서 john과 unit4A변수에 의해 가진 강한 참조를 중단할 때 참조 카운트는 0으로 떨어지지 않고 인스턴스는 ARC에 의해 할당 해제되지 않습니다.

(참조가 발생할경우 ARC에 의해 참조 카운트가 1씩 증가, 참조가 해제되면 1감소)

john = nil
unit4A = nil

위의 코드로 nil로 설정할때 초기화 해제 구문은 호출이 되지 않습니다.

강한 참조 사이클은 Person과 Apartment 인스턴스가 할당 해제되는 것을 방지하여 앱에서 메로리 누수를 유발합니다!

따라서 Person과 Apartment 인스턴스 간의 강한 참조는 남아있고 중단 될 수 없습니다.

클래스 인스턴스 간의 강한 참조 사이클 해결

위와같은 문제를 해결하기 위해 Swift는 2개의 해결방법을 제공합니다.

1. 약한 참조 (weak reference)

2.미소유 참조 ( unowned reference )

이 2개를 사용하면 참조 사이클의 한 인스턴스가 강한 유지 없이 다른 인스턴스를 참조할 수 있습니다.

약한 참조를 사용하는 경우

다른 인스턴스의 수명이 더 짧은 경우 즉, 다른 인스턴스가 먼저 할당 해제 될 수 있을 때 약한 참조를 사용합니다. 

위의 Apartment 예제에서 아파트는 어느 시점에 소유자가 없을 수 있는 것이 적절하므로 이경우 약한 참조를 사용하여 참조 사이클을 끊는 것이 적절한 경우 입니다.

미소유 참조를 사용하는 경우

다른 인스턴스의 수명이 동일하거나 더 긴 경우 미소유 참조를 사용합니다.

(오느른 여기까지...)

생각과 감정

건강하자고 한 운동이 잘못된 자세로 인해 건강을 해치고 있었군요... 그리고 컴퓨터를 많이해 일자목이.. 큽...

여러분도 자세 바르게하는 습관을 꼭 유지하세요....

요즌 document를 읽으면서 느끼는 감정이 대학 1, 2학년에 새로운 언어를 배울때 느끼는 감정과 조금은 비슷하네요ㅋ..

사실 그때는 이런걸 배우는 이유는 생각하지 않고 그냥 just 배워~ 학점을 위해서 머리에 때려넣고 까먹었는데

지금은 절대.. 절대는 모르겠지만 머리에 계속 남아있게 한번씩 들려서 다시 봐야겠어요.. 그리고 조금은 재밌다랄까요?

언어의 특징을 배우면서 한발짝은 아니어도 조금은 Swift와 친해졌다는 느낌이 많이 듭니다 ㅎㅎ

참조를 배우면서 예전에 다른 언어에서 배운것에대한 기본기는 조금? 비슷해서 이해하기 수월했습니다.. 그래도 조금 수월한 것이지 많이 어렵네요 ㅎㅎ

앞으로의 계획선언

빨리 회복해서 다음 약한참 조와 미소유 참조를 공부 하도록 하겠습니다!! 
그리고 개인 프로젝트를 준비해야겠어요 마냥 document만 읽고있을수는 없으니 간단한 앱으로 시작하며 성장하겠습니다~~

모두들 화이팅!