객체지향 프로그래밍이란?

객체 지향의 특징

1. 추상화
2. 캡슐화
3. 상속
4. 다형성

객체 지향 프로그래밍

• 컴퓨터 프로그램을 → "객체"들의 모임으로 파악하는것
  • 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.
• 프로그램을 유연하고 변경이 용이하게 만든다.
  • 레고 블럭 조립하듯, 키보드 마우스 갈아 끼우듯이 → 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법이다.

---

1. 추상화

• 객체에서 공통된 속성과 행위를 추출 하는 것

  • 설계도
  • 공통된 기능을 공유할 때 사용 (서로 관계있는 얘들)
    • 차 추상 클래스 → 아우디, 현대, 벤츠 의 상속 클래스(객체들)
    • 예시) 차 라는 설계도가 있고 → 니싼이라는 새로운 객체가 필요하면 →설계도를 받아서 구현하면 된다.

2. 캡슐화

• 변수와 함수를 하나의 클래스 안에 캡슐로서 묶는다.

  • 프로그램의 세부 구현을 외부로 드러나지 않도록 감출 수 있다. (직접 까봐야함)
  • 낮은 결합도를 유지할 수 있도록 설계하는 것
    

3. 상속

• 부모 클래스의 필드와 메서드를 자식 클래스에게 물려줄 수 있다.

  • 상속을 사용하면 적은 양의 코드로 새로운 클래스를 작성할 수도 있고 공통적인 코드를 관리하여 코드의 추가와 변경이 쉽다.
    

4. 다형성

• 객체지향의 핵심
• 어떠한 요소에 여러 개념을 넣어 놓는 것
• 하나의 클래스 내부에 같은 이름의 행위를 여러개 정의하거나 (오버로딩)
  상위 클래스의 행위를 하위 클래스에서 재정의하여 사용할 수 있기 때문에 다형성이라는 특징을 갖게 된다. (오버 라이딩)

• 자바 언어의 다형성을 활용해 역할과 구현으로 나눌 수 있다.
  역할 = 인터페이스
  구현 = 인터페이스를 구현한 클래스, 구현 객체
• 객체를 설계할 때 역할과 구현 명확히 분리
• 객체 설계시 역할(인터페이스)을 먼저 부여하고,→ 그 역할을 수행하는 구현 객체 만들어서 사용한다.

오버라이딩

• 상위 클래스가 가지고 있는 메소드를 하위 클래스가 재정의해서 사용하는 것

오버로딩

• 같은 이름의 메서드가 인자의 개수나 자료형에 따라 다른 기능을 하는 것
  • (예: String의 println()메서드)

---

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

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

• SRP: 단일 책임 원칙(single responsibility principle)
• OCP: 개방-폐쇄 원칙 (Open/closed principle)
• LSP: 리스코프 치환 원칙 (Liskov substitution principle)
• ISP: 인터페이스 분리 원칙 (Interface segregation principle)
• DIP: 의존관계 역전 원칙 (Dependency inversion principle)

1. 단일책임 원칙

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

  • 중요한 기준은 변경. → 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
    • UI를 변경했는데 애플리케이션 로직을 다 뜯어고쳐야 한다 → 단일책임 원칙을 못지킨것
    • UI 변경과 객체의 생성과 사용을 분리 → 단일책임 원칙 잘 지킴

2. 개방-폐쇄 원칙

• 확장에는 열려 있으나 변경에는 닫혀 있어야 한다

  • 예시)
    • 인터페이스를 구현한 → 새로운 클래스를 하나 만드는 것은 (확장임)
    • 핵심!: 추가하거나 뭐 그런건 확장! → 상관없음
    • BUT 기존 코드를 변경, 구현 코드를 변경하는것엔 닫혀있어야함
      (변경하는것은 스프링 빈으로 등록한 클래스에서 해줄것임 → 그리고 다른 클래스에선 변경된 스프링 빈을 내려받고)

    //이렇게 구현 코드 변경이 가능하면 -> 변경에 열려있는 것이다 !!! 개방폐쇄원칙 못지킴
    MemberRepository m = new MemoryMemberRepository(); //기존 코드
    MemberRepository m = new JdbcMemberRepository(); //변경 코드 (리파지토리 바꾸기)

3. 리스코프 치환 원칙

• 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야 한다

  • 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체를 믿고 사용하려면, 이 원칙이 필요하다.
    • 예시) 자동차 인터페이스의 → 구현체 엑셀을 → 뒤로 가게 구현하면 LSP 위반, 느리더라도 앞으로 가야함 (정확성을 깨트리지 않아야함)
    • 구현체 엑셀3, 4, 5, 6 도 앞으로 가는 기능이어야 한다.

• 단순히 컴파일에 성공하는 것을 넘어서는 이야기다.
  • 자동차가 뒤로가게 구현해도 컴파일은 성공한다

4. 인터페이스 분리 원칙

• 범용 인터페이스 하나보다 클라이언트를 위한 여러 개의 인터페이스로 구성하는 것이 좋다.
  • 예) 자동차 인터페이스를 -> 운전 인터페이스, 정비 인터페이스로 분리
  • 예) 사용자 클라이언트를 -> 운전자 클라이언트, 정비사 클라이언트로 분리

• 인터페이스를 잘 분리할수록 → 명확해지고, 대체 가능성이 높아진다.

5. 의존관계 역전 원칙

• 추상화에 의존해야지, 구체화에 의존하면 안된다
  • (의존성 주입은 이 원칙을 따르는 방법 중 하나)

• 핵심!: 코드가 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
  • 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다! 구현체에 의존하게 되면 변경이 아주 어려워진다