최범균 OOP
비용
개발에서 비용은 고려대상이다. 작은 비용으로 변경이 가능해야 된다.
객체
절차 지향 vs 객체 지향
- 절차 지향 - 데이터를 공유하는 모델(비용을 올리는 경우가 많다.)
- 객체 지향 - 테이터와 프로시저를 따로 분리
객체란
객체의 핵심 -> 기능제공
- 객체는 제공하는 기능으로 정의
- 내부적으로 어떤 데이터를 가졌느냐로 정의하지 않음
인터페이스
객체가 제공하는 기능의 명세(이름,입력,결과)
메시지
메시지 전달
- 객체에게 기능 실행을 요청
- 일반적인 언어에서는 메소드 호출
캡슐화
객체가 내부적으로 기능을 어떻게 구현 했는지 감추는 것
- 구현에 사용된 데이터 상세 내용을 감춤
캡슐화 하지 않으면?
변경이 연쇄적으로 퍼짐
캡슐화를 하면
기능은 제공하고 구현 상세를 감춤
캡슐화를 위한 두가지
tell, don`t ask
- 데이터를 달라고 하지말고 해달라고 하기
demeter`s law
- 메서드에서 생성한 객체의 메서드만 호출
절차지향 방지책
필요한것만 받기
다형성과 추상화
개발비용을 낮춰 주는 객체지향의 두가지 특성
다형성
여러 모습을 갖는것
- 모습 -> 타입
- 객체지향언어에서는 타입상속으로 구현
추상화
- 데이터나 프로세스 등을 의미가 비슷한 개념이나 의미 있는 표현으로 정의 하는 과정
타입 추상화
여러 구현 클래스를 대표하는 상위 타입 도출
추상타입은 구현을 감춤
- 의도를 더 잘 드러냄
추상화 결과
사용 대상의 변경 유연함
변경될때 추상화를 하라
변경이나 확장이 발생할때 추상화 하라
OCP
개방폐쇄원칙
- 확장에는 열려있고 수정에는 닫혀있음
기능과 책임의 분리
기능
- 입력
- 출력
- 상태변경
기능분해
기능은 하위 기능으로 분해
기능을 누가 제공할것이냐?
기능은 곧 책임
- 분리한 각 기능을 알맞게 분배
큰 클래스, 큰 메서드
클래스나 메서드가 커지면 책임에 따라 알맞게 코드 분리 필요
몇가지 책임 분배/분리 방법
- 패턴 적용
- 계산 기능 분리
- 외부 연동 분리
- 조건별 분기는 추상화
패턴적용
전형적인 역활 분리
계산의 분리
계산 기능을 별도로 분리
- 분리한 입력과 출력은 다른 코드에 덜 엮이도록
연동 분리
- 네트워크, 메시징, 파일 연동처리
조건 분기는 추상화
연속적인 if-else 는 추상화 고민
알맞은 책임 분리 테스트
테스트가 쉬워진다
의존
기능 구현을 위해 다른 구성 요소를 사용하는것
결합도
- 구성요소가 서로 의존하는 정도
의존은 변경이 전파될 가능성을 의미
- 의존하는 대상이 바뀌면 바뀔 가능성이 높아짐
- 의존대상은 적을수록 변경에 덜 영향
의존대상 많을때
한클래스에서 많은 기능을 제공하는 경우
- 기능별로 알맞게 분리할 것을 고민(단일 책임 원칙)
몇가지 의존 대상을 단일 기능으로 묶어서 생각해보면 의존대상을 줄일수 있다.
의존 대상 객체를 직접 생성하면?
생성 클래스가 바뀌면 의존하는 코드도 바뀜
의존 대상 객체를 직접 생성하지 않는 방법
- 의존주입
- 서비스 로케이터
- 팩토리
프레임 워크가 지원하면 DI
프레임워크에 기댈수 없다면 서비스 로케이터
- 서비스로케이터 단점
- 의존 관계가 잘 드러나지 않음
- 사용하지 않는 타입에 대한 의존 발생
DIP
- 고수준 모듈 - 의미 있는 단일 기능을 제공
- 저수준 모듈 - 고수준 모듈의 기능을 구현하기 위해 필요한 하위 기능의 실제 구현
고수준이 저수준에 직접 의존하면 저수준 모듈이 변경되면 -> 고수준 모듈에 영향
고수준 모듈 관점에서 저수준 모듈을 추상화
좋은 설계 가능성을 높힘
고수준의 변경을 최소화 하면서 저수준 모듈의 변경 유연함을 높임
처음부터 바로 좋은 설계가 나오지는 않음