이야기를 나눠요
129만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
김영한의 실전 자바 - 중급 1편
스프링 강의를 듣기 위한 조건
안녕하세요 자바 초급에 이어서 자바 중급1편까지 완강한 수강생입니다우선 항상 양질의 강의를 올려주셔서 정말 감사드립니다!스프링을 수강하기에 앞서 자바편을 듣는 것인데, 아직 컬렉션, 제네릭, 람다 등이 학습이 되지 않아 스프링 강의는 미뤄두고 있습니다 (정확히 모르는 개념이 있으면 강의의 몰입도가 떨어지는 제 성격 때문이 큽니다) 여기서 고민이, 자바 중급2편이 곧 올라올 예정이고 여기서 컬렉션과 제네릭은 다뤄주신다고 말씀해 주셨는데 람다의 경우는 다른 책이나 강의를 통해 공부를 진행하고 스프링을 공부해야 할까요? 아니면 자바 중급까지만 잘 들어놓으면 바로 스프링으로 넘어가도 될까요? 의견 부탁드립니다! (자바 중급만 듣고 바로 스프링 넘어갈 경우에도 람다에 대해서는 아주 간단하게라도 공부는 할 예정입니다)
-
김영한의 실전 자바 - 중급 1편
코드에 익숙해 질려면 어떻게 해야 하나요?
안녕하세요. 코드에 익숙해 지는 방법이 궁금하여서 질문을 남깁니다. 저가 문제 풀이를 하다보면은 저가 하던 방식으로 하는경우에는 실패하는 경우가 많더라고요.그래서 공식 서포터즈님들이나 영한님의 코드를 배껴서라도 풀어야 하는데,문제는 시간이 흐르면 다시 저의 방식으로 하고 있다는것을 생각하게 됩니다.이런 경우 어떻게 해야 영한님의 코드나 공식 서포터즈님들의 코드에 최대한 빨리 익숙해 지는 방법은 무었인가요? 계속 따라 치는거 밖에 방법이 없는건가여?답변 부탁드립니다.
-
김영한의 실전 자바 - 기본편
엇 다음으로 못갈 것 같아요
접근제어자 문제와 풀이부터 갑자기 멍해지는데저만 그런가요?이러다 다음으로 못 갈 것 같은데...
-
김영한의 실전 자바 - 기본편
스프링 입문 강의로 넘어가기 전에 배워야 할 자바 개념
아직 중급 2 이상이 안 나온 상황에서 입문 - 기본 - 중급1을 들었다고 할 때, 이 개념은 스스로 학습하고 스프링 넘어갔으면 좋겠다 하시는 개념이 있으실까요???
-
나도코딩의 자바 기본편 - 풀코스 (20시간)
강의를 완강하고 부족한 부분때문에 고민입니다.
먼저 강의를 완강했으나 인터페이스 부분외 이런저런 부분에서 확실하게 배워지지않았습니다.반복해서 시청했는데도 잘 안되네요. 실전에서도 이렇게될까봐 걱정인데 이 강의의 내용을 안보고도 혹은 다른 자료를 참고하지 않을정도로 완벽하게 코드를 짤 수 있을정도로 다시 노력을 해야할지단순히 하다가 기억이 안나면 자료를 찾는 방향으로 나아갈지 조언을 부탁드립니다.
-
스프링 핵심 원리 - 기본편
이 구간에서 발견 할 수 있었던것 정리해봤어요! 혹시 어떤 것들이 있으셨나요?
[ 깨달음 ] - 역할과 구현의 효과를 체감=> 역할: BeanDefinition 정보 생성==> 구현: 무엇을 가지고 BeanDefinition 생성- BeanDefinition을 보면 Bean 생성 시 무엇을 정의 할 수 있는지 알 수 있다=> Scope, lazyInit 등등- factory method를 쓰는 annotation config는=> 빈 정보에 factoryBeanName = config name, factoryMethodName = 생성 method 이름 이 붙음 [ 생각과 느낌 ] - 코드 작성에도 교양이 있으면 낭만이 있다- 직접 BeanDefinition 을 만들다니 우와
-
스프링 핵심 원리 - 기본편
노트 정리해보았습니다! 혹시 필요하신 분 있으실까요?
[ 배움 ]- ApplicationContext는 BeanFactory의 자식이다=> ApplicationContext는 부가 기능 제공 - ApplicationContext 부가 기능=> 여러 인터페이스의 묶음==> 메시지 소스:===> 메시지의 국제화 등==> 환경 변수: ===> 환경 변수 사용 등==> 이벤트:===> 이벤트 발행 등==> 리소스:===> 리소스 파일 열기 등 - 스프링 컨테이너=> 실제 클래스가 아니라 개념이다 [ 생각과 느낌 ]- 인터페이스가 많이 분리된 경우를 많이 봤는데=> 그 이유가 역할의 분리에서 나온 것이었구나 - 환경 변수 어떤 기준으로 쓸까?=> 환경에 따라 값을 다르게 하기 위해 사용==> 즉, 이 값을 환경 변수로 둬야 할까의 기준은 어떤 환경에 쓰는가에 달라지냐 여부===> 예: 환경 별 달라지는 사용 데이터베이스 - 여러 환경을 두려면=> 테스트 등 을 위해 따로 DB 등 서버를 띄워야 하고==> 그만큼 많은 하드웨어 리소스도 많이 필요하겠구나
-
스프링 핵심 원리 - 기본편
노트 정리 해보았어요! 혹시 어떤 내용이 기억에 남으시나요?
[배움]- 부모 타입으로 조회=> 자식 타입들도 끌려 온다- 모든 자바 객체의 최고 부모=> Object [생각과 느낌]- 코드 내에서도 역활과 구현을 확실히 나타내 주도록 하자=> (부모 class) return (구체 class)
-
스프링 핵심 원리 - 기본편
정리해보았습니다! 이상할까요?
[생각과 느낌]- Bean에게는 Name이 있다- Bean에게는 Type이 있다- 같은 Type의 Bean은 Name으로 구분한다
-
스프링 핵심 원리 - 기본편
노트 정리 해보았습니다. 가장 중요한 핵심은 어디일까요?
[ 배움 ] - getClass() 하면 classpath가 출력됨- isInstanceOf 로 구체 객체 확인- 타입으로만 조회 가능- assertThrows 로 예외가 던져지는지 테스트=> 주로 실패에 대한 테스트 시 사용 [ 깨달음 ] - 테스트는 실패 하였을 때 에 대한 case도 필요하다=> 예: 인증 실패에 대한 response는 어떻게 오는지 확인 [ 생각과 느낌 ] - java는 다양한 Exception 에 대한 정의를 해두는 방식으로 현재 어떤 오류가 나는지 사용자에게 알려주고 있다.=> Exception 명을 정 할 때 해당 오류에 대한 소개가 나와야 한다.
-
스프링 핵심 원리 - 기본편
노트 정리해보았어요! 추가 할 내용 있을까요?
[Spring 적용]- @Bean=> method에 적어줌==> 컨테이너에 등록됨- ApplicatonContext 생성=> 컨테이너 생성==> new AnnotationConfig...(AppConfig.class);- 컨테이너 통해서 찾아옴=> bean을 가져옴==> name: method 이름==> type: 반환 type- 실행 시 등록 됨=> @Bean 해둔 것 singleton instance 생성- 스프링의 어마어마한 장점:=> 컨테이너가 관리해서 어마어마 해진다 [생각 및 느낌]- 좋은 개발자는 당연한 것에 의구심을 품는 개발자이다- 스프링의 개발 시초는 DIP 와 OCP를 지키기 위해서 생긴거구나
-
스프링 핵심 원리 - 기본편
노트 정리해보았어요! 추가 할 내용 있을까요?
[스프링 컨테이너 생성]- 컨테이너 생성 과정=> ApplicationContext는 인터페이스 이다==> AnnotationConfig (annotation 기반)- 요새 XML 잘 안씀=> Boot 에서 java config 편함- AppConfig=> 우리가 작성한 AppConfig가 컨테이너에 대한 명세 였다- 주의: 빈 이름은 항상 다른 이름을 부여 해야 한다=> 실무에서는 무조건 단순하고 명확하게 개발 해야 한다- 스프링 빈 의존관계 설정 - 준비=> MemberServiceImpl은 MemberRepository를 의존함==> 이를 생성자로 주입 받음 (의존관계 주입 DI)===> 스프링에서 알아서 필요한 것들을 순차적으로 생성해 넣어준다- 스프링 빈 의존관계 설정 - 완료=> 의존관계 주입도 같이 처리 된다==> MemoryMemberRepository는 bean으로 동록 하지 않았지만 주입에는 사용 되었다[생각과 느낌]재미있다
-
스프링 핵심 원리 - 기본편
노트 정리해보았어요. 어떤가요?
< IoC >- 인터페이스를 사용하는 입장에서는 어떤 것을 쓸지 제어 할 수 없다=> 외부에서 관리함예: AppConfig vs. OrderServiceImpl< 깨달음 >- 라이브러리와 프레임워크 차이=> 라이브러리: 내가 만든 체계에서 직접 호출한다=> 프레임워크: 내가 만든 것을 알아서 호출한다< DI >- 정적인 클래스 의존 관계=> import만 보고 쉽게 파악 가능=> 세부 기능이 바뀌어도 바뀌면 안된다- 동적인 객체 의존 관계=> 실제 실행 봐야 알 수 있음=> 세부 기능에 따라 바뀜- DI:-- 인스턴스 생성한다-- 참조하는 값에 넣어준다< 깨달음 >- 의존 관계는 두가지 이다=> 정적: 클래스 의존 관계=> 동적: 객체 의존 관계- 툴로 분석 가능=> Intellij: diagram - show diagram- 설계 할 때는-- 인터페이스 설계 그리고-- 객체 설계 까지 두루 한다< IoC, DI 컨테이너 >- 뜻: 객체를 생성하고 연결해주는 역할을 하는 아이- 예: AppConfig, 스프링, Assembler, Object factory< 깨달음 >- 잘 만든 코드는 코드 블럭을 가지고 조립하는 것이다
-
스프링 핵심 원리 - 기본편
저처럼 소름 돋으셨나요?
[와우 포인트]고칠 때 차이- 구성 영역, 사용 영역 중 구성 영역만 바꾸면 된다-- 구성 영역: 대신, 구성 영역이 세세히 다 알아야 한다-- 사용 영역: 더 이상 손댈 필요가 없다.--- => 스프링 코드 짤 때 AppConfig 코드 외 아무 것도 손대지 않아도 된다- 개발자가 하는 일=> 최초에 사용 영역만 인터페이스만 사용해서 잘 만드는 것- OCP 지켜짐=> 구체화를 바꿔도 클라이언트 코드 바꾸지 않아도 된다==> 인터페이스를 사용하는 입장의 코드는 더 이상 인터페이스 구현체가 바뀌어도 바꾸지 않아도 된다- DIP 지켜짐=> 추상화만 의존==> 구현은 모름[팁]- Ctrl + R 하면 기존 실행된 것 실행됨
-
스프링 핵심 원리 - 기본편
리펙토링이 무엇인지 약간은 더 알것 같아요!
[리펙토링]- 역할들을 드러나게 하는 것 중요=> 인터페이스 반환 하는 부분이 안보임- 중복 제거=> 같은 구현 클래스를 여러 군데서 넣어주던 중복 제거[깨달음 점]- 리펙토링에서 것은 중복 제거하고 그런 것들을 하던 이유가 명확해졌다=> 역할과 구현 등 관계를 확인 하고 구조를 편하게 확인 하기 위해서 였다==> 앱 컨피그만 보아도 이 프로그램이 뭘 쓰고 있고 어떻게 돌아가는지 짐작이 간다 - intellij extract method 쓰면 refactor 쉽다
-
스프링 핵심 원리 - 기본편
노트 정리해보았어요. 혹시 문제 있으시면 알려주셔요!
[문제점]- 클라이언트 (OrderServiceImpl) 고쳐야함=> OCP를 위반함- OrderServiceImpl이 DiscountPolicy 뿐만 아니라 구현 클래스 FixDiscountPolicy에도 의존하고 있다=> DIP를 위반함[해결 방법]- 1. DIP 해결 방법: 인터페이스만 의존 하게 한다-- => 코드 내에서도 객체 할당 X- 객체 할당 X 에서 생기는 NullPointer Exception 문제 해결 방법:-- => 대신 주입할 얘가 필요하다[강의 느낀점]- 실제 의존 관계 다이어그램에서 화살표를 보니 의존 관계가 확 와닿는다
-
스프링 핵심 원리 - 기본편
AppConfig의 역할이 너무 광범위 하지는 않을까요?
질문:- AppConfig의 역할이 너무 광범위 하지는 않을까요?- member service impl 에 주입하는 구체 클래스는 동적으로 runtime 시 정하는 방법도 있을까요? 깨달음:- final 변수를 만들면 기본 할당 또는 생성자를 통해서 할당 되어야 함- Command + E: 과거 했던 파일들 다보는 방법=> vim: ls[관심사의 분리]- 공연=> 역할의 구현을 누가 정하는가: 기획자- 기획자=> AppConfig[AppConfig]- 역할=> 구현 생성=> 역할에 설정=> 기획자로서 역할을 갖는 ROLE에 맞는 구현 ACTOR를 배정함- 역할에 설정 방법:-- 생성자 주입[Injection]- Injection=> 역할에 구체화를 부여- DIP를 지킨다=> 구현 클래스를 몰라도 된다.==> 역할인 인터페이스만 의존한다.- OCP를 지킨다=> (closed) 역할을 사용하는 클라이언트가 구현 클래스를 의지 않해서 구현이 바뀔 때마다 수정할 필요가 없다=> (open) 클라이언트 수정 없이 언제든지 추가 구현 클래스를 만들어서 클라이언트에 적용 할 수 있다- Dependency Injection=> 의존 관계 주입==> 클라이언트가 의존하는 것을 클라이언트 외부에서 주입
-
스프링 핵심 원리 - 기본편
순진한 개발자 여기 있어요
아래와 같이 정리해보았습니다. 혹시 더 필요한 부분이 있을까요? [agile manifesto]느낀점:- 기준을 제시해주어서 좋다- 개발 할 때 고려 할 기준:-- 개인의 생각을 중요시하고 상호 교류가 잘 일어나는 것이 중요-- 문서화 할 시간에 더 나은 제품-- 고객과 협력에 집중하고 계약 협상에 대한 생각은 나중에-- 필요에 따른 변화를 우선. 계획에 집착하기보다[test]깨달은점:- test 코드 파일 작성 쉽게 가능하다느낀점:- 아직 SOLID가 안되는 문제점은 말씀해주시지 않았다
-
스프링 핵심 원리 - 기본편
MemberRepository 공유가 되나요?
질문:- Member Repository가 OrderService와 MemberService 사이에 어떻게 공유 될 수 있을지=> 내 생각: final이 영향을 준다?=> 실제 답: repository 내 store가 static으로 선언되어서 그렇다느낀점:- 단위테스트가 중요하다=> 단위테스트로 점점 쌓아 점점 더 크게 테스트하는 것이다- 이렇게 역할과 구현을 나눠서 개발만 한 것도 잘한 것이다=> 실무에서 이렇게만 해주는 것을 1차 단계로 해보자
-
스프링 핵심 원리 - 기본편
discountPrice가 최종 할인된 가격 맞을까요?
[수업 노트 공유] 깨달음:1. 단일 설계 원칙을 잘 지켰다:- "Order 생성 시 DiscountPolicy는 나는 모르겠고~ 할 수 있다. 질문:1. discountPrice가 최종 할인된 가격 맞을까요?- discount 함수는 얼마나 할인 되는지를 알려주는 함수 아닌가요?