[학습] 객체 지향 프로그래밍 입문 정리
인프런 최범균님의 객체 지향 프로그랭 입문 강좌를 정리한 내용입니다.
객체
절차지향
객체지향
데이터/프로시저를 객체 단위로 묶음
데이터에 접근하는게 아니라, 프로시저를 통해서 접근함
시간이 지남에 따라 코드 수정이 용이함
객체의 핵심
- 기능 제공
- 예) 회원 객체 - 암호 변경하기 기능 / 차단 여부 확인 하기 기능
- 예) 소리제어기 객체 - 소리 크기 증가하기 기능 / 소리 크기 감소하기 기능
- 기능 명세
- 메서드를 이용해서 기능 명세
- 객체와 객체는 기능을 사용해서 연결
- 기능 사용 = 메서드 호출한다
- 객체와 객체 상호작용 : 메세지
1 | public class Member { |
이런 것은 객체
라기 보다는 구조체
라고 하는게 나을 듯 -> 여기에 Member
클래스에 기능들이 붙게되면 그제서야 객체
라고 표현 가능 하다.
캡슐화
- 데이터 + 관련 기능 묶기
- 객체가 기능을 어떻게 구현했는지 외부에 감춘다.
- 구현에 사용된 데이터의 상세 내용을 외부에 감춤
- 정보 은닉 의미 포함
- 외부에 영향 없이 객체 내부 구현 변경가능
캡슐화는 연쇄적인 변경 전파를 최소화
캡슐화 시도는 기능에 대한 의도(이해)를 높임
캡슐화를 위한 규칙
- Tell, Don’t Ask - 데이터를 달라하지 말고 해달라고 하기
1 | if (acc.getMembership() == REGULAR){ |
아래 처럼 변경하기!
1 | if (acc.hasRegularPermission()){ |
- Demeter’s Law
- 메서드에서 생성한 객체의 메서드만 호출
- 파라미터로 받은 객체의 메서드만 호출
- 필드로 참조하는 객체의 메서드만 호출
상속보단 조립
상속의 단점
- 상위 클래스 변경 어려움
- 클래스의 증가
- 상속 오용
상속의 단점 해결 방법 : 조립
- 여러 객체를 묶어서 더 복잡한 기능을 제공
- 보통 필드로 다른 객체를 참조하는 방식으로 조립 또는 객체를 필요 시점에 생성/구함
상속보다는 조립
- 상속하기에 앞서 조립으로 풀 수 없는지 검토
- 진짜 하위 타입인 경우에만 상속 사용
기능과 책임 분리
기능은 하위 기능으로 분해 가능
기능은 곧 책임
- 분리한 각 기능을 알맞게 분배
클래스나 메서드가 커지면 절차지향의 문제가 발생함
- 여러 기능이 한 클래스/메서드에 섞여 있을 가능성이 짙음
- 책임에 따라 알맞게 코드 분리 필요함
몇 가지 책임 분배/분리 방법
패턴 적용
- 역할 분리 (Controller / Service / Repository , 디자인 패턴)
계산 기능 분리
- 별도 클래스로 분리
외부 연동 분리
- 별도 클래스로 분리
조건별 분기는 추상화
연속적인 if-else는 추상화가 가능한지 고민한 후에 분리 한다.
공통되는 부분을 인터페이스로 뺀다.
해당 인터페이스를 각각 구현한다.
역할 분리가 잘되면 테스트가 용이해짐
의존과 DI
- 기능구현을 위해 다른 구성요소를 사용하는 것 (객체 생성, 메서드 호출, 데이터 사용)
- 의존은 변경이 전파될 가능성을 의미
- 의존하는 대상이 바뀌면 바뀔 가능성이 높아짐
의존대상 많을 때, 기능 많은 경우
- 기능별로 분리 고려
의존 대상 많을 때
- 묶어 보기(기능 구현을 추상화)
의존 대상 객체를 직접 생성하면 ?
의존 대상 객체를 직접 생성하지 않는 방법
- 팩토리, 빌더
- 의존 주입(DI)
- 외부에서 의존 객체를 주입
- 생성자나 setter메서드를 이용해서 주입
- 외부에서 의존 객체를 주입
- 서비스 로케이터
DI의 장점은?
- 의존 대상이 바뀌면 조립기(설정)만 변경하면 됨
- 의존하는 객체 없이 대역 객체를 사용해서 테스트 가능
[학습] 객체 지향 프로그래밍 입문 정리