객체 지향 프로그래밍과 설계 원칙(SOLID)

1. 객체 지향 프로그래밍

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

 

2. 역할과 구현을 분리

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

 

3. 스프링과 객체 지향

• 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다.
• 스프링에서 이야기하는 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.

스프링의 만들어지고 사용하는 이유는 결국 객체지향의 장점을 극대화하기 위함이다. 

 

4. 좋은 객체 지향 설계의 5가지 원칙(SOLID)

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

한 클래스는 하나의 책임만 가져야 한다.

• • 하나의 책임이라는 것은 모호하다.
    • 클 수 있고, 작을 수 있다.
    • 문맥과 상황에 따라 다르다.
  • 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다.

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

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 

• • 변경에 대한 비용을 최대한 줄이면서 확장에 대해서는 가능한 극대화 해야 한다.
  • 다른 추가 사항이 일어나더라도 기존 구성은 변경하지 않으며 확장에 대한 가능성을 열어둬야 한다.

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

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

• • 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙 (인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.

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

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

ex) 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음

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

추상화에 의존해야지, 구체화에 의존하면 안 된다.

• • 구현 클래스에 의존하지 말고, 인터페이스에 의존해야 한다.
  • 역할(Role)에 의존하게 해야 한다. 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다. 구현체에 의존하게 되면 변경이 어려워진다.
  • Spring이 의존성 주입으로 인해 이문제를 해결할 수 있다.

Example

public class MemberService {
    private MemberRepository memberRepository = new MemoryMemberRepository(); //기존코드
}

public class MemberService {
    //private MemberRepository memberRepository = new MemoryMemberRepository();
    private MemberRepository memberRepository = new JdbcMemberRepository(); //변경코드
}

기존 코드에서 변경 코드로 바꾼다고 생각해보자. 우리는 MemberRepository 인터페이스(역할)에 의존하게 설계했다고 생각하지만 MemoryMemberReopository(기존코드), JdbcMemberRepository(변경코드) 구현 클래스에도 의존하고 있는 것이다. MemberService 클라이언트가 구현 클래스를 직접 선택하였다. 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
분명 다형성을 사용했지만 DIP 원칙을 지킬 수 없다.
이를 해결하기 위해 우리는 Interface에 의존하도록 설계를 해야 한다.
=> 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다. (이 역할을 Spring이 해준다.)

 

5. 정리

• 순수하게 자바로 OCP, DIP 원칙들을 지키면서 개발을 해보면, 결국 스프링 프레임워크를 만들게 된다. (DI 컨테이너)
• 모든 설계에 역할과 구현을 분리하자. (이상적으로 모든 설계에 인터페이스를 부여하자.)