3. 디자인패턴의 아름다움 스터디
캡슐화
- 데이터 은닉
- 접근제어
- 캡슐화
- 제한된 메서드 노출
- 속성을 캡슐화
- 사용자의 학습비용 감소
- 사용 시 오류 확률 감소
- 사용자에게 노출할 비즈니스의 범위를 결정할 수 있다.
- 이거는 개발자가 정할 수 없는 영역
- 사용자가 학습할 인터페이스를 구성할 수 있다.
- 이거는 개발자가 정할 수 있는데, 어떤 기준으로 정하게 될까?
상속과 다형성
- 대체가능성
- 구상형은 추상형을 대체 가능
- 타입이 계층 구조를 가질 수 있다.
- 내적동질성
- 생성형이 언제나 연산을 실행함
- 아래 예시에서..태어날 때 Child 로 태어났기 때문에, 어떤 형태로 다형성을 만족시켜도 Child 여야함
open class Parent {
fun print() = printlin(message())
open fun message() = "parent"
}
class Child:Parent(){
override fun message() = "child"
}
val target:Parent = Child()
target.print()
상속
- 상속이 연쇄된 의존성을 만들어낸다.
- 각 상속단계에 구현을 재활용 할 수 있음
- 대신, 내적동질성읠 런타임 유지에 큰 비용이 든다.
- 하위 층이 상위 층에 의존하기 쉬워짐
인터페이스
- 1단계의 의존성만 만들어냄
- 모든 의존하는 타입에 구현을 만들어야함.
- 연쇄 의존성을 제거하기 위해 개별적으로 구현한 것
트레이트
- 인터페이스와 흡사. 타입과 인터페이스의 연결을 별도로 정의함
- 타입에 인터페이스를 추가하기 쉬움
타입 계층
- 호스트코드는 추상화된 연산에 의존하게 됨
- 추상화된 연산의 변경이 매우 힘듬
- 추상층에 의존하는 모든 구상층의 연산을 변경해야함
- 데이터가 많고 연산이 정해진 경우 유효함
- 이를 타입 계층이라고 부름.
- 여기서 타입은 연산의 집함임
추상데이터 타입
- 제공되는 타입은 1개이나, 내부에 다양한 데이터를 소유가능
- 각 연산 내부에서 데이터를 분기하여 처리함
- 데이터의 종류가 늘어날 때 마다, 모든 연산을 고쳐야함
- 반대로 연산을 늘리기는 쉬움
추상화
-
메서드 내부 구현을 숨김
-
메서드가 제공하는 기능에만 집중
-
구현 정보를 분리해 인지적 복잡성을 낮춤
-
추상적인 이름 짓기
- getNaverCloudPictureUrl 이란 이름이 있다고하면
- get 으로도 지을 수있고, getNaver, getNaverUrl ..등등으로 지을 수 있다.
- 이 문제가 바로 추상화 레벨을 결정하는 것
- Naver.Cloud.Url(url).get(picutre)
- 추상화를 통해서 남이 어떻게 이 메서드를 사용할것인가?
- 즉..추상화라는것은 추상화 레벨을 결정하는 것
-
추상화 기법 (인지이론)
- 모델링 (필요한 부분만 추출)
- 필요한 부분이 어떤건가?
- 카테고라이징 (특정 기준으로 동일하게 취급)
- 그룹핑 (임의의 집단으로 묶어서 관리)
- 모델링 (필요한 부분만 추출)
-
추상화 기법 (생각의 탄생)
- 관찰
- 생각의 한 형태로 감각적 경험과 지적의식을 가깝기 연결하여 감각작용을 이해하는 것
- 형상화
- 관찰의 결과를 시각적인 형태로 그려내는 것
- 추상화
- 세부적인 내용을 이해하고, 이를 제거하여 오직 전체를 대표할 수 있는 하나만 남기는 것
- 패턴 인식
- 추상화를 통해 단순화 된 것들 사이의 규칙을 찾아내고, 더 나아가 여러 패턴들 사이를 연결하는 메타패턴도 찾아내는 것
- 패턴형성
- 인색했던 패턴들을 다른 대상에게도 발견하여, 적용하는 것 뿐 아니라 패턴의 조합으로 문제를 해결하는 것
- 관찰
추상화기법(소프트웨어 공학)
- 일반화와 특수화
- 집합과 분해
- 분류와 인스턴스화
is member of
- 연관화 (association)is instance of
- 분류화 (classification)is part of
- 집단화 (aggregation)is a
- 일반화 (generalization)