🔥학습 내용

UML(Unified Modeling Language)

1. UML이란 무엇인가?

• UML이란 Unified Modeling Language 약자로, 통합 모델링 언어이다. 즉, 모델을 만드는 표준언어라고 이해하면 될 것이다.
• UML은 소프트웨어 집약 시스템의 시각적 모델을 만들기 위한 도안 표기법을 포함한다.

2. UML을 왜 사용하는가?

• 객체 지향 프로그래밍 소프트웨어 집약 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화할 때 사용한다.
• 다음과 같이 UML을 사용하는 유형을 알 수 있다.
  • 다른 사람들과의 의사소통 또는 설계 논의
  • 전체 시스템의 구조 및 클래스의 의존성 파악
  • 유지보수를 위한 설계의 back-end 문서

3. UML 종류는 어떻게 되는가?

• UML은 다양한 형태로 존재한다. 가장 많이 사용하는 것은 클래스 다이어그램이라고 할 수 있겠다.

#. 참고URL

• https://ko.wikipedia.org/wiki/%ED%86%B5%ED%95%A9_%EB%AA%A8%EB%8D%B8%EB%A7%81_%EC%96%B8%EC%96%B4
• https://www.nextree.co.kr/p6753/

🔥학습 내용

ARC(Automatic Reference Counting)

1. ARC란 무엇인가?

• Swift는 앱의 메모리 사용을 추적하고 관리하기 위해 ARC를 사용한다.
• ARC는 클래스 인스턴스가 더 이상 필요하지 않을 때, 그 인스턴스에 의해 사용되는 메모리를 자동으로 할당 해제한다.

2. ARC는 어떻게 작동하는가?

• 클래스의 인스턴스를 생성할 때마다, ARC는 그 인스턴스에 대한 정보를 저장할 메모리의 덩어리를 할당한다. → 이 메모리는 그 인스턴스와 관련이 있는 모든 stored property 값과 함께 인스턴스의 타입에 대한 정보를 갖는다.
• 인스턴스가 더 이상 필요하지 않을 때, ARC는 그 인스턴스에 의해 사용되는 메모리를 할당 해제하게 되고 그 메모리가 다른 목적으로 사용될 수 있게 한다. → 클래스의 인스턴스가 더 이상 필요하지 않을 때 메모리에 공간을 차지하지 않도록 보장해주는 것이다.

#. 참고URL

• https://www.slideshare.net/LeeDaheen/swift-arc-152213706
• https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/

🔥학습 내용

App Delegate, Scene Delegate

1. App Delegate란 무엇인가?

• 앱 전체의 생명주기를 관리한다. (앱 실행, 종료, 백그라운드/포어그라운드 전환 등 앱 전체에 영항을 미치는 이벤트를 처리한다.)
• App Delegate는 앱 전체의 생명주기 동안 존재한다. 앱이 실행될 때 처음 생성되고 앱이 종료될 때까지 메모리에 유지된다.
• 모든 iOS 앱에서 필수적으로 사용해야 한다.
• iOS 12 버전 그리고 그 이전 버전은 App Delegate를 사용했다.

2. App Delegate가 처리하는 이벤트

• 앱 실행 시점 (application:didFinishLaunchingWithOptions:)
• 앱 백그라운드/포어그라운드 전환 (applicationWillResignActive:,applicationDidBecomeActive:)
• 앱 종료 시점 (applicationWillTerminate:)
• 메모리 경고 시점 (applicationDidReceiveMemoryWarning:)
• URL 처리 (application:openURL:options:)
• 푸시 알림 처리 (application:didReceiveRemoteNotification:fetchCompletionHandler:)

이밖에도 상당히 많은 이벤트 처리를 할 수 있는 것을 알 수 있다.

3. Scene Delegate란 무엇인가?

• 씬의 생명주기를 관리한다. (씬이란? 앱의 특정 기능이나, 콘텐츠를 나타내는 단위 -> 하나의 창이라고 생각하면 될 것 같다.)
• 씬 연결, 연결 해제, 활성화/비활성화 등 씬과 관련된 이벤트를 처리한다.
• iOS 13 이상에서만 사용할 수 있고, 씬을 사용하는 앱에서만 필요하다.

4. Scene Delegate가 처리하는 이벤트

• 씬 연결 시점 (scene:willConnectToSession:options:)
• 씬 연결 해제 시점 (sceneDidDisconnect:)
• 씬 활성화 시점 (scene:didBecomeActive:)
• 씬 비활성화 시점 (sceneWillResignActive:)

App Delegate와는 다르게 이벤트 처리가 상당히 많지 않다는 것을 알 수 있다.

#.참고URL

• https://developer.apple.com/documentation/uikit/uiapplicationdelegate
• https://developer.apple.com/documentation/uikit/uiscenedelegate

🔥학습 내용

타입 프로퍼티(Type Property)

1. 타입 프로퍼티란 무엇인가?

• 각각의 인스턴스가 아닌 타입 자체애 속하는 프로퍼티를 타입 프로퍼티라고 한다.
• 인스턴스의 생성 여부와 상관없이 타입 프로퍼티의 값은 하나이다. 그래서 그 타입의 모든 인스턴스가 공통으로 사용하는 값, 모든 인스턴스에서 공용으로 접근하고 값을 변경할 수 있는 변수를 선언할 때 아주 유용하다.

2. 타입 프로퍼티의 구조

• 타입 프로퍼티는 static 키워드를 붙여준다.
• 아래의 예시를 보면 확인할 수 있다.

  struct SomeStructure {
    static var storedTypeProperty = "Some value."
    static var computedTypeProperty: Int {
        return 1
    }
  }
  enum SomeEnumeration {
    static var storedTypeProperty = "Some value."
    static var computedTypeProperty: Int {
        return 6
    }
  }
  class SomeClass {
    static var storedTypeProperty = "Some value."
    static var computedTypeProperty: Int {
        return 27
    }
    class var overrideableComputedTypeProperty: Int {
        return 107
    }
  }

print(SomeStructure.storedTypeProperty)
// Prints "Some value."
SomeStructure.storedTypeProperty = "Another value."
print(SomeStructure.storedTypeProperty)
// Prints "Another value."
print(SomeEnumeration.computedTypeProperty)
// Prints "6"
print(SomeClass.computedTypeProperty)
// Prints "27"

#.참고URL

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

🔥학습 내용

LLDB

1. LLDB이란 무엇인가?

• LLDB는 LLVM의 프론트엔드단에 오류를 찾기 위한 디버거 도구이다.
• LLDB 공식 문서에서는 아래와 같이 설명한다. LLDB is a next generation, high-performance debugger. It is built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler.

✔︎ LLVM이란?

• LLVM 프로젝트는 모듈식의 재사용 가능한 컴파일러와 툴체인의 집합이다.
• 해당 컴파일러는 프론트엔드-미들엔드-백엔드의 단계로 구성되어 있다.

2. Debugging이란 무엇일까?

• 버그를 잡는 것

#.참고URL

• https://lldb.llvm.org/
• https://namu.wiki/w/LLVM

🔥학습 내용

SOLID 원칙

1. SOLID 원칙이란 무엇인가?

• SOLID 원칙은 객체지향 설계에서 지켜야 할 5개의 소프트웨어 개발 원칙을 말한다.

2. SOLID 원칙의 종류

• SRP(Single Responsibility Principle): 단일 책임 원칙
• OCP(Open Closed Principle): 개발 폐쇄 원칙
• LSP(Listov Substitution Principle): 리스코프 치환 원칙
• ISP(Interface Segregation Principle): 인터페이스 분리 원칙
• DIP(Dependency Inversion Principle): 의존 역전 원칙

3. SOLID 원칙을 왜 지키는 게 좋을까?

• 좋은 코드와 높은 품질을 얻기 위해서이다.
• 좋은 코드란 무엇일까? 재사용이 가능하고, 유지보수가 좋아야 하며 가독성이 좋아야할 것이다.
• SOLID 원칙을 적용하면 불필요한 복잡성을 제거해 리팩토링에 소요되는 시간을 줄임으로써 프로젝트 개발의 생산성을 높일 수 있다.

4. SRP(Single Responsibility Principle): 단일 책임 원칙

• 클래스의 수정 이유는 단 하나여야 한다.
• 하나의 클래스는 하나의 책임만 가져야 한다.
• 하나의 책임이 여러개의 클래스에 나뉘어 있으면 안된다.
• 하나의 클래스안에 협력관계가 여러개가 있는 것은 괜찮다.(?)

🚩 높은 응집도와 낮은 결합도를 지키는 것이 단일 책임 원칙을 지키는 것이라 볼 수 있다.

5. OCP(Open-Closed Principle): 개방 폐쇄 원칙

• 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다.
• 객체가 변경될 때에는 해당 객체만 바뀌어도 동작이 잘되면 OCP를 잘 지킨것이라 볼 수 있다.

🚩 내부적으로 하나의 케이스가 사라지거나 수정이 됬다고 다른 게 영향이 있다면 폐쇄 원칙을 지키지 못한 것이다.

6. LSP(Listov Substitution Principle): 리스코프 치환 원칙

• 자식 클래스는 부모의 역할은 온전히 다할 수 있다.
• 자식 클래스는 부모 클래스의 동작을 바꿀 순 없다.

7. DIP(Dependency Inversion Principle): 의존관계 역전 원칙

• 상위레벨 모듈은 하위레벨 모듈에 의존하면 안된다.

8. ISP(Interface Segregation Principle): 인터페이스 분리 원칙

• 클래스내에서 사용하지 않는 인터페이스는 사용하지 말아야 한다.
• 즉, 프로토콜을 잘 분리해서 사용해야한다. 클래스에서 해당 프로토콜을 채택했는데 메소드를 굳이 사용할 필요가 없다면..??

#.참고URL

• https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84%EC%9D%98-5%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-SOLID
• https://ko.wikipedia.org/wiki/SOLID_%28%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84%29

🔥학습 내용

Super View, Sub View의 차이

1.View(뷰)란 무엇인가?

• View는 자신의 콘텐츠를 보여주고, 다른 뷰를 위한 컨테이너의 역할을 한다.
• 컨테이너의 역할이 궁금할 수도 있겠다. 뷰는 스택 형식으로 쌓인다고 보면 될 것 같다. Root View라고 하는 첫 Load된 View가 있을 것이다. 필요에 따라 Root view가 아닌 다른 뷰가 불리게 될 것 이다. 이럴 때, 해당 Root view는 다른 뷰를 위해 컨테이너 역할이 되어 준다.

2. Super view와 Sub View는 무엇인가?

• 뷰가 다른 뷰를 포함할 때 자식뷰를 서브뷰(Sub view)라고 하고, 그 부모뷰를 슈퍼뷰(Super view)라고 한다.

#.참고URL

• https://underside.tistory.com/68

🔥학습 내용

Unit Test(유닛테스트)

1. Unit Test란 무엇인가?

• 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는 지 검증하는 절차이다.
• 모든 함수와 메소드에 대한 테스트 케이스(Test Case)를 작성하는 절차이다.

2. Unit Test 왜 할까?

• Unit Test를 하게 되면, 나중에 단일 모듈끼리 통합될 때 터지는 부분을 방지할 수 있다.
• 의존성을 낮춘다.
• Unit Test를 하면서 해당 메소드가 어떤 역할, 기능을 하는 지 확인할 수 있다.
• 코드 변경으로 인해 문제가 발생할 경우, 단시간 내에 이를 파악하고 바로 잡을 수 있도록 할 수 있다. (프로그램의 각 부분을 고립 시켜서 각각의 부분이 정확하게 동작하는지 확인하는 것이다.)

3. 그렇다면 Test는 어떻게 작성해야할까? (FIRST 원칙을 지켜보자!)

1. Fast
   • 빨라야한다. 테스트를 빠르게 해야한다.
2. Independent / Isolated
   • 독립적이어야 한다. 예를 들어, A 테스트 케이스를 했는데, B 테스트 케이스가 변화가 되면 안된다.
3. Repeatable
   • 반복가능해야한다. 예를 들어, 서버에 문제가 생겼을 경우 MOCK 객체를 만들어 되는 것처럼 만든 후 Test를 진행해 볼 수도 있을 것이다.
4. Self-Validating
   • 스스로 검증하는, 테스트 케이스 내부에서 오로지 테스트가 이뤄져야 한다는 뜻이다.
5. Timely
   • 적시성, 기능을 추가하기 전에 테스트 코드를 작성해야 한다.

🤔 FIRST 원칙을 꼭 모두 지켜야하는 것은 아니다. 예를 들어 Timely의 경우, 개발 시간이 오래걸리는 이유로 지켜지지 않는 경우도 있다.

#.참고URL

• https://ko.wikipedia.org/wiki/%EC%9C%A0%EB%8B%9B_%ED%85%8C%EC%8A%A4%ED%8A%B8
• https://yagom.net/courses/unit-test-%EC%9E%91%EC%84%B1%ED%95%98%EA%B8%B0/

🔥학습 내용

Error Handling

1. Error Handling이란 무엇인가?

• Swift 가이드 문서에 따르면, 이렇게 정의한다. "Respond to and recover from errors." 에러의 복구와 대응이다.
• Error Handling이란 프로그램에서 에러가 발생할 조건으로부터 대응하거나 복구하는 과정이라고 볼 수 있다.

2. Representing and Throwing Errors

• 스위프트에서는 Error 프로토콜을 채택하는 타입을 가지고 있고 있다. 보통 열거형을 사용하는 것 같다.

  enum VendingMachineError: Error {
    case invalidSelection
    case insufficientFunds(coinsNeeded: Int)
    case outOfStock
  }

• throw Error를 하는 것은 정상적인 프로그램 흐름이 기대되지 않을 때, 혹은 실행이 진행되지 않을 때, 가리킨다.

  throw VendingMachineError.insufficientFunds(coinsNeeded: 5)

3. Handling Error

• 에러를 throw할 때, Error를 핸들링 할 수 있도록 해야하는데, 그 방법이 4가지가 있다.

1. Propagating Errors Using Throwing Functions.
2. Handling Errors Using Do-Catch

   do {
    try <#expression#>
    <#statements#>
   } catch <#pattern 1#> {
    <#statements#>
   } catch <#pattern 2#> where <#condition#> {
    <#statements#>
   } catch <#pattern 3#>, <#pattern 4#> where <#condition#> {
    <#statements#>
   } catch {
    <#statements#>
   }

3. Converting Errors to Optional Values
4. Disabling Error Propagation

#.참고URL

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

🔥학습 내용

Strong, Weak 키워드

1. Strong, Weak란 무엇인가?

• 강한참조, 약한참조라고 불리우는 Strong, Weak를 알아본다.
• IBOutlet을 사용하여 다양한 UI 컴포넌트(UILabel 등)를 Interface Builder(Storyboard, XIB)에 연결할 때, 일반적으로 Strong/Weak 인지, Optional 이네?, 왜 강제 언래핑이 되어있지? 에 대한 생각을 하지 않는다.
• 아래는 Apple에서 권장하는 IBOutlet 구조 이다.

@IBOutlet weak var button: UIButton!

2. 왜 Apple은 weak를 권장할까?

1. 일단, Apple은 최상위 객체만 Strong 이고, 그외 객체는 weak로 하라고 말한다. 그래서 viewController가 최상위 객체이며, 그외 객체(IBOutlet)은 weak로 설정되는 것이다.
2. weak를 사용하면 순환 참조를 예방할 수 있다. 순환 참조는 메모리 leak을 일으키고, 앱의 성능을 저하 시킨다. 대신, 개체가 살아있음을 확인하려면 그것을 참조하는 개체가 스트롱타입으로 있어야 한다. 예를 들면, UIviewController를 보면 view라고 하는 프로퍼티는 strong으로 되어있는 것을 확인할 수 있다.

3. 왜 (!) 강제 언래핑을 할까?

• ViewController가 스토리보드에서 로드되면, 시스템은 뷰 계층 구조를 인스턴스화 한다. (이 과정이 loadView()에서 하는 역할이라고 볼 수 있다.)
• ViewController에서 viewDidLoad() 메소드가 호출될 때, ViewController에 모든 Outlet에는 유효한 값을 할당하고 안전하게 액세스를 하기 때문에, 리스크가 있음에도 불구하고, 강제 언래핑을 한 것이다.
• 이미 viewDidLoad()를 호출할 때는 유효한 값이라고 생각하는 것 같고, 유효한 값이 아니라면, loadView()에서 일이 일어났을 것이다.

#. 참조URL

• https://medium.com/macoclock/swift-iboutlet-weak-strong-optional-wrapped-confused-12d371930be2

@IBOutlet이란 무엇인가?

• In the case of @IBOutlet, this is a connection from an Interface Builder user interface component – e.g. a UIButton – to a property in a view controller or other piece of Swift code 인터페이스 빌더와 컴포넌트의 연결이다.?

  1. Interface Builder란 무엇인가?

  • IB는 Interface Builder의 약자라고 한다.
  • XCode 내의 편집기이며, Interface Builder를 사용해서 코드를 작성하지 않고, 응용 프로그램을 위한 인터페이스 구축할 수 있다.
  • What is the Interface Builder? It’s the tool in OS X which allows a programmer to build a Graphical User Interface (GUI) for an application.

  2. Outlet이란 무엇인 가?

  • Component라고 생각하면 될 것 같다. UiLabel, UIButton 등등 다양하게 적용될 수 있다고 생각한다.

  3. 왜 @을 붙이는가?

  • @을 붙이는 것은 Property Wrappers라른 것을 사용한 것이라고 볼 수 있다. 예시를 보면 이해할 수 있다.
  • A property wrapper adds a layer of separation between code that manages how a property is stored and the code that defines a property.

   @propertyWrapper
   struct TwelveOrLess {
     private var number = 0
     var wrappedValue: Int {
        get { return number }
        set { number = min(newValue, 12) }
     }
   }

   struct SmallRectangle {
     @TwelveOrLess var height: Int
     @TwelveOrLess var width: Int
   }

   var rectangle = SmallRectangle()
   print(rectangle.height)
   // Prints "0"

   rectangle.height = 10
   print(rectangle.height)
   // Prints "10"

  rectangle.height = 24
  print(rectangle.height)
  // Prints "12"

4. 그렇다면, Property Wrappers 정의된 프로퍼티 타입이 Optional 일것이다?

@IBOutlet 프로퍼티는 왜 강제 언래핑을 할까?

• UILabel을 연결시킬 때, 코드상에서는 보통 아래와 같이 명시되어있을 것이다.

  @IBOutlet weak var ??: UILabel!

• 위의 내용을 비추어보아, 결론적으로 IBOutlet은 Property Wrappers인 것이고, 정의할 때에 component 타입들을 옵셔널 형태로 지정을 해준 것으로 보인다.

#. 참고URL

• https://developer.apple.com/library/archive/documentation/General/Conceptual/CocoaEncyclopedia/Outlets/Outlets.html
• https://developer.apple.com/documentation/uikit/uilabel
• https://www.hackingwithswift.com/example-code/xcode/what-is-an-iboutlet
• https://reintech.io/blog/how-to-use-swift-iboutlet
• https://medium.com/@JanlCodes/iboutlets-and-ibactions-in-the-cocoa-touch-framework-dfcc9d6c77b2

🔥학습 내용

Super 키워드

1. Super 키워드란 무엇인가?

• ios 프로젝트를 만들면 viewController를 볼 수 있다.
• viewController 내부에는 viewDidLoad 메소드가 있는 것을 볼 수 있다.
• viewDidLoad 메소드 내부에는 아래와 같이 초기 코드가 작성 되어 있는데, 확인해보자.

override func viewDidLoad() {
    super.viewDidLoad()
}

• super 키워드는 현 클래스가 상속받고있는 부모클래스에 구현되어있는 메소드를 구현하겠다는 의미이다.
• super 키워드를 사용하는 시점은 정확히 아는 것은 불가능하나, 관련 공식문서에서 권장하는 방법이 적혀있으며, 별도 언급이 없다면, super 키워드를 활용해서 호출하는 것을 권장한다.

🔥학습 내용

Protocols(프로토콜)

1. 프로토콜이란 무엇인가?

• 서로 다른 방식을 사용한다면, 서로 통신을 할 때 이해가 어려움이 발생한다. 그러므로, 규칙을 정해서 통신하여 이해가 잘 되게 할 수 있을 것이다.
• 프로토콜은 약속, 규칙이라고 할 수 있다.

2. 프로토콜의 기본 구조

protocol 프로토콜명 {

}

3. 프로토콜을 어떻게 사용할까?

protocol DogProtocol {
    var name: String { get }
    var age: Int { get }
    var color: String { get }
    var weight: Double { get }

    func bark()
    func eat(_ something: String)
    func move(to place: String)
    func drink(_ something: String)

4. 프로토콜명을 정의하는 방법

1. -Type, -Protocol 을 붙인다.
2. -able을 붙인다.
3. -ing을 붙인다.

5. 프로토콜이 왜 필요할 까?

• 프로토콜은 규칙을 정한다.
• 규칙을 정하면, 프로퍼티, 메소드의 이름이 일관성을 높일 수 있다.
• 의존성을 낮춰 줄 수 있다. 의존성을 낮추다는 의미는 결국 유지보수 용이성을 높일 수 있다.

#.참고URL

• https://docs.swift.org/swift-book/documentation/the-swift-programming-language/protocols/#app-top
• https://www.swift.org/documentation/api-design-guidelines/#argument-labels

오늘은 velog RSS 등록 방법과 RSS 등록 시 경험했던 Error들을 해결한 과정에 대해서 포스팅 하겠습니다.

1. velog RSS 등록 방법

• https://v2.velog.io/rss/[본인 Velog 이름]을 넣어주면 바로 rss를 찾을 수 있습니다.

2. PCDATA invalid Char value Error 해결방법

• RSS 찾을 때, 정상적으로 XML이 나오길 기다렸지만 세상일은 쉽지 않죠? 어김없이 Error를 뿌려줍니다.
• Error가 나오는 근본적인 원인은 시작태그와 종료태그 사이 위치한 텍스트데이터의 값이 유효하지 않다는 것이었습니다. 위치를 확인해보니 제 Velog 닉네임과 간략한 설명을 하는 위치 쪽이 Error에 걸린 것 같았습니다.
• 어떤 텍스트가 문제인지 정확히 몰라서, 일단 간략한 설명은 지웠구요. 닉네임은 심플한 단어로 변경해서 테스트를 해봤습니다. 결론적으로는 Error 해결!!!

**[Tip] PCDATA invalid Char value Error가 발생했을 때는 관련 Line의 텍스트를 지워가면서 테스트를 해보시기 바랍니다. 🙏 **

3. Input is not proper UTF-8, indicate encoding ! Error 해결방법

• PCDATA를 해결해서 좋았는데, 역시 쉽게 끝나지 않죠..?
• 입력값이 적절한 UTF-8이 아니라고 합니다. 또 다시 velog 웹사이트를 보며 어떤 부분이 문제일까 테스트를 해봅니다.
• 제 경우는 포스팅한 제목이 문제였는데요..? 제목 포스팅을 작성할 때, 다른 벨로그 글의 수정화면으로 들어가서 복사 붙여넣기를 한다음, 이름을 변경하는 식으로 진행을 하기도 했었고, 제목 끝에 주제를 표시하기 위해 _ 를 붙여서 표현하기도 했었습니다. 결론적으로 몇몇의 포스팅 제목의 _부제 를 삭제 하며 테스트를 해봤더니, 정상적으로 XML 데이터를 볼 수 있었습니다.

**[Tip] Input is not proper UTF-8, indicate encoding ! Error가 발생했을 때는 관련 Line의 텍스트를 테스트 해보시기 바랍니다. 🙏 제 경우는 포스트 제목이 원인이었습니다. 😅

#. 참고URL

1. RSS 등록 방법: https://velog.io/@nandong1104/RSS
2. PCDATA invalid Char value Error: https://samslow.github.io/development/2019/01/28/Jekyll-Blog,-PCDATA-invalid-Char-value-Error-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95/

🔥학습 내용

Namespace(네임스페이스)

1. 네임스페이스란 무엇인가?

• 연관된 값들을 한 공간에 이름을 지어 모아둔 공간을 말한다.

2. 네임스페이스를 왜 사용해야할까?

• 유사한 값들을 한 공간에 모아두면 관리가 쉬워진다. 관리가 쉽다는 말은 유지보수가 용이하다는 뜻이다.
• 재사용도 편리하다.
• 네임스페이스를 잘 만들어 놓는다면 하드코딩을 방지하고 코드의 가독성도 좋아진다.

3. 네임스페이스 어떻게 사용할까?

1️⃣ 열거형에 원시값(rawValue)을 사용하는 방법

• 원시값을 사용해서 메시지를 출력할 때, 열거형의 인스턴스를 생성한 뒤, 그 rawValue를 꺼내오는 방식을 사용하게 된다.

  //열거형에 원시값(rawValue) 사용
  enum DannyHobby: String {
    case soccer = "축구"
    case readBook = "독서"
  }
  

print(DannyHobby.soccer.rawValue) // 축구 print(DannyHobby.readBook.rawValue) // 독서

```

• 이해하기가 가장 쉬운 방법이다. 하지만, 네임스페이스의 활용 측면에서 보면 지속적으로 DannyHobby 인스턴스 초기화를 해야하고, rawValue를 이용해야하는 불편함이 있다.

#.참고URL

• https://bicycleforthemind.tistory.com/26

Define requirements that conforming types must implement.

: 적합한 유형이 구현해야 하는 요구사항을 정의합니다.

A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality.

: 프로토콜은 메소드, 프로퍼티, 그리고 다양한 요구조건(함수적인 요소 또는 특별한 task 등)들의 청사진으로 정의된다.

The protocol can then be adopted by a class, structure, or enumeration to provide an actual implementation of those requirements.

: 프로토콜은 요구사항을 실제로 수행을 제공하기 위해 클래스, 구조체, 열거형을 채택할 수 있다.

Any Type that satifies the requirements of a protocol is said to conform to that protocol.

: 프로토콜의 요구사항을 만족하는 모든 타입은 프로토콜에 적합하다고 할 수 있다.

In addition to specifying requirements that conforming types must implement, you can extend a protocol to implement some of these requirements or to implement additional functionality that conforming types can take advantage of.

:

Protocol Syntax

:프로토콜 문법

You define protocols in a very similar way to classes, structures, and enumertaions

: 클래스, 구조체, 열거형 형태와 유사하게 프로토콜을 정의한다.

protocol SomeProtocol {
    // protocol definition goes here
}

Custom types state that they adopt a particular protocol by placing the protocol’s name , separated by a colon, as part of their definition.

: .

Muliple protocols can be listed, and are separated by commas

: 여러개의 프로토콜은 리스트화하여 사용할 수 있으며, 콤마로 분리할 수 있다.

struct SomeStructure: FirstProtocol, AnotherProtocol {
    // structure definition goes here
}

If a class has a superclass, list the superclass name before any protocols it adopts, followed by a comma : 클래스가 부모클래스를 상속받고 있다면, 다른 프로토콜 보다 맨 앞에 명시가 되어야 하며, 콤마로 분리한다.

class SomeClass: SomeSuperclass, FirstProtocol, AnotherProtocol {
    // class definition goes here
}

Property Requirements

: 프로퍼티 요구조건

A protocol can require any conforming type to provide an instance property or type property with a particular name and type.

: 프로토콜은 다양한 적합한 타입이 필요할 수 있다. “인스턴스 프로퍼티” 또는 특정 이름과 타입의 “타입 프로퍼티” 를 제공 받기 위해

The protocol doesn’t specify whether the property should be a stored property or a computed property - it only specifies the required property name and type.

: 프로토콜은 만족하지 않는다. 프로퍼티가 저장 프로퍼티이거나, 연산 프로퍼티어야만 하는 것을

: 프로토콜은 오직 프로퍼티 이름과 프로퍼티 타입만 있으면 만족한다.

The protocol also specifies whether each property must be gettable or gettable and settable.

: 프로토콜은 또한 프로퍼티가 gettable 이거나, gettable과 settable을 이어야 하는 것을 만족한다.

protocol SomeProtocol {
    var mustBeSettable: Int { get set }
    var doesNotNeedToBeSettable: Int { get }
}

Always prefix type property requirements with the static keyword when you define them in a protocol

: 항상 타입 프로퍼터의 접두사는 static 키워드가 요구된다. 프로토콜 내부에서 정의할 때

This rule pertains even though type property requirements can be prefixed with the class or static keyword when implemented by a class

: 이 규칙은 관련이 있다. 클래스 정의할 때 타입 프로퍼티를 정의할 때 “static” 키워드를 붙이는

protocol AnotherProtocol {
    static var someTypeProperty: Int { get set }
}

Here’s an example of a protocol with a single instance property requirement

: 프로콜의 예제가 여기 있다. 단일 인스턴스 프로퍼티 요구사항의

protocol FullyNamed {
    var fullName: String { get }
}

The FullyNamed protocol requires a conforming type to provide a fully qualified name. : FullyNamed 프로토콜은 fullName을 받기 위해 적합한 타입이 필요하다.

The protocol doesn’t specify anything else about the nature or the conforming type - it only specifies that the type must be able to provide a full name for itself. :

The protocol states that any FullyNamed type must have a gettable instance property called fullName, which is of type String.

: 프로토콜은 상태이다. FullyNamed type이 String 타입인 fullName으로 불리는 gettable 인스턴스 프로퍼티를 무조건 갖고 있는

Here’s an example of a simpler structure that adopts and conforms to the FullyNamed protocol

: 이 예제를 봐라. FullNamed 프로토콜을 채택한 간단한 구조체이다.

struct Person: FullyNamed {
    var fullName: String
}
let john = Person(fullName: "John Appleseed")

This example defines a structure called Person, which represents a specific named person.

: 이 예제는 Person 구조체를 정의했다.

It states that it adopts the FullyNamed protocol as part of the first line of its definition.

: 이 구조체는 FullyNamed protocol을 채택한다.

Each instance of Person has a single stored property called fullName, whic is of type String.

: Person의 여러 인스턴스는 스트링타입의 fullName 단일 저장 프로퍼티를 가진다.

This matches the single requirement of the FullyNamed protocol, and means that Person has correctly conformed to the portocol : 이것은 FullyNamed 프로토콜의 단일 요구사항과 일치한다. 이것은 Person 구조체가 프로토콜에 올바르게 따라가고 있다는 것을 의미한다.

(Swift reports an error at compile time if a protocol requirement isn’t fulfilled)

: 스위프트는 컴파일 타임에서 Error를 알려줄 것이다. 프로토콜의 요구사항을 충족하지 않는다면

Here’s a more complex class, which also adopts and comforms to the FullyNamed protocol

: 여기 더 복잡한 클래스가 있다. FullyNamed 프로토콜을 따라가고 채택한

class Starship: FullyNamed {
    var prefix: String?
    var name: String
    init(name: String, prefix: Stirng? = nil) {
        self.name = name
        self.prefix = prefix
    }
    var fullName: Stirng {
        return (prefix != nil ? prefix! + " " : "") + name
    }
}

var ncc1701 = Starship(name: "Enterprise", prefix: "USS")
// ncc1701.fullName

This class implements the fullName property requirement as a computed read-only property for a starship.

: 이 클래스는 이행한다. fullName 프로퍼티의 요구사항을 오직 읽을 수만 있는 연산 프로퍼티로 써

Each Starship class instance stores a mandatory name and an optional prefix.

: 각가의 Starship 클래스 인스턴스는 저장한다. 이름과 옵셔널 prefix를

The fullName property uses the prefix value if it exists, and prepends it to the beginning of name to create a full name for the starship.

: fullName 프로퍼티는 사용한다. prefix 값을 만약, 값이 있다면, 이름과 함께 full name을 만들 수 있다.

#.참고URL

• https://docs.swift.org/swift-book/documentation/the-swift-programming-language/protocols/#Property-Requirements

🔥학습 내용

Notification Center

1. Notification이란 무엇인가?

• 등록된 노티피케이션에 노티피케이션 센터를 통해 정보를 전달하기 위한 구조체이다.
• A container for information broadcast through a notification center to all registered observers.

[구조]

struct Notification

[주요 프로퍼티]

1. name: 알림을 식별하는 태그

   var name: Notification.Name

2. object: 발송자가 옵저버에게 보내려고 하는 객체, 주로 발송자 객체를 전달하는 데 쓰임.

var object: Any?

3. userInfo: 노티피케이션과 관련된 값 또는 객체의 저장소

   var userInfo: [AnyHashable : Any]?

2. 왜 Notification을 사용할까?

• 정보를 Notification Center에 전달해주기 위해 사용한다.

3. Notification Center란 무엇인가?

• 등록된 옵저버에게 동시에 노티피케이션을 전달하는 클래스이다.
• NotificationCenter 클래스는 노티피케이션을 발송하면 노티피케이션 센터에서 메세지를 전달한 옵저버의 처리할 때까지 대기한다. 즉, 흐름이 동기적(synchronous)으로 흘러간다.

[기본 Notification Center 얻기]

• default: 애플리케이션의 기본 노티피케이션 센터이다.

  class var 'default': NotificationCenter { get }

[옵저버 추가 및 제거]

• addObserver(forName:, object:, queue:, using:)
• addObserver(_:, selector:, name:, object:) - 노티피케이션을 노티피케이션 센터의 메서드를 가리키는 장소에 이름을 추가합니다.
• removeObserver(_:, name:, object:) - 노티피케이션 센터의 메서드를 가리키는 장소에서 일치하는 이름을 제거합니다.
• removeObserver(_:) - 노티피케이션 센터의 메서드를 가리키는 장소에서 모든 이름을 제거합니다.

[노티피케이션 발송]

• post(_:) - 지정된 노티피케이션을 노티피케이션 센터에 발송합니다.
• post(name:, object:, userInfo:) - 지정된 이름, 보낸 객체, 보낼 정보로 노티피케이션을 만들어 노티피케이션 센터에 발송합니다.
• post(name:, object:) - 지정된 이름, 보낸 객체로 노티피케이션을 만들어 노티피케이션 센터에 발송합니다.

#. 참고URL

• https://www.boostcourse.org/mo326/lecture/16919
• https://developer.apple.com/documentation/foundation/notification
• https://developer.apple.com/documentation/foundation/notificationcenter

🔥학습 내용

싱글톤 패턴(Singleton Pattern)

1. 싱글톤 패턴(Singleton Pattern)이란 무엇인가?

• 클래스의 인스턴스가 단 1개만 생성되도록 하는 패턴이다.

2. 왜 싱글톤 패턴을 사용할까?

• Singletons are used in situations where this single point of control is desirable, such as with classes that offer some general service or resource 싱글톤 패턴은 단일 제어 포인트인 상황에 사용하는 것이 바람직하다라고 볼 수 있다.

3. 장점

• 편의성이 좋다.
• 어떤 시점에도 클래스의 인스턴스가 단 1개만 존재하도록 보장하는 것이다.
• 1개의 인스턴스만 생성되기 때문에, 메모리 낭비를 방지할 수 있다.

4. 단점

• 전역 접근(global access)가 가능한 부분이 편리하기도 하지만 부작용이 따른다.
• 편의성이 좋지만, 투명성이 안좋아진다. ex) 프로젝트 내에서 사용자 관리를 해야할 때, 사용자 객체가 생성되고 관리되어야 하지만, 싱글톤 패턴을 사용한다면 오직 한명의 사용자만이 로그인할 수 있다.
• 싱글톤에 의존하는 인스턴스는 강한 결합으로 수정과 테스트가 어려워진다.

5. 싱글톤 패턴을 사용할 때, Struct가 아닌 Class를 사용하는 이유는 무엇일까?

• 1개의 인스턴스를 생성해서 인스턴스를 공유하는 취지로 생성된 것인 싱글턴 디자인 패턴이기 때문에, 값을 전달받는 열거형, 구조체로 구현하는 것은 알맞지 않고, 클래스 타입을 활용해야 한다.
• 열거형과 구조체 값 타입이고, 클래스는 참조타입 이다. 따라서 클래스를 사용해 싱글톤을 구현해야 한다. 참조 타입으로써, 같은 메모리를 가리키고 결국 하나의 인스턴스인 셈이 되어야 싱글톤 패턴의 의미를 지킬 수 있다.

#. 참고 URL

• https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/Singleton.html
• https://wody.tistory.com/9
• https://babbab2.tistory.com/66
• https://bibi6666667.tistory.com/511
• https://so-kyte.tistory.com/169

🔥학습 내용

MVC

1. MVC란 무엇인가?

• Model, View, Controller 역할을 갖고 있는 객체로 이뤄진 디자인 패턴이다.

2. 왜 MVC를 사용할까?

• Many objects in these application tend to be more reusable.
• their interfaces tend to be better defined.
• Applications having an MVC design are also more easily extensible than other applications.

#. 참고URL

1. https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html#//apple_ref/doc/uid/TP40008195-CH32-SW3

🔥학습 내용

삼항조건연산자

1. 구조

   • 조건 ? A : B
   • 조건이 참이라면, A를 실행한다.
   • 조건이 거짓라이면, B를 실행한다.
   2. 예시

 //삼항조건연산자
var valueA: Int = 10
var valueB: Int = 5
var biggerValue: Int = valueA > valueB ? valueA : valueB
print(biggerValue) // 10

valueA = 0
valueB = -3
biggerValue = valueA > valueB ? valueA : valueB
print(biggerValue) // 0

var stringA: String = ""
var stringB: String = "String"
var resultValue: Double = stringA.isEmpty ? 1.0 : 0.0
print(resultValue) // 1.0
resultValue = stringB.isEmpty ? 1.0 : 0.0
print(resultValue) // 0.0