진행방식
- 먼저
키워드를 설정을 합니다.
- 해당 키워드 별로 자유롭게 이야기를 하면서 내용을 채워가고 그 과정에서 수정, 추가, 삭제
- 모든 키워드를 작성한 뒤에 다시 훑어보면서 검증?
키워드
- Entity / Value Object (+ DTO, DAO 등등의 용어?)
- Entity : 식별자를 가지고 있는 객체, 시간에 따라 변경이 발생한다.
- Value Object : 식별자를 가지지 않는 객체, 값이 변경되지 않는다.
- Data Transfer Object : 계층간 통신을 위한 데이터 객체
- Data Access Object : 데이터베이스의 데이터에 접근하기 위한 객체 Database를 위한 로직과 비즈니스 로직을 구분하기 위해서
- Dependency (+ Injection)
- 의존이란? 기능 구현을 위한 다른 구성 요소들을 사용하는 것
- 이때 사용이란 객체 생성, 메소드 호출, 데이터 사용 등
- 의존은 하면 변경이 전파될 가능성을 의미!
- ex) 호출하는 메소드의 파라미터가 변경, 발생하는 예외타입 변경
- 단단한 결합도와 느슨한 결합도
- 단단한 결합도 : Compile 시점에 의존성 생성
- 느슨한 결합도 : Runtile 시점에 의존성 생성
- 응집도와 결합도
- 응집도(Cohesion)
- 모듈에 포함된 내부 요소들이 연간돼 있는 정도
- 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도
- 변경의 많다면 응집도가 높은 것!
- 결합도(Coupling)
- 다른 모듈에 대해서 얼마나 많은 지식을 갖고 있는 지를 나타냄
- 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도
- 결합도가 높을수록 변경해야하는 모듈의 수가 늘어나 변경이 어려워 진다.
- 좋은 설계는 높은 응집도와 낮은 결합도를 가져야 한다.
- 의존
- 연관
- https://www.youtube.com/watch?v=dJ5C4qRqAgA&list=LL&index=24&t=1359s
- DI도 해야되지 않나요?
- DI는 생성자를 권장하잖아요.
도진
약간 저는 의존한다?의 개념이 그냥 쓰기만 하면 다 의존인가? 싶던데 맞죠?
그러면 약간 Utility? 같은 Static class들은 그냥 바로 쓰잖아요. 그런 것도 의존성을 가지는 거긴 하죠? 맞나요?ㅋㅋ
- IoC(Inversion Of Control)
- 컨테이너도 상위 개념에 포함되는 걸로 볼께요
- 도진 : IoC를 구현하기 위한 전략 중 하나로 DI가 있다고 생각했어요
- 애플리케이션 코드가 프레임워크가 짜놓은 틀에서 수동적으로 동작
- The Hollywoord Principle
- Context는 객체의 생성, 연관 관계를 담당
- Context는 IoC가 일어나는 공간으로 IoC Container라고 한다.
- Spring에서는 Application Context를 이용한다.
- IoC를 구현하는 방법
- 전략패턴 / 서비스 로케이터 패턴/ 팩토리 패턴/ 의존성 주입 등
- IoC를 하는 이유가 의존성을 낮추기 위해서 맞죠? 역전시켜서
- 저는 왜 써야 하는 지 아직 와닿지가 않아서 ㅋㅋ
- 맞는것 같습니다!
- ApplicationContext
- 도진
- Bean객체를 관리하는 객체!
- Bean 객체: Application Context에 의해 관리되는 객체
- JVM에 많은 객체가 등록되고 이들 중 ApplicationContext에서 관리되는 객체를 구분하기 위해서 Bean이라는 용어가 만들어짐.
- Bean anontation을 이용해서 선언
- Configuration Meta
- 실제로 ApplicationContext는 만들어야 할 빈 객체 정보를 config를 통해서 받음.
- 이때 config metadata를 xml과 java로 작성할 수 있다
- xml 작성 ⇒ GenericXmlApplicationContext 구현체 사용
- java작성 ⇒ AnnotationConfigApplicationContext 구현체 사용
- java로 작성되는 게 주류를 이룬다.
- Components Scan
- 도진
- 위에서 말했던 빈 객체들에 대해서 설정 클래스에 따로 작성하지 않아도 알아서 찾아서 등록해주는 기능!(개발자의 편의성과 생산성 증대)
- Stereotype Annotation을 이용해서 Scan 대상 객체를 표기
- 불필요한 객체들은 excloude filters를 통해서 제거 가능
- Bean Scope
- Bean Life Cycle
- Enviroment Profile
- 모의객체
- 단위 테스트시, 오로지 하나의 단위에 대한 테스트에 충실하기 위해 외부의존성을 배제하는데 사용할 수 있다.
- 예를들어 repository에 의존하는 service클래스의 메서드를 단위 테스트 하는 경우, repository를 모의 객체로 만들어 repository에 대한 의존을 해소하는 방식
- Garbage Collector
- reference counting
- 객체에 대한 참조가 0이 되면 메모리 공간을 수거한다.
- 순환 참조 문제 발생할 수 있다.
- mark and sweep
- root가 참조하는 객체로부터 다른 객체들을 탐색해 내려가며 마크하고, 마크 되지 않은 객체들을sweep한다.
- 순환 참조 문제를 해결하지만, 실행 시점을 지정해야 한다.
- mark and sweep의 gc실행시점
- minor gc
- eden 영역이 꽉차면 실행, 살아남은 객체는 survival 0영역으로 이동
- survival 0영역에서 살아남은 객체들은 survival 1영역으로 이동
- age bit가 일정수준 이상 넘어가면 old generation으로 이동
- major gc
- old generation이 가득차면 실행
키워드 끝 - 작성하실 수 있는 것만 하시면 됩니다!
과제하면서 받은 피드백
- 커밋 컨벤션
- gitmoji plus
- 다들 커밋 컨벤션은 쓰시나요??
- 한 줄 쓰기
- 객체 지향 생활 체조 원칙
- 롬북관련 @AllArgsConstructor 사용 지양, @RequiredArgsConstructor를 사용 하는 것이 좋다.
- 변수명 줄이지 않기
- repository save return 하느냐 ? server save는 void해도 된다. 네 맞아요!
- 테스트 코드도 필요하다고 레이님이 이야기했던 거 같아요.
- 서비스 테스트에서는 저장하는 역할이 자기가 가진 역할이 아니라서! 전달만 하면 끝
- 혹시 주석을 따로 다시는 분 있나요?
- 주석 다는 게 좋은 거죠? 맞나요? 안 달아도 이해되는 게 좋은 건가요?
- 흑구님 왈: 안 달아도 이해되는 게 최고지만, 알고리즘적인 코드는 달아주는 게 낫다. 남들이 보기에 이해하기 어렵다고 생각하면 주석을 달아주는 게 좋다. (다다익선은 아니다.)
- 이거 주석 달 때, 줄마다 다는 스타일이 낫나요? 아니면 그냥 모아서 한번에? 너무 디테일인가.... 어떻게 생각하시나요?
- 사용하는 기준은?(과정을 설명 - 한번에, 줄마다 필요한 거(?)는 줄마다?
- 인풋 아웃풋만 잘 설명한다.
- 내가 보고 싶은 걸 남긴다....
- 다들 의견 감사합니다.ㅋㅋㅋㅋㅋㅋㅋㅋㅋ ㅇㅈ.... 그리고 6개월 전 코드면 후진코드...
- zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz머선일이고.... 저는 알고리즘은 오히려 코드가 잘 안 바뀌더라구요... 실제 서비스 구현한 코드가 더 개선점이 많았던 거 같아요
- TODO: FIX: 이런 키워드 주석 쓰시나요??
- 이렇게 주석 남기면 따로 하이라이팅 되어서 표기되는 그런..dk 다들 모르셨군요.... 이거하면 자동으로 기록남아서 찾아갈 수 있어요 바로 그 위치로... ㅋㅋㅋㅋ 근데 뭔가 개발잘하는 거라기 보다는 생산성??? 을 올릴 수 있는 그런 것들에 관심이 좀 있는 거 같아요.
- 이것도 나름 좋은 거 같아서 깃헙 보실 때....
- 그리고 깃허브 .com을 .dev로 바꾸면 vscode web editor로 바로 열 수 있어요... 나름 편리한?
- 그리고 저는 제가 자주 쓰는 단축키는 최대한 손 편한 키로 다 바꿔서 쓰는 거 같아요. 특히 리팩토링 관련??
- 이래봐야 코드 못 짜면 의미 없... ㅋㅋ 10시간 짜도 잘 짜시는 분 1시간만 못한 ㅠㅋㅋㅋ교수님 아니고 도진님이요...허헣.. 또 코드리뷰때 나온거 없나요? 긑인가요?
- by, Ph.d 도진 유 :
