객체 지향
객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나
여러 개의 독립된 단위, 즉 객체들의 모임으로 파악하고자 하는 것입니다.
각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있습니다.
객체 지향 특징은 추상화, 캡슐화, 상속, 다형성이 있으며
다형성에 대해 자세히 알아보겠습니다.
다형성
다형성은 프로그램 언어의 각 요소들이 다양한 자료형에 속하는 것이 허가되는 성질을 가리킵니다.
쉽게 말해서, 하나의 객체에 여러 가지 타입을 대입할 수 있다는 것을 의미합니다.
다형성은 역할(인터페이스)과 구현(인터페이스를 구현한 클래스)을 분리하는 것이 중요합니다.
인터페이스와 구현으로 분리하면 단순해지고, 유연해지며, 변경도 용이해집니다.
따라서 클라이언트는
대상의 인터페이스만 알면 되고,
구현 대상의 내부 구조는 몰라도 되고,
구현 대상의 내부 구조가 변경되어도 영향을 받지 않으며,
구현 대상 자체를 변경해도 영향을 받지 않는 다는 장점이 있습니다.
정리하자면,
유연하고 변경이 용이
확장 가능한 설계 (인터페이스에 구현설계를 확장하면서 확장가능)
클라이언트에 영향을 주지 않는 변경이 가능합니다.
그러므로 인터페이스를 안정적으로 잘 설계하는 것이 중요합니다.
스프링에서 나오는 제어의 역전(IoC), 의존관계 주입(DI)은
다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원해주므로
다형성을 극대화해서 이용할 수 있게 도와줍니다.
객체 지향 설계 (SOLID)
객체 지향 설계의 5원칙
• SRP 단일 책임 원칙(single responsibility principle)
• OCP 개방-폐쇄 원칙 (Open/closed principle)
• LSP 리스코프 치환 원칙 (Liskov substitution principle)
• ISP 인터페이스 분리 원칙 (Interface segregation principle)
• DIP 의존관계 역전 원칙 (Dependency inversion principle)
SRP 단일 책임 원칙
한 클래스는 하나의 책임만 가져야 합니다.
이때 하나의 책임이라는 것이 모호한데
변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것입니다.
OCP 개방-폐쇄 원칙
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 합니다.
얼핏 들으면 모순적이라고 생각할 수 있습니다.
다형성을 활용해보겠습니다.
위와 같은 클래스 관계에서
public class MemberService { //private MemberRepository memberRepository = new MemoryMemberRepository(); private MemberRepository memberRepository = new JdbcMemberRepository(); }
MemberService 클라이언트가 Memory, Jdbc 중에 구현 클래스를 직접 선택할 수 있어
다형성을 사용한 모습을 볼 수 있습니다.
하지만 위의 예시에서는 구현 객체를 변경하려면 MemberService 클래스 코드를 변경해야 합니다.
위와 같이 다형성을 사용했지만 OCP 원칙을 지킬 수 없었습니다.
이를 해결하기 위해서는 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요합니다.
해결책에 대해서는 아래에서 알아보겠습니다.
LSP 리스코프 치환 원칙
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 합니다.
예를 들어 자동차 인터페이스의 엑셀은 앞으로 가는 기능이지만 뒤로 가게 구현하면 LSP 위반입니다.
ISP 인터페이스 분리 원칙
범용 인터페이스 하나보다 특정 클라이언트를 위한 인터페이스 여러 개가 낫습니다.
자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
범용 인터페이스를 여러 개의 인터페이스로 분리하면 인터페이스가 명확해지고 대체 가능성이 높아집니다.
DIP 의존관계 역전 원칙
구체화에 의존하지말고 추상화에 의존해야한다는 원칙입니다.
쉽게 말해서, 구현 클래스(구현)에 의존하지말고 인터페이스(추상화, 역할)에 의존하게 해야 한다는 것입니다.
하지만 OCP에서 설명한 MemberService는 인터페이스에 의존하지만, 동시에 구현 클래스에도 의존합니다.
MemberService 클라이언트가 구현 클래스를 직접 선택하기 때문입니다.
public class MemberService { //private MemberRepository memberRepository = new MemoryMemberRepository(); private MemberRepository memberRepository = new JdbcMemberRepository(); }
정리하자면 다형성만으로는 OCP, DIP를 지킬 수 없습니다.
OCP, DIP 해결 방안
이를 해결하기 위해서는 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요합니다.
그 기능을 스프링에서는 스프링 컴포넌트 DI(Dependency Injection) 의존관계 주입을 통해 할 수 있습니다.
간단하게 말하자면 MemberService 클라이언트에서는 MemberRepository 인터페이스만을 사용하는 방식으로 개발을 진행한 후,
MemberRepository가 JdbcMemberRepository 객체를 반환하는 별도의 조립, 설정자를 추가하여 개발할 수 있습니다.
@Bean public MemberRepository memberRepository(){ // return new MemoryMemberRepository(); return new JdbcMemberRepository(); }
따라서 스프링을 이용해서
클라이언트 코드의 변경 없이 기능 확장을 할 수 있고 (OCP : 개방-폐쇄 원칙)
클라이언트가 인터페이스에만 의존하므로 (DIP : 의존관계 역전 원칙)
OCP, DIP 둘다 잘 지킬 수 있습니다.
DI(의존관계 주입)에 관한 자세한 내용은 Spring IoC, DI 정리 참고하시길 바랍니다.
