객체지향 관련 핵심 내용 추출 정리

https://link.coupang.com/a/QoNwV

개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴

본문의 내용은 위 책에서 정리한 내용 일부이며, 자세히 알고 싶은 분들은 위 책을 구매해서 보시는 것을 추천드립니다.

씹고 뜯고 맛보고 즐겨도 내용이 지루하지 않고, 정말 돈이 아깝지 않은 책!

 

 

객체지향에서는 추상화와 다형성을 이용해 변화하는 부분을 관리한다.

• 변화하는 부분 관리 <= 추상화 + 다형성

 

절차 지향적으로 코드가 만들어지는 이유

객체 자체와, 객체 지향의 핵심인 캡슐화 및 추상화가 적용되지 않았기 때문

 

객체 지향적으로 만든 코드에서는 객체의 데이터를 변경하더라도 해당 객체로만 변화가 집중(캡슐화)되고 다른 객체에는 영향을 주지 않기 때문에, 절차 지향보다 프로그램을 더 쉽게 변경할 수 있는 장점을 갖는다.

 

4. 의존

객체 지향적으로 프로그램을 구현하다 보면, 다른 객체가 제공하는 기능을 이용해서 자신의 기능을 완성하는 객체가 출현하게 된다.

• 흐름제어 객체나, Agent, Manger 같은 이름의 객체들이 이 역할을 수행 할 듯 싶음.

5. 캡슐화

객체 지향의 장점 : 한 곳의 구현 변경이 다른 곳에 변경을 가하지 않도록 해준다는 것

객체지향은 기본적으로 캡슐화를 통해서 한 곳의 변화가 다른 곳에 미치는 영향을 최소화한다.

캡슐화는 객체가 내부적으로 기능을 어떻게 구현하는지 감추는 것

따라서, 캡슐화를 통해서 내부 구현 변경의 유연함을 얻을 수 있다.

• 내부 구현 변경의 유연함 <= 캡슐화

캡슐화를 위한 두 개의 규칙

• Tell, Don't Ask - 데이터를 물어보지 말고, 기능을 실행해 달라는 규칙, 기능 실행을 요청하는 방식으로 코드를 작성하다 보면, 자연스럽게 기능을 어떻게 구현했는지 여부가 감춰진다.
• 데미테르의 법칙 

 

다형성과 추상 타입

객체 지향이 주는 장점 : 구현 변경의 유연함

변경을 지원하는 요소

1. 내부 구현 변경의 유연화 - 캡슐화
2. 어떤 역할의 기능을 사용하는 클라이언트 코드에서 여러 타입의 객체를 받을 수 있게 하여 변화되는 부분 관리의 유연함 ( 필요한 기능을 정의하고 (ex: 계산), 그 기능을 구현하는 여러 방법을 구현 클래스로 생성 ( ex: 카드 결제, 현금 결제, QR 결제 등) ) - 추상화, 다형성
   1. 추상화 : 데이터나 프로세스 등을 의미가 비슷한 개념이나 표현으로 표현하는 과정
      1. 추상 타입 : 추상화 된 타입은 오퍼레이션의 시그니처만 정의 할 뿐, 실제 구현을 제공하지는 못한다.
   2. 다형성 : 한 객체가 여러 타입을 가질 수 있다.

 

1. 인스턴스의 생성 역할을 하는 클래스를 따로 빼거나

2. DI 등으로 외부에서(생성자나 setter로) 주입받으면

OCP(개방 폐쇄 원칙)을 더 잘 지킬 수 있다.

• OCP 완성? <= DI + 추상화, 다형성

 

 

3.3 변화되는 부분을 추상화 하기

추상화가 되어 있지 않은 코드는 주로 동일 구조를 갖는 if-else 블록으로 나타난다.

 

 

조립을 이용한 재사용

코드 재사용의 목적일 때는 상속이 아니라 조립을 우선 고려 할 것

 

위임은 내가 할 일을 다른 객체에게 넘긴다는 의미를 담고 있으며,

• 위임 <= 조립 방식으로 구현됨

 

 

설계원칙 : SOLID

이전 장에서는 객체 지향의 기본 내용들인 책임 할당, 캡슐화, 다형성과 추상화, 조립을 통한 재사용에 대해서 알아봤었다.

SOILD는 객체 지향적으로 설계하는데 기본이 되는 설계 원칙이다.

SOLID 설계 원칙은 설계 관련 내용들은 체계적으로 정리한 것이다.

 

 

단일 책임 원칙

객체 지향의 기본은 책임을 객체에게 할당하는 것

단일 책임 원칙은 이 책임과 관련된 규칙이다.

클래스는 단 한 개의 책임을 가져야 한다.

• 객체의 책임 <= 단일 책임 원칙

클래스가 여러 책임을 갖게 되면 그 클래스는 각 책임마다 변경되는 이유가 발생하기 때문에, 클래스가 한 개의 이유로만 변경되려면 클래스는 한 개의 책임만을 가져야 한다.

 

객체가 단일 책임의 원칙이 지켜지고 있지 않다는 것을 확인할 수 있는 지표가 있을까?

서로 다른 Client에서 어떤 객체에 있는 메서드들 중 서로 다른 메서드'만' 호출해서 사용한다면, 그 메서드는 각각 다른 책임에 속할 가능성이 높고 책임 분리 후보가 될 수 있다.

 

개방 폐쇄 원칙

- 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.

위 말을 풀면

- 기능을 변경하거나 확장할 수 있으면서

- 그 기능을 사용하는 코드는 수정하지 않는다.

개방 폐쇄 원칙을 개인적으로 해석해보자면, 어떤 기능이 추후 다른 방식으로도 구현될 수 있을 것 같으면, 이 기능을 사용(인스턴스.메시지 를 통한 사용)하는 클라이언트 코드에서는 변경이 일어나지 않고 '확장성 있게 변경' 가능하도록, 그 기능을 추상화하여 인터페이스 만들고, 다형성 활용하여 클라이언트 코드에서 기능 갈아 끼울 때 변경 일어나지 않도록 구현해야 한다는 의미로 해석이 됨.

 

2.1 개방 폐쇄 원칙이 깨졌을 때의 주요 증상

1. 다운 캐스팅을 한다.

 이런 경우가 발견된 경우, 이 기능을 추상화하여 부모 클래스에 적용 가능한지 검토를 한다.

 가능한 경우,  해당 로직을 추상화하여 클라이언트에서는 추상 타입을 사용하도록 하고, 추상 타입의 구현체는 개별적으로 구현하여 채워 넣는다.

2. 비슷한 else if 구문이 존재한다.

 

 

 

3. 리스코프 치환 원칙

• OCP <= 추상화 + 다형성(상속)
• 다형성 <= 리스코프 치환 원칙
• 기능의 명세(계약) <= 리스코프 치환 원칙

정의 : 상위 타입의 객체를 하위 타입의 객체로 치환해도, 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

리스코프 치환 원칙은 계약과 확장에 관한 것

 

예제는 쿠폰 할인 예제

 

3.1 리스코프 치환 원칙이 깨졌을 때 주요 증상

1. 타입을 확인하는 기능(instanceof을 사용하는 것은 전형적인 리스코프 치환 원칙을 위반할 때 나타나는 증상)