밤에 쓴 코드

Factory - 팩토리 구체적이면 구체적일 수록 변화에 취약하다. 인스턴스를 생성하는 코드는 되게 구체적인 부분이라 유연하지 않다. 그 부분을 분리하기 하여 관리하려는 노력에서 나온 패턴이다. 변화에 취약한 부분을 분리하자 구체적이면 구체적인 부분일수록 변화에 취약하다. 특정 구상 클래스의 인스턴스를 생성하는 부분은 굉장히 구체적인 부분이므로 , 분리해서 관리하는 것이 좋다. 구체적인 클래스에 직접적으로 접근하는 것은 팩토리 만으로 한정 짓는다. 생성할 객체를 추상화하자 팩토리메소드는 구상클래스의 인스턴스를 반환한다 . 하지만 생성된 인스턴스를 받을 구체적인 타입을 알지 못한다. 좀더 세분화하여 구체적인 객체를 생성해야 한다면 생성 자체를 추상화하자 객체를 생성함에 있어서 단계를 나눌 수 있다. *게임..

타입, 추상화 추상화 공통적인 특징들만 모으고 차이점을 배제하는 일반화 , 일반화 되어있는 정보에서 집중하지 않아도 되는 불필요한 정보를 제거해 나감으로서써 단순화를 하여 , 복잡도를 낮추고 좀 더 본래 목적에 집중할수 있게 해주는 작업 예) 지하철 노선도 초기 지하철 노선도는 지도와 일치하는 구체적은 지형까지 담고 있었다. 사실적이지만 목적에서 벗어나는 정보들까지 한번에 너무많은 정보가 들어오다 보니 , 오히려 본래 의도를 전달하기 더욱 어려워 졌다. 지하철 노선도에서 중요한 것은 방향에 따른 역들의 순서를 전달하는 목적에 알맞지 않은 부가적인 정보가 너무 많았다. 훗날 집중해야하는 부분과 집중하지 않아도 되는 부분을 분리해서 제거하여 , 더 본래의 의도에 더욱 맞게 사용할 수 있게 되었다. 객체를 그..

스트래티지 패턴 스트래티지 패턴에서는 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. 스트래티지패턴을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다. 문제점 상속 일부 적합하지 않은 서브클래스가 존재할 수 있다. 인터페이스 인터페이스를 채택한 클래스에서 구현이 이루어진다. 코드의 중복이 야기된다. 디자인 원칙 달라지는 부분과 달라지지 않는 부분을 분리 - 달라지는 부분 캡슐화 인터페이스(상위형식)에 맞추어 프로그래밍 상속보다는 구성(Composition) 개발기간보다 개발이 끝난 후에 코드에 더 많은 시간을 쓴다. 재사용성도 중요하지만 확장성,관리의 용이성이 더 중요하다. 동작이 유연하게 관리되어야 하는 설계에서는 스트래티지 패턴은 좋은 선택이..

디자인패턴 기존 환경내에서 반복적으로 일어나는 문제들을 설명한 후 그 문제들에 대한 해법의 핵심을 설명 , 재사용 할수 있게 하는 패턴 기대효과 공통적인 설계자들의 어휘의 수준을 높여준다. 논의에 있어서 대화의 많은 영역을 추상화하여 더 간결하게 표현할 수 있어서 , 더욱 지적 대화가 가능하다. 적은 단어로 많은 내용을 내포하여 의도를 제대로 전달 할 수 있다. 디자인패턴을 인용한 대화 - 객체의 이동하는 동작에 대해서는 스트래티지패턴이 적절하겠네요. 객체의 이동을 표현하기 위해서는 이동하는 동작을 정의한 인터페이스를 정의하고 , 해당 인터페이스를 구체화한 클래스를 추상화되어있는 인터페이스에 합성시키고 인터페이스에 정의된 메소드외에는 은닉하고, 동적으로 수정할 수 있게 프로그래밍하면 적절하겠네요. 시스템..

OOP ) 상태 , 행동 , 식별자 객체지향 패러다임 지식을 추상화 하고 , 추상화한 지식을 객체내에 캡슐화 하여 복잡성을 관리하고 , 객체의 지식과 행동을 구조화 객체 하나의 단위로 인식가능한 사물이다. 행동 , 상태 , 식별자를 가지는 사물 현실의 문제를 해결하기위해서 소프트웨어 세계를 창조합니다. 하나의 문제를 해결하기위해선 여러개의 작은 동작들로 나눌 수 있습니다. 각각의 동작들은 책임을 가지는 객체가 해결하고 , 협력을 통해 문제를 해결합니다. 행동과 상태 행동을 수행하는 객체들이 행동의 결과를 결정하는데에는 과거의 행동의 이력이 연관을 가진다. 과거의 행동의 이력을 표현할 수 있는 효과적인 방법은 상태 로 표현하는 것이다. 과거의 행동이 상태를 변경하므로 상태는 행동의 결과에 의존한다 또 행동..

Swift) POP - Protocol Oriented Programming 상속의 한계 상속의 계층 구조가 깊어질수록 복잡도가 올라간다. 값 타입 (ex - struct)는 상속이 불가능 프로퍼티 추가 불가능 추상화된 클래스를 구체화했을 때 공통적인 책임을 가지는 여러 클래스가 존재할 수 있고, 중복된 코드를 야기한다. *중복된 상황 - 억지로 만들어낸 예시 * class Bird{ // 모든 새가 날수있는건 아니어서 동작 추가 불가능 } class Owl : Bird { func fly(){ print("훨~ 훨~") } // 비행한다 - 중복 } } class Pigeon : Bird { func fly(){ print("훨~ 훨~") } // 비행한다 - 중복 } } class Penguin : ..

Swift) Extension 익스텐션 사용하는 이유 기존 타입의 기능확장 확장된 코드 영역은 비교적 side effect 에서 자유로움 기능별로 단위를 묶어서 표현하기 쉬움 특징 *열거형, 구조체, 클래스, 프로토콜 확장 가능 * 재정의는 불가능 연산프로퍼티 추가가능 상속과는 달리 수평적 기능 추가의 느낌이 있음 사용 예시 기존의 기본클래스(구조체)의 기능적 확장 extension Int{ func changeToString ->(String){ return "\(self)" } } Default Implement - 프로토콜 기본구현 protocol runable{ func run() } extension runable{ func run(){ print("뒤뚱뒤뚱") } } TypeAlias 와 함께..

역할 , 책임 , 협력 객체 현실의 사물을 추상화 / 모방 ? 가상세계의 사물을 창조 객체간의 협력 protocol guest{ func order(menu : String){} } // 손님 역할 protocol Casher{ func takeOrder(menu : String, money : UInt){} func deliver(menu : String){} } // 캐셔 역할 protocol Barista{ func makeCoffee(menu : String) -> (Coffee){} } // 바리스타 역할 각각의 역할이 존재하고 그에 해당하는 책임이 있다. 하나의 문제를 해결하기 위해서는 여러 객체간의 협력이 필요하다. 역할은 외부에서 볼때는 역할이고 , 내부에서 볼때는 일종의 책임에 해당한다...