## 3주차 토요스터디
### 참여자
- vetto
- harry
- 리지
- 송준
- (새홍)

### 진행일시
2023.01.28

## 👨‍🔬 실험주제 : SOLID

### SRP(Single Responsibilty Principle)
클래스가 하나의 책임을 갖도록 그 책임과 관련된 메서드들만 구현한다.

### OCP(Open/closed principle)
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

### LSP(Liskov substitution principle)
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다

### DIP(Dependency Inversion Principle)
상위레벨 모듈은 하위레벨 모듈에 의존하면 안된다.

### ISP(Interface segregation principle)
프로그램 객체는 사용하지 않는 메소드에 의존하면 안된다.
- 인터페이스를 일반화하여 구현하지 않는 인터페이스를 채택하는 것보다 구체적인 인터페이스를 채택하는 것이 더 좋다는 원칙

// 1. DIP 원칙
protocol Validatable {
    func isValid(data: String) -> Bool
    //func check() ; OCP 원칙을 준수하고자 ISP 원칙을 따름
}
// 2. ISP 원칙
protocol Check {
    func check()
}

struct ValidName: Validatable, Check {
    func isValid(data: String) -> Bool {}
    
    func check() {}
}

struct ValidAge: Validatable {
    func isValid(data: String) -> Bool {}
}

struct ValidPhoneNumber: Validatable {
    func isValid(data: String) -> Bool {}
}

struct ValidAdress: Validatable {
    func isValid(data: String) -> Bool {}
}

class ValidateContact {
    var valid: [String: Validatable] = [
        "이름": ValidName(), 
        "나이": ValidAge(), 
        "연락처": ValidNumber()
    ]
    
    valid["이름"].isValid()
    valid["나이"].isValid()
    valid["연락처"].isValid()
}

class InsertionContact {
    // 연락처 추가
}

class SearchContact {
    // 연락처 검색
}

class LookupContact {
    // 연락처 조회
}

#### 1. SRP 원칙
- 추상화의 범위를 좁혀서 클래스가 하나의 책임을 갖도록 그 책임과 관련된 메서드들만 구현한다.
- 연락처 검증, 추가, 검색, 조회 기능을 담당하는 타입을 구현하여 SRP원칙을 준수한다.

#### 2. OCP 원칙
- `Validatable`을 채택함으로써 이름, 나이, 연락처 검증뿐만아니라 다른 검증 기능이 필요한 경우에도 기능 확장에대해서 유연하게 대처할 수 있다.

#### 3. DIP 원칙
- `Validatable` 프로토콜을 채택하고 있는 타입들이 모두 `Validatable`의 `isValid` 메서드에 의존

#### 4. ISP 원칙
- `Validatable` 프로토콜 안에 `check()`라는 메서드를 만들지 않고, 새로운 프로토콜에 메서드 생성

#### 5. LSP 원칙
- `Validatable` 프로토콜을 채택하고 있는 `struct`에서 추상적인 개념을 구체화 시키고 기능을 모두 수행하고 있는 측면에서 원칙을 준수한다.