# 멀티바인딩 `@IntoSet` `@IntoMap` `@Multibinds`

멀티바인딩은 여러 바인딩을 하나의 컬렉션으로 관리하는 구조다. Set, Map 컬렉션을 지원하며  중복바인딩이랑은 결이 좀 다르다고 볼 수 있을 것 같다. 

Set을 이용한 방식은 기존 @Provides하던 바인딩에 `@IntoSet`을 달아주면 된다. 그렇게 하면 컴파일 타임에서 Set안에 @IntoSet이 선언된 바인딩을 묶어서 갖고 있게 된다. 근데 컬렉션으로 바인딩을 관리하면 문제가 하나 생긴다.

단독 바인딩일 때는 EntryPoint에서 @Inject할 때 알아서 가져갔는데, 반환타입이 Set<T>으로 감싸져있어서 그냥 @Inject하면 MissingBinding을 오류로 내뿜게 된다.

단독 바인딩이 Set<T>으로 되어있다면 @IntoSet말고 `@ElementsIntoSet`을 달아줘야된다. 그러면 단독 바인딩 된 Set의 원소들이 Set 멀티 바인딩 돼서 들어온다.

@Module
@InstallIn(SingletonComponent::class)
class MultiBindModule {
    @Provides
    @IntoSet
    fun provideString(): String{
        return "test"
    }
}

// 사용은 아래처럼 Set으로
@Inject
lateinit var str: Set<String>

Set을 반환하는 바인딩을 쓴 건 아래와 같다.

@Module
@InstallIn(SingletonComponent::class)
class MultiBindModule {
    @Provides
    @IntoSet
    fun provideString(): String {
        return "test"
    }

    @Provides
    @ElementsIntoSet
    fun provideStrings(): Set<String> {
        return setOf("a", "b", "c")
    }
}

그럼 위에서 str은 Set을 받아오는데, 결과가 어떻게 나올까?

다 담겨서 들어온다. Set 말고 Map으로도 멀티바인딩이 가능하다.

Map은 기본적으로 Key - Value 형식이라 키를 지정해줘야하는데, String, Int, Long, Class로 키를 지정해줄 수 있다. 사용방법은 Set과 비슷한데, @IntoMap과 @"타입"Key("키 값")을 지정해주면 된다.

@Provides
@IntoMap @IntKey(1)
fun provideName(): String{
    return "one"
}

@Provides
@IntoMap @ClassKey(Test::class)
fun provideNameOfClass(): String{
    return "Test Value"
}

Test클래스를 키로 쓴건데 키 타입이 `Class<*>`가 된다. Map을 사용한 멀티바인딩은 키값이 가장 중요해서 조심해야된다.

@Inject
lateinit var mapInt: Map<Int, String>

@Inject
lateinit var mapClass: Map<Class<*>, String>

mapClass 값은 `mapClass[Test::class.java]`로 꺼내쓴다.

지정된 타입 말고도 키를 설정할 수 있다. `@MapKey`를 사용한 방식인데 키가 될 enum class 같은 걸 annotation class로 커스텀 키 어노테이션 선언해주고, @MapKey를 붙여서 쓰면된다.

@MapKey
annotation class CustomMapKey(val value: Keys)

enum class Keys {
    ONE,
    TWO,
    THREE
}

// 모듈에서는 아래 처럼
@Provides
@IntoMap
@CustomMapKey(Keys.ONE)
fun provideCK(): String{
    return "CK"
}

Inject 부분에서는 Enum 클래스를 Key에 넣어주면 된다.

`@Multibinds`는 바인딩 된지 안된지 모르는 상태이거나 빈컬렉션이 필요할 때 사용하면 된다.

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!

# Binding?

flowchart LR
    Android -->|Compile, Request| Hilt
    Hilt -->|Runtime, Inject| Android
    AppModule ---> Hilt
    NetworkModule ---> Hilt

의존성을 추가하는 행위나 개별적인 인스턴스 dependency(Inject로 되어있는) 모두 바인딩이라고 한다. 그냥 의존성을 바로 꽂을 수도 있고, 의존성을 관리할 모듈을 둬서 모듈을 HiltComponent에 꽂아 사용하기도 한다.

# Dependency Injection - 생성자 주입, 필드 주입, 메서드 주입

// 생성자 주입
class Test @Inject constructor(foo: Foo){ // foo 주입과 동시에 Test 바인딩
 
}
// 필드 주입
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    @Inject // 얘는 요청해서 주입 받는 것
    lateinit var test: Test
    ...
}
// 메서드 주입
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    
    @Inject
    fun foo(bar: Bar){
	...
}

생성자 주입과 필드주입은 이전 게시글에서 확인했다. 메서드 주입만 보면 되는데, foo 메서드는 bar라는 파라미터의 의존성을 주입받게 된다.

생성자 주입은 따로 스코프 없이 Inject해버리는데 이 경우 Test 클래스 자체도 컴파일 타임에 Hilt 컴포넌트에 바인딩된다는 특이점이 있다.  메서드 주입은 Inject가 `super.onCreate` 이후에 작동하기 때문에 이 메서드에서 lateinit var를 초기화할 수 도 있다.

lateinit var fooFun: Foo

@Inject // method 주입
fun provideFoo(foo: Foo){ // super.onCreate 이후에 Inject되어 fooFun은 초기화 된 상태로 접근가능하다.
    fooFun = foo
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    assert(this::fooFun.isInitialized) // true이기 때문에 crash 발생하지 않음
	...
}

근데 모듈을 사용하기 때문에 메서드 주입은 아무래도 사용하는 빈도가 적을 것 같다.

# `@Qualifier` , `@Named("식별명")`

Hilt는 타입을 기준으로 의존성을 구분하는데 그래서 중복 바인딩이 발생하면 오류가 발생한다. 동일한 타입의 두 의존성을 구분하지 못하기 때문이다. -> `Dagger/DuplicateBindings` 로 에러가 나온다. 근데 타입은 동일하지만 역할이 다른 경우 두 가지 모두 살려야할 때가 있다. 예를 들면 Access Token으로 접근해야 되는 의존성과 그게 없어도 접근 가능한 의존성 이렇게 두개로 나눌 때가 그 예시다.  이 경우 Qualifier로 구분할 수 있다.

사용 방법은 은근히 간단하다.

@Qualifier
annotation class TestQualifier

@Module
@InstallIn(SingletonComponent::class)
object TestModule {

    @Provides
    fun provideTest(): Test {
        return Test(id = "Test")
    }

    @TestQualifier
    @Provides
    fun provideTest2(): Test {
        return Test(id = "TestQualifier")
    }
}

Qualifer 어노테이션을 달고있는 커스텀 Qualifier annotation을 만들고, 그걸 중복바인딩이 필요한 곳에 달아주면 된다.

@Inject
lateinit var test1: Test

@TestQualifier
@Inject
lateinit var test2: Test

// 메서드 주입의 경우
@Inject
fun injectTest(@TestQualifier test: Test){
    testQualifier = test
}

물론 주입받을 곳에도 달아줘야된다.

껍데기만 만들어두고 사용할 수도 있지만 속성을 정의하는 방식으로 사용하는 것도 가능하다.

@Qualifier
annotation class TestQualifier(val id: String)

이렇게 정의하면 Inject나 바인딩 할 때 속성값인 key를 명시해줘야한다.

이런 식별과정을 좀 더 쉽게하는 방법이 `@Named`인데 식별명 문자열을 id로 갖는 Qualifier라고 보면 될 것 같다.

@Module
@InstallIn(SingletonComponent::class)
object TestModule {

//    @TestQualifier
    @Named("Test")
    @Provides
    fun provideTest2(): Test {
        return Test(id = "TestQualifier")
    }
}

한 데 모아 관리하길 좋아하는 사람들은 아마 Named 보다 Qualifier를 선호하지 않을까 생각한다.

# Lazy와 Provider

Hilt의 Lazy 주입은 by lazy과 특정시점에 인스턴스를 생성한다는 점에서 약간 비슷하다. 인스턴스 생성시점을 조절한다는 의미는 생성비용이 커서 이걸 조절하겠다는 의미도 될 수 있다.

@Inject
lateinit var foo: Lazy<Foo> // Lazy

...
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    assert(foo.get().bar != null)

get으로 Lazy 주입을 받아올 수 있는데, 주의할 점은 Lazy가 dagger 라이브러리의 타입이라는 것이다. 코틀린도 Lazy를 갖고있기 때문에 import를 잘못하면 get으로 못가져온다.

Lazy로 선언한 인스턴스는 한번 주입되면 같은 인스턴스를 반환한다.

@Inject
lateinit var fooProvider: Provider<Foo>

Provider도 비슷하다. get으로 가져오고, 호출할 때 인스턴스를 생성한다. Lazy와 다른 점은 Lazy는 한번 생성되면 그걸 가져오는 거고, Provider는 매 호출마다 새 인스턴스를 가져온다. 그래서 각 호출에 대해 동일한 인스턴스를 반환하고 싶다면 Scope를 지정해서(`@Singleton`을 붙인다던가) 사용하는 방법을 선택해야된다.

# 바인딩 기법 - `@Binds`

바인딩은 DI 그 자체(컴포넌트에 의존성을 추가하는 행위) 또는 그 의존성 자체를 의미한다.

모듈 안에서 컴포넌트에 달아놓는 `@Provides`는 이제 익숙해졌다. 기존에 Provide 된 바인딩이 있으면 `@Binds`로 효율적으로 달아 둘 수 있게 된다. Binds가 중요한 이유는 언어 특성상 인터페이스 타입으로 선언된 변수에 하위 타입으로 바인딩을 걸 수 있기 때문이다.

즉 `@Binds`는 이미 바인딩 된 의존성을 확장관계에 있는 새 타입으로 감싸서(선택적으로 모듈 설치가 가능하다) 바인딩 시킬 때 효율적으로 동작한다. 따라서 제약 조건이 존재하는데,

1. `@Binds`는 모듈 내 abstract 메서드에 추가돼야한다.
2. 파라미터를 한 개만 가질 수 있다.
3. 파라미터 타입이 반환 타입의 서브타입이어야 한다.
4. `@Scope` 및 `@Qualifier` 랑 같이 쓸 수 있다. 

1, 2, 3 모두 확장이 용이한 언어특성을 그대로 반영한 조건들임을 알 수 있다.

abstract 메서드는 구현체가 필요한 경우라 이것만으로는 인스턴스를 생성할 수 없는데, provides는 그게 아니기 때문에 주의해야된다.(파일 자체를 분리 시켜버리는 게 좋다.) 네이밍규칙은 `bind서브타입`으로 시작한다.

@Module
@InstallIn(SingletonComponent::class)
// Binds를 위한 추상 모듈을 만들어 준다
abstract class EngineModule {
    @Binds
    abstract fun bindGasolineEngine(engine: GasolineEngine): Engine

    @Binds
    abstract fun bindDieselEngine(engine: DieselEngine): Engine
}

Engine은 인터페이스고, GasolineEngine, DieselEngine은 생성자 바인딩으로 컴포넌트에 달려있는 상태다. 이대로만 놔두면 Engine을 반환하는 게 중복돼서 중복바인딩을 허용하지않는 Hilt 특성상 에러가 발생한다. Named나 Qualifier로 해결하면 되는 부분이기 때문에 이건 필요에 따라 다르게 사용하면 될 것 같다.

# 옵셔널 바인딩  `@BindsOptionalOf`

바인딩 되어 있을 수도 있는 의존성을 요청하는 어노테이션이다. 옵셔널이기 때문에 바인딩 되지않아도 일단 컴파일 에러는 발생하지 않는다. 바인딩이 안된 경우도 있을 수 있기 때문에 기본적으로 파라미터를 가지면 안된다. 또 받아올 의존성도 Optional해야되기 때문에 생성자 바인딩 된 의존성들은 이때 사용할 수 없다.

@Provides
fun provideFoo(): Foo{
    return Foo()
}

그래서 BindsOptionalOf는 따로 provide된 의존성을 달아줘야된다.

@BindsOptionalOf
abstract fun bindDieselEngine(): Engine

이렇게 하는 방법 말고 의존성 그래프 상의 관계에서 모두 `Optional<T>`로 선언해주는 방법도 있다.

@Inject
lateinit var foo: Optional<Foo>

BindsOptionalOf로 바인딩 된 의존성을 요청할 때는 Optional로 감싸서 해주고,  get()으로 가져온다.

바인딩 되지않았다면 예외가 발생하기 때문에 isPresent로 체크해줘야된다. 

`@BindsInstance`는 컴포넌트 생성과 동시에 바인딩 되는 걸 말한다. 근데 이건 따로 외부 컴포넌트를 만들어서 사용할 때 주로 사용한다...

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!

제가 보려고 만들었습니다. 계속 내용이 추가될 예정입니다

# SOLID 원칙

• `Single Responsibility Principle` 단일책임원칙
  • 한 클래스에 한 책임을 부여해야한다.
• `Open Closed Principle`
  • 상위 클래스, 인터페이스를 중간에 하나 둬서 내 확장에는 열려있고 변화에 대해서는 닫혀 있어야한다. Repo - RepoImpl과 같은 관계
• `Liskov Substitution Principle` - 상속의 특성을 잘 활용하기
  • 하위클래스의 인스턴스는 상위 객체에 넣어서 상위 클래스 인스턴스 역할을 하는데 문제가 없어야된다.
  • 하위클래스 is a 상위클래스
• `Interface Segregation Principle`(인터페이스 최소주의 원칙)
  • 내가 사용하지않는 메서드와 의존성이 있으면 안된다.
• `Dependency Inversion Principle` - 의존성 역전 원칙
  • 변하기 쉬운것의 변화에 영향을 받지않아야한다.  구현체에 의존하지 말라는 얘기다.
  • 추상화된 인터페이스나 상위클래스를 하나 끼워서 변화에 둔감하도록 만드는 게 DIP이다.

::출처::

https://github.com/VSFe/Tech-Interview?tab=readme-ov-file

https://github.com/WooVictory/Ready-For-Tech-Interview

https://github.com/gyoogle/tech-interview-for-developer

https://github.com/JaeYeopHan/Interview_Question_for_Beginner

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^

제가 보려고 만들었습니다. 계속 내용이 추가될 예정입니다

# 정규화, 반정규화

RDB에서 anomaly 문제를 처리하기 위해 적절한 relation으로 분리하는 것을 의미한다.

`anomaly` -> 정규화를 거치지 않아서 서로 다른 엔티티가 중복된 컬럼 값을 갖게되는 문제가 발생한다.

삽입, 삭제, 갱신 시 발생하는 문제로 NULL값이 들어가서 문제가 생기거나, 갱신문제로 모순이 생기거나, 의도와 상관없는 데이터까지 삭제되는 경우가 있다.

• 1 정규화(First Normal Form - 1NF)
  • 모든 도메인은 원자값으로만 갖고있다(단일값만 가능하고 여러값을 갖는 컬럼이 없어야된다)
  • 컬럼에 반복되는 그룹이 나오지 않아야한다.
  • 기본키를 사용해서 각 튜플을 고유하게 식별할 수 있어야한다.
• 2 정규화
  • 1NF를 만족하는 상황에서 부분적 함수 종속을 제거하는 경우다.
  • 함수적 종속은 완전함수 종속, 부분함수 종속으로 나눌 수 있다. 기본키(PK)를 기준으로 한다. 기본키는 NULL이면 안되고 중복된 값을 가지면 안된다.
    • 완전함수 종속 - `X -> Y`로 X값에 따라 Y값이 결정되는 경우. 복합키여도 가능하다.
    • 부분함수 종속 - 단일키는 불가능하고, 복합키 중 하나만으로도 Y값을 결정할 수 있는 경우
    • 이행적 함수종속 - `X -> Y -> Z`로 Z까지 알수 있는 경우 
• 3 정규화
  • 기본 키가 아닌 모든 속성이 키본키에 대해 이행적 함수 종속 관계를 끊어버리는 것
  • 속성(컬럼)이 `X -> Y -> Z`로 결정되는 걸 끊어서 다른 테이블로 만들어버린다.
• BCNF(Boyce-Codd)
  • 모든 결정자(`X->Y`에서의 X)는 후보키어야한다.
  • 후보키, 기본키, 외래키 같은 용어는 https://jerryjerryjerry.tistory.com/49여기서 확인하면 된다.
• 그 이상의 4NF, 5NF는 고급 정규형인데 너무 잘게 쪼개서 발생할 수 있는 부작용이 존재한다

정규화 단점이라면 relation이 분리되며 JOIN연산의 필요성이 더 많아져서 쿼리 응답 시간이 느려질 수 있다는 게 있다.

반정규화는 조인을 줄이는 건데 그러면 정규화를 반대로 하는 거라고 자연스럽게 받아들일 수 있다. 정규화를 하면 정합성(데이터가 올바른지랑 상관없이 데이터들의 값이 일치하는 상태)과 무결성이 보장된다. 반정규화의 목적은 의도적으로 중복을 만들어서 읽기 성능을 올리는 것이다. 그러면 반대로 이상현상도 발생할 수 있는 `C,U,D`에 사용되는 작업은 성능이 떨어진다. DB는 보조메모리(디스크)에 저장되는데, 읽기성능을 올리려고 접근횟수를 줄이는 방식이 반정규화이다.

# RDBMS와 NoSQL(Not Only SQL)의 차이

Relation으로 이뤄진 스키마로 구성된 RDBMS는 scale-out(수평 스케일 확장) 시 번거롭다.

데이터가 join을 통해 형성될 것이고 그러면 수직적으로 데이터베이스가 만들어져있어서 샤딩할때 각각 다른 데이터 베이스에 붙어버릴 수 있는 가능성이 있다. NoSQL은 독립형 객체로 저장하고 있어서 애초에 단일서버에 그대로 상주하고 있다. 다른 테이블의 데이터와 조인 없이 확장이 가능하다.

그래서 NoSQL이 빅데이터 처리에 효과적이다. 분산 처리와 병렬처리가 분산형 구조로 인해 자연스럽게 가능하고 Relation이 없기 때문에 수평확장이 쉽다. 

그대신 relation이 없어서 일관성이 항상 보장되지는 않아 주의해야되고 조인을 구현하려면 각 테이블을 일단 가져와서 데이터를 합쳐야한다.

1. 샤딩(Sharding) : 하나의 데이터 세트를 다수의 DB에 분산시키는 방법. 주로 데이터 세트가 단일 DB에 저장하기에는 너무 클 때 사용한다
2. 파티셔닝 : 논리적인 데이터 element 들을 다수의 entity로 쪼개는 행위를 뜻하는 일반적인 용어 즉 큰 table이나 index를, 관리하기 쉬운 partition이라는 작은 단위로 물리적으로 나누는 것을 의미한다

# 트랜잭션

트랜잭션은 논리적인 작업단위로 Commit하거나 Rollback해서 실행여부를 결정한다. 롤백할 수 있다는 게 장점이다. 부정합이 발생하면 롤백시켜 예방할 수 있다.

ACID라는 성질이 있다.

• `Atomicity`(원자성) - Commit or Rollback
  • 트랜잭션의 연산은 데이터베이스에 모두 반영되든지 아니면 전혀 반영되지 않아야 한다.
  • 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수 행되지 않고 어느하나라도 오류가 발생하면 데이터베이스 상태를 트랜잭션 작업 이전으로 되돌려서 원자성을 보장한다.
• `Consistency`(일관성)
  • 트랜잭션 수행 전과, 수행 완료 후의 상태가 같아야 한다.
• `Isolation`(독립성, 격리성)
  • 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행중에 다른 트랜잭션의 연산이 끼어들 수 없다.
  • 수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.
  • 격리성은 읽기 일관성과 동시성에 영향을 미치는 성질
• `Durability`(영속성, 지속성)
  • 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다.

트랜잭션 격리 Level이라는 게 존재한다. 이것에 따라 읽기 일관성이 달라지기때문에 중요한 개념이다.

위에서 부터 레벨 0~3이고 레벨 2인 Repeatable Read가 MySQL InnoDB의 기본 isolation level이다.

레벨을 너무 낮게 잡으면 읽기 일관성을 제대로 보장할 수 없고, 너무 높게 잡으면 동시성 탓에 데이터 처리 속도가 느려져서 적당한 트레이드 오프가 필요하다.

• 레벨 0인 Read Uncommitted 는 커밋되지 않은 내용에 대해서 데이터를 읽을 수 있다.
• 레벨 1인 Read Committed 는 커밋된 내용에 대해서만 데이터를 읽을 수 있다.
• 레벨 2인 Repeatable Read 는 선행 트랜잭션이 읽은 데이터는 트랜잭션이 종료될 때가지 후행 트랜잭션이 갱신하거나 삭제하는 것은 불허함으로써 같은 데이터를 두 번 쿼리했을 때 일관성 있는 결과를 리턴한다.
• 레벨 3인 Serializable Read 는 선행 트랜잭션이 읽은 데이터를 후행 트랜잭션이 갱신하거나 삭제하지 못할 뿐만 아니라 중간에 새로운 레코드를 삽입하는 것도 막아주기 때문에 완벽하게 읽기 일관성 모드를 제공한다. 단, 동시성에 대한 성능은 매우 떨어진다.

# 동시성 제어 - 직렬성을 지키기 위해 필요한 필수 작업

Locking, Timestamp, Validation으로 처리한다.

• `Locking`
  • 트랜잭션이 데이터에 lock을 걸면 다른 트랜잭션은 unlock 전까지 이 데이터에 접근할 수 없다.
  • 접근이 불가능하다는 말은 교착상태랑 기아상태가 발생할 수 있는 위험이 있다는 말이 된다.
• `Timestamp`
  • 먼저 들어온 트랙잭션이 항상 더 빨리 수행된다. 늦은 것 부터 처리하는 스케줄링 방식과 비슷하다.
• `Validation`
  • 메모리상의 복사본에서 연산을 수행하고 검증완료시 DB에 반영한다. 읽기-검증-쓰기 3단계로 이뤄져있다.
  • 읽기는 복사본을 따로 만들지 않는다.
  • 검증단계에서는 해당 트랜잭션을 수행하는 동안 직렬화가 지켜졌는지 검증한다.
  • 유효하다면 업데이트 된 부분들을 DB에 적용한다.

DB 인덱싱 공부는 나중에 정리해서 올리겠다. 아래는 공부하고 있는 참고링크

https://github.com/NKLCWDT/cs/blob/main/Database/Index%2C%20Hint.md

::출처::

https://github.com/VSFe/Tech-Interview?tab=readme-ov-file

https://github.com/WooVictory/Ready-For-Tech-Interview

https://github.com/gyoogle/tech-interview-for-developer

https://github.com/JaeYeopHan/Interview_Question_for_Beginner

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^