Geon

Dependency Inversion Principle (의존성 역전) 상위 수준의 모듈은 하위수준의 모듈에 의존해서는 안된다. 구체적인 사항은 추상화에 의존해야 한다. 왜 하위수준의 모듈에 의존하면 안될까?? 하위수준의 모듈 즉 구체타입은 변화가 많지만 상위모듈인 추상타입은 잘 안변한다. 그래서 DIP를 적용하여 수정시 다른 코드에 영향을 최소화 시킬수 있다. protocol Networkable { mutating func runDataTask(request: URLRequest, completionHandler: @escaping (Result) -> Void) } final class NetworkManager { private var networkable: Networkable init(netw..

Interface Segregation Priciple ( 인터페이스 분리 법칙) 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 말아야 한다. 왜 사용하지 않는 메서드에 의존하지 말아야 할까? 불필요한 빌드가 유발될수 있다. protocol 세탁할수있는 { func 세탁하기() func 건조하기() } struct LG세탁기: 세탁할수있는 { func 세탁하기() { print("세탁하기") } func 건조하기() { print("건조하기") } } struct 삼성세탁기: 세탁할수있는 { func 세탁하기() { print("세탁하기") } func 건조하기() { } } 삼성세탁기는 건조하기 기능이 없을수도 있다. 이럴떄는 기능이 없지만 protocol을 채택하고 있기때문에 건조하기 메서드..

Open / Closed Principle (개방 - 폐쇄 원칙) 확장에는 열려있고 변경에는 닫혀있다. 왜 확장에는 열려있고 변경에는 닫혀있을까? 새로 추가되는 코드가 기존 코드에 영향을 끼치지 않게 하여 새로운 기능을 쉽게 추가할수 있게 한다. 새로 추가되는 코드나 변경되는 코드가 기존 코드의 변경을 초래하지 않아야 작업하기 수월하다. 타입 확장 메서드 또는 행동 추가 위 예시처럼 어떤 부분을 추상화 시키고 어떤부분을 구체화 시킬것인지를 고려해야 한다.

Single Responsibility Principle(단일책임 원칙) 하나의 클래스는 하나의 책임만을 가져야 한다. 왜 하나의 책임만을 가져야 할까?? 재사용의 어려움 이해하기 어려워, 유지보수가 힘들어진다. 특정 기능을 변경했는데 객체 일부만 수정되었거나, 원하지 않는 객체들도 수정이 될수도 있다. Bad Case struct Cacao { func 서비스개발() -> APP { let 설계도 = 설계하기() let api = 백엔드개발(설계도: 설계도) return 프론트개발(API: api) } func 설계하기() -> UML { return UML } func 백엔드개발(설계도: UML) { return API } func 프론트개발(API: API) -> APP { return APP } ..

SOLID 원칙을 왜지킬까?? 코드의 품질을 높이기 위해서 코드의 품질이 무엇인데요?? 가독성 단순성 유연성 Single Responsibility Principle(단일책임원칙) 한클래스는 한가지의 책임만을 가져야한다. 하지만 MVC패턴에서의 ViewController는 이러한 원칙을 어기고 있다. Open-Close Principle 확장에는 열려있고 변경에는 닫혀있어야 한다. Swift에서는 enum은 case가 추가되면 switch문에 모두 추가해줘야하기에 메서드에 대한 행동을 추가할떄 용이 Protocol은 추상화된 인터페이스가 변경될떄는 해당 프로토콜을 준수해야하기에 모두 오류 Liskov Substitution Principle 자식클래스는 부모 클래스로써의 역할을 모두 수행해야 한다. De..