좋은 객체지향 프로그래밍?

객체 지향 프로그래밍이란 무엇인가?

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시야에서 벗어나 여러개의 독립된 단위, 즉 “객체” 들의 모임으로 파악하고자 하는것. 각각의 객체는 메세지를 주고받고, 데이터를 처리할 수 있음 = (협력가능)
객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다

유연하고, 변경이 용이하다?

다형성의 실세계 비유

역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며 변경도 편리해짐
장점
- 클라이언트는 대상의 역할(인터페이스)만 알면 됨
- 클라이언트는 구현 대상의 내부 구조를 몰라도 됨
- 클라이언트는 구현 대상의 내부 구조가 변경돼도 영향을 받지 않는다
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다
자바 언어
- 역할 = 인터페이스
- 구현 = 인터페이스를 구현한 클래스, 구현 객체
객체를 설계할 때 역할과 구현을 명확히 분리해야됨
객체 설계시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기

SRP: 단일 책임 원칙(single responsibility principle)

OCP: 개방-폐쇄 원칙 (Open/closed principle)

LSP: 리스코프 치환 원칙 (Liskov substitution principle)

ISP: 인터페이스 분리 원칙 (Interface segregation principle)

DIP: 의존관계 역전 원칙 (Dependency inversion principle)

MemberService클라이언트가 구현 클래스를 직접 선택
- MemberRepository m = new MemoryMemberRepository // 기존 코드
- MemberRepository m = new JdbcMemberRepository // 변경코드
구현 객체를 변경하려면 클라이언트 코드를 변경해야함
분명 다형성을 활용했지만 OCP원칙을 지킬 수 없다.
⇒ 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 함
다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
예) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능이다, 뒤로가게 구현하면 LSP원칙을 위반함.

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.” 의존성 주입은 이 원칙을 따르는 방법 중 하나.
쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존해라
앞에서 예기한 역할(Role)에 의존하게 해야 한다는 것과 동일함. 클라이언트가 구현체에 의존하지 말고 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다!
그런데 OCP에서 설명한 MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다
MemberService 클라이언트가 구현 클래스를 직접 선택
MemberRepository m = new MemoryMemberRepository(); DIP 위반