컨벤션

• 클래스 이름 정할때 util은 쓰지말기
• 내용에 위화감
• 흠 내용만 맞다면 써도 될거같기도한대 테스트할때 주로 쓴다.

• 몰랐던사실
• get은 항상 인스턴스 돌려받음
• find는 리턴값이 옵셔널! 그래서 jpa 가 항상 옵셔널이었구나

• 동사를 반복하는거라 없는단어 exist 쓰자!

• 설명그대로, 참고해야 겠다.

• 대게 와닿는말 객체를 능동적이게 만들려면 객체에게 일을 시켜야한다.
• 왼쪽 코드 처럼
• TDA 물어보지말고 일을 시켜라

• 옵셔널 자주 사용하기.
• 옵셔널은 NULL 을 달 수 없다.

• MAP 남발하지않기

• 본인만 이해하는 코드가 될 수 있다.

• 만약 쓴다면 SCOPE 밖에 넘어가면 안됨

• 이해가 잘안되넹 !
  

• 보통 스타트는 포함하고 엔드는 제외한다.

• 1번 대게 애매하다 회사차원에서 정하고 가는게 나을 까?

객체 지향적인 코드 짜기 (1) : 객체의 종류, 행동

• 보통 평소에 코드할때도 이런식으로 짜는데

• 내용을 좀더 체우는 느낌.

• 사이드 이펙트를 줄이기위해 불변 객체를 만든다

• 멱등성이 보장된다.

• 생성자시 값을 항상 체크를 해줘야된다 , 흠 뭔가 불편하면서

• 이런 코드는 예전에 짜보긴했는데 실무에선?

• 위 코드에서 확장해서 생성자는 2가지역할만 값 주입 + 값 검증

• 1~3 번은 공통적
• 위키에보면 디비에 저장되는게 꼭 엔티티가 아니다 흠 ?

• 이 2개가 가장 중요할거 같고.

• 디미터법칙 위배
• 관리자가 내부구현을 너무 깊게 알고 있으니
• 캡슐화가 되어야된다.

• 이것도 좋은 코드가 아니다?

• 이런식으로.

• 흐음 잡힐듯 잡히지 않는다.

설계 (1) : 의존성이란 무엇인지? (DI vs DIP)

• 항상 외우는 대 까먹는거
• 깊이 이해하지 못해서일까?
• 100줄이상 기억해 두자.

• 관계없는 코드를 건드려야될때 확정이 닫혀 있다.
• 기능 확장을 위해 이파일 저파일 건드려야된다 수정에는 열려있다.
• 보통 추상화가 부족한 경우 발생

• 정말 기본적인 코드 오랜만에 본다.

• 유명한 정사각형예제 정사각형인대 5센치 높이가된다? 깨진다

• PUBLIC 메서드는 인터페이스라고도 하고 인터페이스 의 다른이름은 계약!

• setHight 높이를 정하는 계약 계약이 상속하면서 파기됨.

• 리스코프 치환 이 깨졌다.

• 이래서 상속은 신경쓸게 많아서 피하는게 맞다.

• 컴포지션!

• 인터페이스 분리 원칙

• 계약 경계 의미 기억

  

• 이 기능을 사용하려면 이 방법을 사용해라

• 인터페이스는 public 으로 선언된 메서드

• api도 인터페이스라 할수있따 어떤 기능을 사용하고싶으면 이걸 사용해!

• 결론적으로? 인터페이스를 적재적소에 잘 분리해라 .

• 합쳐지면? 다른 하나의 불필요한 메서드도 구현해야된다.
• 참 생각할게 많아지는 구문들이다.

• 의존성 역전의 원칙
• 구현체에 바로 의존할 떄 위험 ?

• 의존성 주입은 의존성을 약하게 만드는 테크닉
• 새롭게 뭔가 와닿는다

• 완저 다른 개념

• 의존 그래프
• 오른쪽처럼 만든다면? 이게 역전. (인터페이스를 두고 통신하게 한다)
• 화살표가 반대가 됬다? 의존성 방향이 반대 의존성 방향도 역전이 됨.
• 의존성 역전은 화살표의 방향을 반대로 바꾸는 테크닉

1. 의존성 역전은 상위 모듈과 하위모듈 모두 추상화 에 의존해야 된다.
2. 세부사항에 의존하면안돼고 추상화에 의존해야된다.
3. 추상화는 좋은 방법론이지만 비용이 증가한다 무조건 추상화가 좋은 의미는 아님.

설계 (2) : 의존성을 추상화 시키는 방식

• 코드를 잘모르는데 사용하면 내부에 감춰진 의존성 때문에

• 원인 분석 및 디버깅 시간이 길어짐.

  

• 변하는 값을 주입 받아라 아...
• 테스트도 쉬워짐
• 테스트가 쉽게 짜진다 ? 설계가 잘 짜여져 있다

그러나?

• 테스트가 어려워졌다 서비스 입장에선

• 최상위 까지 끌어와도 어려워 진다.

• 결론 적으로 의존성을 감추지 말자

• 여러 강의에서 들어왔던말 변하는 값을 추상화하라 영한님 강의에서도 듣던 말

• 런타임 의존성 컴파일 타임 의존성을 다르게 하자 ! 어렵네..

• 책임을 다른 객체에 넘겨라
• 요즘 짜는 코딩방식 인대 괜찮은 방법 같다
• 기계처럼 사용한 방식인대 이런 의미를 내포한걸 알고나니 더 잘 사용 할 수 있을거 같다.

• 대사가 참 좋다 .

• 이 부분은 다시들어도 좋을거 ㄱ같다.

• 명령 일을시키는 메서드
• 명령 메서드는 상태를 변경시키고 리턴값을 가지지 않는다.

• 질의 상태만 물어보는 메서드
• 상태를 변경하면 안됀다.

팁

• 500은 장애선언 인지한 500에러라면 캐치해서 메세지를 전달해 줘야된다.

• • 과한 들여쓰기도 메소드 분할의 요소