[TIL] 20231130

코드 리뷰 답변 작성하면서 정리한 내용

if let vs. guard let

1. 상수(let)의 사용범위가 다릅니다.
옵셔널 바인딩된 상수의 scope가 다릅니다. 즉, 상수를 사용할 수 있는 범위가 다릅니다.
if let 같은 경우, 옵셔널 바인딩된 상수를 if문 밖에서 쓰는 것이 불가하고
guard let의 경우에는 해당 상수를 함수 내에서 지역 상수처럼 자유롭게 사용할 수 있습니다. (단, else문에서는 사용불가)

 

2. else의 생략 가능 여부에 차이가 있습니다.
if let은 해당 조건이 true인 경우를 강조하는 문법입니다.
그렇기 때문에 else구문을 꼭 써주지 않아도 됩니다.
하지만, guard let의 경우 nil인 경우에 무조건 함수를 종료시켜버리기 때문에 else 구문을 꼭 써주어야 합니다.
또한, else구문 안에 return, break 등과 같이 함수를 종료시킬 수 있는 명령어가 꼭 필요합니다.

 

각각을 어떨 때 사용하는 게 좋을까?

if 구문에서 조건이 참이 아닐 시, 해당 함수를 종료 시키거나 루프, 조건문에서 빠르게 탈출시키고 싶은 경우 guard let을 사용하고 조건이 참이 아니더라도 코드를 계속 진행하고자 하는 경우는 if let을 사용하게 되는 것 같음!

 

예전에 정리를 잘 해놨네...

[Swift] if let과 guard let의 차이

접근 제어 (Access Control )

선언, 파일, 모듈에 의해 코드의 가시성을 관리합니다.

 

접근 제어 (Access control) 는 다른 소스 파일과 모듈에서 코드 접근에 대해 제한합니다. 이 기능은 코드의 구현 세부를 숨기고 해당 코드에 접근하고 사용될 수 있는 기본 인터페이스를 지정할 수 있습니다.

특정 접근 수준을 개별 타입 (클래스, 구조체, 그리고 열거형) 뿐만 아니라 해당 타입에 속하는 프로퍼티, 메서드, 초기화 구문과 서브 스크립트에 할당할 수 있습니다. 프로토콜은 전역 상수, 변수, 그리고 함수와 마찬가지로 특정 컨텍스트로 제한될 수 있습니다.

접근 수준 (Access Levels)

Swift는 코드 내에서 엔티티에 대해 5개의 다른 접근 수준(access levels) 을 제공합니다. 이 접근 수준은 엔티티가 정의된 소스파일과 관련되며 소스 파일이 속한 모듈과 관련됩니다.

*엔티티(entity): 접근제어를 적용할 수 있는 코드의 다양한 측면을 칭함(프로퍼티, 타입, 메서드 등)

 

Open, Public

open 접근 과 public 접근은 정의한 모듈의 모든 소스 파일과 정의한 모듈을 가져오고(import) 다른 모듈의 소스 파일에서 엔티티를 사용할 수 있습니다. 일반적으로 프레임워크를 공개 인터페이스로 지정할 때 open 또는 public 접근을 사용합니다. 

 

Open과 Public의 차이점

Open 접근은 클래스와 클래스 멤버에만 적용되고, 모듈 외부의 코드를 서브클래싱하고 재정의할 수 있다는 점에서 public 접근과 다릅니다. Open 접근은 가장 높은 (가장 적은 제약) 접근 수준입니다.

Internal

Internal 접근 은 정의한 모듈의 모든 소스 파일 내에서 사용할 수 있지만 해당 모듈 외부의 소스 파일에서는 사용할 수 없습니다. 일반적으로 앱 또는 프레임워크의 내부 구조체를 정의할 때 internal 접근을 사용합니다. 

 

File-private

File-private 접근 은 자체 정의한 소스 파일로 엔티티의 사용을 제한합니다. 세부 내용은 파일 전체에서 사용되고 기능의 특정 부분의 구현 세부정보를 가리기 위해 file-private 접근을 사용합니다.

 

Private

Private 접근 은 둘러싸인 선언과 같은 파일에 있는 해당 선언의 확장으로 엔티티의 사용을 제한합니다. 세부 내용은 단일 선언 내에서만 사용되고 기능의 특정 부분의 구현 세부정보를 가리기 위해 private 접근을 사용합니다. private 접근은 가장 적은 (가장 높은 제약) 접근 수준입니다.

접근 제어 구문 (Access Control Syntax)

엔티티의 선언의 시작에 open, public, internal, fileprivate, private 수식어 중 하나를 위치시켜 엔티티에 대한 접근 수준을 정의합니다. (별도 지정 없다면 디폴트 접근 수준은 internal)

 

open class SomeOpenClass {}
public class SomePublicClass {}
internal class SomeInternalClass {}
fileprivate class SomeFilePrivateClass {}
private class SomePrivateClass {}

open var someOpenVariable = 0
public var somePublicVariable = 0
internal let someInternalConstant = 0
fileprivate func someFilePrivateFunction() {}
private func somePrivateFunction() {}

 

참고 자료: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/accesscontrol/

의존성 주입 방식

1. Constructor Injection

생성자(initializer)를 이용해 외부로부터 필요한 의존성을 주입받는 방식

 

2. Property Injection

프로퍼티를 통해 의존성을 주입받는 방식

(객체 생성 후 나중에 의존성이 생성되는 상황에서 사용)

 

3. Method Injection

public method를 이용해 의존성을 주입하는 방식

 

4. Interface Injection

인터페이스를 이용해 의존성을 주입하는 방식(Swift에서는 주로 프로토콜 이용)

인터페이스를 사용하게 되면 긴밀하게 연결되어 있는 의존성이 약해져 모듈과 모듈 사이의 결합이 줄어든다는 장점이 있다.

@discardableResult

@discardableResult 어트리뷰트는 함수의 반환값을 무시하고 사용하지 않아도 되는 것을 나타냅니다.

항상 사용할 필요가 없는 값을 반환하는 함수를 관리하는 데 유용한 도구입니다.

return 값을 항상 사용하지 않는 함수에 @discardableResult를 붙여주게 되면 코드를 더 깔끔하고 표현력있게 만들 수 있으며, 컴파일러 경고 메시지 또한 제거할 수 있습니다.

---

디자인 패턴 vs. 아키텍처 패턴

소프트웨어 디자인 패턴

디자인 패턴이란, 소프트웨어 디자인에서 공통적으로 많이 발생하는 문제에 대해 재사용 가능한 해결책.

 

상황에 맞게 사용될 수 있는 문제들을 해결하는 데 쓰이는 템플릿을 의미한다.

즉, 디자인 패턴은 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴!

문제상황에 대한 재사용 가능한 해결방법으로서, 일종의 아이디어라고 할 수 있음

 

소프트웨어 아키텍처 패턴

아키텍처 패턴이란, 주어진 상황에서의 소프트웨어 아키텍쳐의 공통적인 발생 문제에 대한 일반적인, 재사용 가능한 해결책을 의미한다.

간단히 말하면, 아키텍처 패턴은 소프트웨어의 전체적인 그림, 구조를 만드는 해결책

 

둘의 차이점?

둘 다 공통적으로 발생하는 문제에 대해 일반화된 솔루션을 제공하는 점은 같으나, 아키텍쳐는 더 큰 뼈대를 말하고 디자인 패턴은 코드 수준에서의 설계를 담당하는 것

즉, 아키텍쳐가 더 큰 범주, 디자인 패턴이 더 작은 범주의 설계를 담당! (but 디자인 패턴을 아키텍쳐 패턴에 포함되는 하위개념이라고 보긴 어려울 것 같음)

 

왜 필요할까?🤔

문제상황이 발생할 때마다 매번 다시 해결책을 찾는다면 시간과 비용이 많이 들어갈 것,,

특정 문제 상황에 대한 패턴을 발견하고 해결방안을 기록해둔다면 다시 그 문제가 발생했을 때 빠르게 적용할 수 있음!

즉, 반복되는 문제 상황에 대한 해결을 빠르고 용이하게 하기 위해 디자인 패턴, 아키텍처 패턴이 필요하다!!!!

또한, 템플릿화된 해결책을 사용하는 것이므로 협업 시 의사소통 또한 효율적으로 할 수 있다.

 

 

+ Tuist를 이용한 모듈화 해보는 중.. 뚝딱뚝딱... 추후에 추가하겠습니다...