학습계획

---

• 객체지향 프로그래밍 정의 및 구성요소
• DI, AOP, PSA
• REST API 기본 디자인 원칙

Today I Learned

---

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

프로그램을 명령어로 보는 시각에서 벗어나 독립된 단위인 객체들의 모임의 새로운 패러다임

객체지향은 클래스, 객체, 메세지로 구성되어 객체 들은 메세지를 주고 받고 데이터를 처리 할 수 있다.

구성요소

• 클래스
  • 같은 종류의 집단에 속하는 속성, 행위를 정의한것
  • 객체지향 프로그램의 기본적인 사용자 정의 데이터형
  • 다른 클래스, 외부요소와는 독립적으로 디자인 해야한다.
• 객체
  • 클래스의 인스턴스(실제 메모리상에 할당한것)
  • 객체는 자신 고유의 속성을 가지며 클래스에서 정의한 행위를 수행할 수 있다.
  • 객체에 정의된 행위에 대한 정의를 공유함으로써 메모리를 경제적으로 사용한다.
• 메서드, 메세지
  • 클래스로부터 생성된 객체를 사용하는 방법은 객체에 명령을 내리는 메세지
  • 객체의 속성을 조작하는데 사용
  • 객체간의 통신은 메세지를 통해 이루어진다.

장점

• 객체지향프로그래밍은 프로그램을 유연하고 변경이 쉽게 만들기 때문에 소프트웨어 개발과 보수를 간편하게 한다.
• 직관적인 코드 분석 가능

단점

• 지나친 객체화는 현실세계를 제대로 반영하지 못한다는 이야기도 있음

특징

추상화

불필요한 정보는 숨기고 공통되고 중요한 기능만 모으는 모델링

추상화된 데이터의 속성과 기능(메서드)에 대해 접근 제어를 통해 데이터를 은닉할 수 있다.

상속

상속은 새로운 클래스가 기존의 클래스의 자료와 연산을 이용할 수 있는 기능

상속을 통해 상속 받은 클래스는 상위 클래스와 종속관계를 유지하며 하위 클래스는 확장할 수 있다. 이로인해 객체를 조직, 분류화 할 수 있다.

다형성

하나의 요소에 여러 개념(타입의 공유)을 넣어서 오버라이딩, 오버로딩을 의미하기도 한다.

동적 바인딩

다형성을 이루게 되는 개념이며, Runtime 시 타입이 결정되는것을 뜻한다.

---

DI-의존성 주입

• 스프링의 @Autowired는 type 기준으로 객체를 매칭한다. 만약 동일한 인터페이스를 구현한 클래스가 여러개 있다면 bean의 id를 확인 후 매칭한다.
• @Autowired : 스프링 어노테이션 / @Resource : 자바 표준 어노테이션
  • @Autowired
    • 빈의 매칭 우선순위 : type > id
    • name으로 강제하기

      @Autowired
      @Qualifier(name = "")

  • @Resource
    • 빈의 매칭 우선순위 : id > type
    • name으로 강제하기

      @Resource(name = "")

→ 저자는 자동주입 역할로 @Resource를 쓰는것이 더 어울린다고 한다. 또한 스프링 프레임워크로 교체되는 경우를 대비하면 자바 표준인 @Resource를 쓰는것이 유리하다고 한다.

→ @Autowired를 사용한다면 추가적인 @Primary같은 기능도 제공하는 이점도 있다.

• 스프링은 xml로 빈의 등록을 하는 방식을 사용하는데 이는 설정 파일을 쓰고 변경해도 재배포 , 재 컴파일 할 필요가 없이 프로그램 실행 결과를 변경할 수 있기 때문
• new 클래스 뿐만 아니라 변수의 할당도 외부에 의존하므로 의존관계가 된다. 즉, DI는 외부에있는 의존대상을 주입하는것을 말한다.

AOP - 관심사의 분리(로직주입)

코드 = 핵심관심사 + 횡단 관심사

Runtime시 횡단 관심사가 주입된다.

AOP는 인터페이스 기반으로 작동하며, 프록시 패턴을 이용해 횡단 관심사를 핵심 관심사에 주입하는것

• Pointcut 횡단 괌심사를 적용할 타겟 메서드 선택 지시자
  
• Jointpoint
  • AOP는 인터페이스로 작동 → 인터페이스는 추상메서드의집합 → AOP는 메서드만 적용 가능
  • jointpoint 즉,Aspect 가능지점
  • jointpoint를 이용하면 실행 시점에 호출된 메서드가 무엇인지, 소유한 객체가 무엇인지 알 수 있다.

PSA - (Portable Service Abstraction) 일관성있는 서비스 추상화

어댑터 패턴을 적용해 같은일을 하는 다수의 기술을 공통의 인터페이스로 제어할 수 있게 만든것

예) ORM, 캐시, 트랜잭션

---

REST API

기본 디자인 원칙

1. 리소스 중심 디자인

   1. URI는 명사를 기바능로 해야한다.

2. 리소스 마다 해당 리소스를 고유하게 식별하는 URI(식별자)가 있다.

   1. 컬렉션/항목/컬렉션 보다 복잡하게 리소스를 설정하는것은 조지 않다.

   https://adventure-works.com/orders/1

3. 교환 형식으로는 JSON 사용

4. 균일한 인터페이스를 사용하는데 해당 작업으로는 GET, POST, PUT, PATCH, DELETE

   1. PUT
      1. 지정된 URI에 리소스를 만들거나 대체
      2. request body의 본문에 만들거나 업데이트할 내용을 지정한다.
      3. 서버에 존재하는 리소스를 통으로 변경되는 작업을 하므로 PUT 요청은 멱등성이 유지된다.
   2. PATCH
      1. 리소스의 부분 업데이트
      2. request body에 본문에 업데이트할 내용 지정한다.
      3. 항상 멱등성을 유지한다고 말할 수 없다.