앱등개발자IOS

# 데코레이터 패턴 ( => 기존 class코드를 바꾸지 않고 객체에 새로운 임무 추가 가능!) ## 정의 : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고, 자동으로 내용이 갱신되는 방식으로, "일대다 의존성"을 정의한다. ## 키워드 : One-to-Many ## 목적 : 상태 변화(State change)를 다른 다수의 객체들에게 알리기 위함 ## 디자인 원칙!! : OCP ( Open-Closed Principle ) => Class는 확장에는 열려있고, 변경에는 닫혀있어야 한다. (

Design Pattern with Java & Swift 2022. 10. 7. 00:45

# 옵저버 패턴 ( = Publish/Subscribe 패턴) ## 정의 : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고, 자동으로 내용이 갱신되는 방식으로, "일대다 의존성"을 정의한다. ## 키워드 : One-to-Many ## 목적 : 상태 변화(State change)를 다른 다수의 객체들에게 알리기 위함 ## 하나의 Object는 옵저버이자 Subject일 수 있다!!! 옵저버 패턴은 여러 방식으로 구현할 수 있지만, 보통 클래스 디자인으로 구현한다. ## 언제 사용하는가? - Loose Coupling이 필요할 때 : 객체들이 상호작용할 수는 있지만, 서로를 잘 모르는 관계 => 옵저버는 구상 클래스가 무엇인지, Observer가 무엇을 하는지 알 필요도 없다. =>..

Design Pattern with Java & Swift 2022. 9. 29. 12:49

객체지향 설계를 하며, 아래와 같이 fly()메서드를 Duck 추상클래스에 선언해주고, 매 번 concrete class에서 override하며 정의해준다면, 단점 - 1. 서브클래스에서 코드가 중복됨 ( 같은 fly()형태를 띠는 클래스들에 같은 코드를 중복해서 작성해야함 ) - 2. 실행 시에 특징을 바꾸기 힘들다 ( 클래스 내부에 concrete하게 구현되므로 실행 중 행동의 특성을 바꿀 수 없다) - 3. 모든 subclass들이 fly()에 관하여 어떤 행동들을 하는지 다 알기 힘들다. ( 관리하기 어려움 ) # 이런 경우에는 fly()를 superClass에서 빼, Flyable 이라는 Interface를 만들어 각 Subclass가 Implement하게 한다면? => 해당 특성 (fly, q..

Design Pattern with Java & Swift 2022. 9. 29. 12:49