GDSC ㅇㅇ의 T19 (9/25) 세션의 백엔드 팀원의 발표 내용을 정리한 게시글입니다.

객체 "지향" 코드란?

절차 지향 vs. 객체 지향

절차지향

• 물이 위에서 아래로 흐르는 것처럼 순차적인 처리

객체지향

• 프로그램을 수많은 객체라는 기본단위로 나누고 이들의 상호작용으로 서술하는 방식
• 컴퓨터의 프로그램을 명령어의 목록으로 보는 시각에서 벗어나서 여러가지 객체의 상호작용으로 분석
• 추상화 과정에 적합
• 단점
  • 생각보다 상호작용이 단순하지 않을 수 있다
  • 객체가 상태를 갖는다
    • 변수로 인해 객체가 예측할 수 없는 상태를 가지게 될 수 있다

더 나은 설계는 없다.

비즈니스 모델의 성격에 따라 다를뿐.

객체지향적으로 개발하는 이유는?

• 수십년간 실무 노하우라서 협업할 때 편리핟
• 절차지향 프로그래밍에서는 프로그램적으로 다뤄져야 하는 상태와 상태를 변경시키는 함수가 따로 놀기 때문에 연관성을 확인하기 힘들었지만, 객체 지향 프로그래밍에서는 변수와 함수를 밀접하게 하나의 클래스의 소속으로 만들었기 때문에 관리가 쉽고 테스트가 용이하다

캡상추다

1. 캡슐화

• 메서드를 통해 간접적으로만 노출하기
• 공통되는 특성/속성을 추출

2. 상속

• 자식 클래스가 부모 클래스를 상속받아 설계된 구조
• 리스코프 치환 법칙

3. 추상화

• 구체적인 존재가 가진 무언가를 프로그래밍 요소로 구현

4. 다형성

• 똑같은 클라이언트 코드로 다른 코드를 수행할 수 있는것

SOLID

1. 단일책임원칙

• Single Responsibility Principle
• 한 클래스는 하나의 책임만 가져아 한다
  • controller/service/repository의 분리
• 어떠한 변화에 의해서 클래스를 변경하는 이유도 한가지여야 한다
• 변경에 의한 연쇄작용으로부터 자유로워야 한다
• 분리
  • 컨트롤러: 사용자 Http요청 후에 간단한 처리를 거쳐 넘긴다
  • 서비스: 메서드를 통한 객체의 처리
  • 레포지토리: 객체의 조회 및 저장

2. 개방폐쇄원칙

• 확장을 위해 열려있으나 변경을 위해 닫혀있다
• open-closed principle
• 인터페이스를 통한 개방 폐쇄 원칙 지키기

3. 리스코프 치환 원칙

• 서브타입은 언제나 기반타입으로 교체할 수 있어야한다
• Liskov Substitution Principle
• is-a 관계의 성립
• 부모 클래스가 할 수 있는 행동은 자식 클래스도 할 수 있어야 한다
• 리스코프 치환 원칙을 지키지 않으면 다형성 원칙가 깨진다
• 사전 조건이 자식 클래스에서 더 강해지면 안된다
  • 자식 클래스가 더 엄격하면 안된다

4. 인터페이스 분리 원칙

• interface segregation principle
• 클라이언트별로 세분화된 인터페이스를 만들어야 한다
• 인터페이스를 용도별로 나눠야 한다

5. 의존성 역전 원칙

• 상위 모듈은 하위 모듈에 의존하면 안된다
• dependency inversion principle
• 고수준인 서비스는 저수준인 레포지토리에 의존하면 안된다