일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |
- OCP
- 알고리즘
- 유연한 설계
- 일관성 있는 협력
- 컴파일 타임 의존성
- 객체 생성 사용 분리
- 서브 타이핑
- dip
- 런타임 의존성
- 믹스인
- 객체지향
- 설계 재사용
- 유여난 설계
- 행동 호환성
- 다형성
- 책임주도설계
- Swift#flatMap#map#Monad#함수형 프로그래밍#Optional
- 오브젝트
- '기존 설계 재사용
- 명령-쿼리 분리
- OOP
- iSP
- 하향식 접근
- 상속 조합 폭발적 증가
- 메서드를 통한 해결
- 의존성
- Apple # HIG #iOS15 #iOS14 #Human #Interface #Guidelines #Apple developer # Apple human interface guidelines
- 추상화
- 상속
- 합성
- Today
- Total
목록2024/07 (3)
도니의 iOS 프로그래밍 세상
디자인 패턴 및 프레임 워크디자인 패턴S/W 설계에서 반복되는 문제에 대해 적용할 수 있는 해결 방법프레임워크설계와 코드를 함께 재사용하기 위한 것공통점협력을 일관성 있게 제공하는 게 목적차이점디자인 패턴: 설계의 묶음프레임 워크: 일관성 있는 협력을 제공하는 확장 가능한 코드01. 디자인 패턴과 설계 재사용패턴의 핵심은 정의가 아닌 뉘앙스를 이해하는 것패턴의 핵심적 특징패턴은 반복적 문제와 해법의 pair로 구성패턴을 사용하여 다른 사람과 의사소통이 간단해짐패턴은 실무에서 “발견된 것”패턴은 다양한 context에서 사용되는 유용한 idea패턴 분류아키텍쳐 패턴s/w 전체 구조 결정에 사용정의된 서브 시스템 제공, 각 서브 시스템의 책임 정의, 서브 시스템 관계간 규칙 및 가이드라인 포함디자인 패턴특정..
객체 협력 구조가 기존과 다를 때, 코드의 이해도가 낮아지고 코드 수정시 더 많은 버그를 유발하게 된다.따라서 객체간 일관성 있는 협력 방식을 사용하여, 유사 기능엔 유사한 협력 패턴을 사용해야 한다.설계 일관성변하는 개념, 변하지 않는 개념을 분리변하는 개념을 캡슐화 하는 게 중요캡슐화는 변화는 어떤것을 감추는 것(데이터 은닉만을 포함하지 않음)결론일관성 있는 협력을 통해, 다른 사람들과 협업시 코드 이해도를 높이고 버그 가능성을 줄일 수 있음캡슐화약간의 부조화를 수용하더라도, 서비스 내에 일관성 있는 패턴을 지키는게 더 중요하다ex. 인터페이스에 객체중 한곳에서 특정 로직을 수행해야 함해당 객체의 역할상 특정 로직을 수행한다는게 초기 의도와 다름하지만 그렇더라도, 각 서비스들의 책임이 올바르게 동작한..
LSP서브 타입과 서브 클래스가 부모 클래스, 상위 타입 대체가 가능 해야함불가능한 예시직사각형, 정사각형현실에서는 정사각형은 직사각형의 한 종류 지만, 동작이 달라 상속이 불가능 함why? 정사각형은 높이를 변경하면, 너비도 함께 바뀜(따라서, 두 사각형의 높이를 변경했을 때 넓이의 변화가 다름(직사각형은 높이만큼, 정사각형은 변경된 높이의 제곱만큼 영향을 받음)따라서 클라이언트의 가정에 따라 부모 클래스 가정을 세우고 맞게 처리해야 함is-a 관계는 클라의 입장에서 고려, 자식 객체가 부모 객체의 행동을 대체할 수 있어야 함(속성은 필요X)LSP의 효과유연한 설계(어떤 자식 클래스과도 안정적으로 협력이 가능)OCP를 위한 전제 조건why? 위반시엔 자식 클래스를 추가할 때마다 문제가 발생하기 때문계약..