1115 - 1124

# 1115 - 1124

# 1115 - 상속과 컴포지션

# 상속과 composite(조합) 이란?

# 상속

IS-A관계로 정의될 수 있으며, 부모클래스를 '확장'하는 개념이다.
상속을 받은 자식클래스는, 부모클래스의 변수와 메소드에 접근이 가능하고, 메소드를 재정의 할 수 있다. (생성자, static블록은 상속되지 않으며, private 선언자는 접근이 불가능하고, final선언자는 재정의가 불가능하다.)

# 컴포지션(조합)

HAS-A 관계로 정의될 수 있으며, 기존 클래스가 새로운 클래스의 구성요소가 되는 것이다.
기존에 존재하는 객체를 멤버변수로 이용, 새로운 객체를 구현하는 방법

# 상속의 단점

캡슐화를 위반한다.
- 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있기 때문이다.
- 상위 클래스의 내부 구현이 달라지면 하위 클래스를 고쳐야할 수 있다.
설계가 유연하지 못하다.
- 컴파일 시점에 객체의 Type이 정해지기 때문이다.
다중상속
- 자바는 다중상속이 불가능하다.
- 따라서 다른 클래스를 상속받고있다면 추가적으로 상속을 받을 수 없다.

# 1116 - 왜 JPA의 Entity는 기본 생성자를 가져야 하는가?

정확히 말하자면 Entity는 반드시 파라미터가 없는 생성자가 있어야 하고, 이것은 public 또는 protected이어야 한다.

# setter의 제한

Entity의 모든 필드에 public setter 메소드를 생성하는 것은 객체의 값의 변경을 열어두기 때문에 일관성을 보장할 수 없다. 또한 단순히 setter이기 때분에 그 의도를 쉽게 파악할 수 없다. setter 메소드를 제공하는 것 보단 확실한 비즈니스가 드러나는 메소드를 제공하는 것이 더 욱 바람직하다.

# Java Reflection API

Java Reflection API란?
구체적인 클래스 타입을 알지 못해도 그 클래스의 메소드, 타입, 변수들에 접근할 수 있도록 해주는 Java API

이러한 Java Reflection을 활용하면 컴파일 시점이 아닌 런타임 시점에 동적으로 클래스를 객체화하여 분석 및 추출할 수 있는 프로그래밍 기법이다.

자세한 내용은 woowacourse.github.io/javable/post/2020-07-16-reflection-api/ 을 참고

JPA는 DB값을 객체 필드에 주입할 때 기본 생성자로 객체를 생성한 후 이러한 Reflection을 사용하여 값을 매핑하기 때문이다.

# Proxy 객체

JPA는 매핑한 Entity를 조회할 때 두 가지 전략을 사용한다. 조회 시점에 함께 가져오는 EAGER와 매핑한 Entity를 사용할 때 조회하는 LAZY가 있다.

이러한 LAZY, 지연로딩을 사용할 경우에는 매핑한 Entity의 대상 객체에 proxy 객체가 들어있다.

정리
정리하면 JPA의 구현체인 hibernate에서 제공하는 다양한 기능을 활용하기 위해서는 public이나 protected 기본 생성자가 필요하다. private로 생성자를 만들게 되면 이러한 기능들을 사용하는데 제약이 되기 때문이다. 다만 안정성 측면에서 좀더 작은 scope를 가진 protected 기본 생성자를 주로 사용한다.

# 1117 - 좋은 커밋 메세지 작성하기위한 규칙

글작성전에 정답은 없으며 협업이나 일관성있게 관리하기 위해 컨벤션을 적용한다.

AngularJS Git Commit Message Conventions 참고하여 작성

# 커밋 메시지의 7가지 규칙

제목과 본문을 빈 행으로 구분한다.
제목을 50글자 내로 제한한다.
제목 첫 글자는 대문자로 작성한다.
제목 끝에 마침표 넣지 않기
제목은 명령문으로 사용하며 과거형을 사용하지 않는다.
본문의 각 행은 72글자 내로 제한한다.
어떻게 보다는 무엇과 왜를 설명한다.

# 커밋 메시지 구조

헤더는 필수이며, 범위(scope), 본문(body), 바닥글(footer)은 선택사항이다.

<type>(<scope>): <subject>          -- 헤더
<BLANK LINE>
<body>                              -- 본문
<BLANK LINE>
<footer>                            -- 바닥글

은 해당 커밋의 성격을 나타내며 아래 중 하나여야 한다.

feat : 새로운 기능에 대한 커밋
fix : 버그 수정에 대한 커밋
build : 빌드 관ㄹ녀 파일 수정에 대한 커밋
chore : 그 외 자잘한 수정에 대한 커밋
ci : CI관련 설정 수정에 대한 커밋
docs : 문서 수정에 대한 커밋
style : 코드 스타일 혹은 포맷 등에 관한 커밋
refactor : 코드 리팩토링에 대한 커밋
test : 테스트 코드 수정에 대한 커밋

1108 - 1114 1122 - 1128