inflearn logo
강의

강의
N
챌린지

챌린지
멘토링

멘토링
N
클립

클립
로드맵

로드맵
지식공유

이야기를 나눠요

173만명의 커뮤니티!! 함께 토론해봐요.

엇 다음으로 못갈 것 같아요

김영한의 실전 자바 - 기본편

접근제어자 문제와 풀이부터 갑자기 멍해지는데 저만 그런가요? 이러다 다음으로 못 갈 것 같은데...

  • java
  • 객체지향
예롬 댓글 1 좋아요 0 조회수 314

스프링 입문 강의로 넘어가기 전에 배워야 할 자바 개념

김영한의 실전 자바 - 기본편

아직 중급 2 이상이 안 나온 상황에서 입문 - 기본 - 중급1을 들었다고 할 때, 이 개념은 스스로 학습하고 스프링 넘어갔으면 좋겠다 하시는 개념이 있으실까요???

  • java
  • 객체지향
김철준 댓글 1 좋아요 0 조회수 407

강의를 완강하고 부족한 부분때문에 고민입니다.

나도코딩의 자바 기본편 - 풀코스 (20시간)

먼저 강의를 완강했으나 인터페이스 부분외 이런저런 부분에서 확실하게 배워지지않았습니다. 반복해서 시청했는데도 잘 안되네요. 실전에서도 이렇게될까봐 걱정인데 이 강의의 내용을 안보고도 혹은 다른 자료를 참고하지 않을정도로 완벽하게 코드를 짤 수 있을정도로 다시 노력을 해야할지 단순히 하다가 기억이 안나면 자료를 찾는 방향으로 나아갈지 조언을 부탁드립니다.

  • java
  • 객체지향
멜리사J 댓글 1 좋아요 0 조회수 288

이 구간에서 발견 할 수 있었던것 정리해봤어요! 혹시 어떤 것들이 있으셨나요?

스프링 핵심 원리 - 기본편

[ 깨달음 ] - 역할과 구현의 효과를 체감 => 역할: BeanDefinition 정보 생성 ==> 구현: 무엇을 가지고 BeanDefinition 생성 - BeanDefinition을 보면 Bean 생성 시 무엇을 정의 할 수 있는지 알 수 있다 => Scope, lazyInit 등등 - factory method를 쓰는 annotation config는 => 빈 정보에 factoryBeanName = config name, factoryMethodName = 생성 method 이름 이 붙음 [ 생각과 느낌 ] - 코드 작성에도 교양이 있으면 낭만이 있다 - 직접 BeanDefinition 을 만들다니 우와

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 277

노트 정리해보았습니다! 혹시 필요하신 분 있으실까요?

스프링 핵심 원리 - 기본편

[ 배움 ] - ApplicationContext는 BeanFactory의 자식이다 => ApplicationContext는 부가 기능 제공 - ApplicationContext 부가 기능 => 여러 인터페이스의 묶음 ==> 메시지 소스: ===> 메시지의 국제화 등 ==> 환경 변수: ===> 환경 변수 사용 등 ==> 이벤트: ===> 이벤트 발행 등 ==> 리소스: ===> 리소스 파일 열기 등 - 스프링 컨테이너 => 실제 클래스가 아니라 개념이다 [ 생각과 느낌 ] - 인터페이스가 많이 분리된 경우를 많이 봤는데 => 그 이유가 역할의 분리에서 나온 것이었구나 - 환경 변수 어떤 기준으로 쓸까? => 환경에 따라 값을 다르게 하기 위해 사용 ==> 즉, 이 값을 환경 변수로 둬야 할까의 기준은 어떤 환경에 쓰는가에 달라지냐 여부 ===> 예: 환경 별 달라지는 사용 데이터베이스 - 여러 환경을 두려면 => 테스트 등 을 위해 따로 DB 등 서버를 띄워야 하고 ==> 그만큼 많은 하드웨어 리소스도 많이 필요하겠구나

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 288

노트 정리 해보았어요! 혹시 어떤 내용이 기억에 남으시나요?

스프링 핵심 원리 - 기본편

[배움] - 부모 타입으로 조회 => 자식 타입들도 끌려 온다 - 모든 자바 객체의 최고 부모 => Object [생각과 느낌] - 코드 내에서도 역활과 구현을 확실히 나타내 주도록 하자 => (부모 class) return (구체 class)

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 274

정리해보았습니다! 이상할까요?

스프링 핵심 원리 - 기본편

[생각과 느낌] - Bean에게는 Name이 있다 - Bean에게는 Type이 있다 - 같은 Type의 Bean은 Name으로 구분한다

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 228

노트 정리 해보았습니다. 가장 중요한 핵심은 어디일까요?

스프링 핵심 원리 - 기본편

[ 배움 ] - getClass() 하면 classpath가 출력됨 - isInstanceOf 로 구체 객체 확인 - 타입으로만 조회 가능 - assertThrows 로 예외가 던져지는지 테스트 => 주로 실패에 대한 테스트 시 사용 [ 깨달음 ] - 테스트는 실패 하였을 때 에 대한 case도 필요하다 => 예: 인증 실패에 대한 response는 어떻게 오는지 확인 [ 생각과 느낌 ] - java는 다양한 Exception 에 대한 정의를 해두는 방식으로 현재 어떤 오류가 나는지 사용자에게 알려주고 있다. => Exception 명을 정 할 때 해당 오류에 대한 소개가 나와야 한다.

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 444

노트 정리해보았어요! 추가 할 내용 있을까요?

스프링 핵심 원리 - 기본편

[Spring 적용] - @Bean => method에 적어줌 ==> 컨테이너에 등록됨 - ApplicatonContext 생성 => 컨테이너 생성 ==> new AnnotationConfig...(AppConfig.class); - 컨테이너 통해서 찾아옴 => bean을 가져옴 ==> name: method 이름 ==> type: 반환 type - 실행 시 등록 됨 => @Bean 해둔 것 singleton instance 생성 - 스프링의 어마어마한 장점: => 컨테이너가 관리해서 어마어마 해진다 [생각 및 느낌] - 좋은 개발자는 당연한 것에 의구심을 품는 개발자이다 - 스프링의 개발 시초는 DIP 와 OCP를 지키기 위해서 생긴거구나

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 294

노트 정리해보았어요! 추가 할 내용 있을까요?

스프링 핵심 원리 - 기본편

[스프링 컨테이너 생성] - 컨테이너 생성 과정 => ApplicationContext는 인터페이스 이다 ==> AnnotationConfig (annotation 기반) - 요새 XML 잘 안씀 => Boot 에서 java config 편함 - AppConfig => 우리가 작성한 AppConfig가 컨테이너에 대한 명세 였다 - 주의: 빈 이름은 항상 다른 이름을 부여 해야 한다 => 실무에서는 무조건 단순하고 명확하게 개발 해야 한다 - 스프링 빈 의존관계 설정 - 준비 => MemberServiceImpl은 MemberRepository를 의존함 ==> 이를 생성자로 주입 받음 (의존관계 주입 DI) ===> 스프링에서 알아서 필요한 것들을 순차적으로 생성해 넣어준다 - 스프링 빈 의존관계 설정 - 완료 => 의존관계 주입도 같이 처리 된다 ==> MemoryMemberRepository는 bean으로 동록 하지 않았지만 주입에는 사용 되었다 [생각과 느낌] 재미있다

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 283

노트 정리해보았어요. 어떤가요?

스프링 핵심 원리 - 기본편

< IoC > - 인터페이스를 사용하는 입장에서는 어떤 것을 쓸지 제어 할 수 없다 => 외부에서 관리함 예: AppConfig vs. OrderServiceImpl < 깨달음 > - 라이브러리와 프레임워크 차이 => 라이브러리: 내가 만든 체계에서 직접 호출한다 => 프레임워크: 내가 만든 것을 알아서 호출한다 < DI > - 정적인 클래스 의존 관계 => import만 보고 쉽게 파악 가능 => 세부 기능이 바뀌어도 바뀌면 안된다 - 동적인 객체 의존 관계 => 실제 실행 봐야 알 수 있음 => 세부 기능에 따라 바뀜 - DI: -- 인스턴스 생성한다 -- 참조하는 값에 넣어준다 < 깨달음 > - 의존 관계는 두가지 이다 => 정적: 클래스 의존 관계 => 동적: 객체 의존 관계 - 툴로 분석 가능 => Intellij: diagram - show diagram - 설계 할 때는 -- 인터페이스 설계 그리고 -- 객체 설계 까지 두루 한다 < IoC, DI 컨테이너 > - 뜻: 객체를 생성하고 연결해주는 역할을 하는 아이 - 예: AppConfig, 스프링, Assembler, Object factory < 깨달음 > - 잘 만든 코드는 코드 블럭을 가지고 조립하는 것이다

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 1 조회수 321

저처럼 소름 돋으셨나요?

스프링 핵심 원리 - 기본편

[와우 포인트] 고칠 때 차이 - 구성 영역, 사용 영역 중 구성 영역만 바꾸면 된다 -- 구성 영역: 대신, 구성 영역이 세세히 다 알아야 한다 -- 사용 영역: 더 이상 손댈 필요가 없다. --- => 스프링 코드 짤 때 AppConfig 코드 외 아무 것도 손대지 않아도 된다 - 개발자가 하는 일 => 최초에 사용 영역만 인터페이스만 사용해서 잘 만드는 것 - OCP 지켜짐 => 구체화를 바꿔도 클라이언트 코드 바꾸지 않아도 된다 ==> 인터페이스를 사용하는 입장의 코드는 더 이상 인터페이스 구현체가 바뀌어도 바꾸지 않아도 된다 - DIP 지켜짐 => 추상화만 의존 ==> 구현은 모름 [팁] - Ctrl + R 하면 기존 실행된 것 실행됨

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 251

리펙토링이 무엇인지 약간은 더 알것 같아요!

스프링 핵심 원리 - 기본편

[리펙토링] - 역할들을 드러나게 하는 것 중요 => 인터페이스 반환 하는 부분이 안보임 - 중복 제거 => 같은 구현 클래스를 여러 군데서 넣어주던 중복 제거 [깨달음 점] - 리펙토링에서 것은 중복 제거하고 그런 것들을 하던 이유가 명확해졌다 => 역할과 구현 등 관계를 확인 하고 구조를 편하게 확인 하기 위해서 였다 ==> 앱 컨피그만 보아도 이 프로그램이 뭘 쓰고 있고 어떻게 돌아가는지 짐작이 간다 - intellij extract method 쓰면 refactor 쉽다

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 251

노트 정리해보았어요. 혹시 문제 있으시면 알려주셔요!

스프링 핵심 원리 - 기본편

[문제점] - 클라이언트 (OrderServiceImpl) 고쳐야함 => OCP를 위반함 - OrderServiceImpl이 DiscountPolicy 뿐만 아니라 구현 클래스 FixDiscountPolicy에도 의존하고 있다 => DIP를 위반함 [해결 방법] - 1. DIP 해결 방법: 인터페이스만 의존 하게 한다 -- => 코드 내에서도 객체 할당 X - 객체 할당 X 에서 생기는 NullPointer Exception 문제 해결 방법: -- => 대신 주입할 얘가 필요하다 [강의 느낀점] - 실제 의존 관계 다이어그램에서 화살표를 보니 의존 관계가 확 와닿는다

  • spring
  • 객체지향
Tai Sun Park 댓글 1 좋아요 0 조회수 231

AppConfig의 역할이 너무 광범위 하지는 않을까요?

스프링 핵심 원리 - 기본편

질문: - AppConfig의 역할이 너무 광범위 하지는 않을까요? - member service impl 에 주입하는 구체 클래스는 동적으로 runtime 시 정하는 방법도 있을까요? 깨달음: - final 변수를 만들면 기본 할당 또는 생성자를 통해서 할당 되어야 함 - Command + E: 과거 했던 파일들 다보는 방법 => vim: ls [관심사의 분리] - 공연 => 역할의 구현을 누가 정하는가: 기획자 - 기획자 => AppConfig [AppConfig] - 역할 => 구현 생성 => 역할에 설정 => 기획자로서 역할을 갖는 ROLE에 맞는 구현 ACTOR를 배정함 - 역할에 설정 방법: -- 생성자 주입 [Injection] - Injection => 역할에 구체화를 부여 - DIP를 지킨다 => 구현 클래스를 몰라도 된다. ==> 역할인 인터페이스만 의존한다. - OCP를 지킨다 => (closed) 역할을 사용하는 클라이언트가 구현 클래스를 의지 않해서 구현이 바뀔 때마다 수정할 필요가 없다 => (open) 클라이언트 수정 없이 언제든지 추가 구현 클래스를 만들어서 클라이언트에 적용 할 수 있다 - Dependency Injection => 의존 관계 주입 ==> 클라이언트가 의존하는 것을 클라이언트 외부에서 주입

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 240

순진한 개발자 여기 있어요

스프링 핵심 원리 - 기본편

아래와 같이 정리해보았습니다. 혹시 더 필요한 부분이 있을까요? [agile manifesto] 느낀점: - 기준을 제시해주어서 좋다 - 개발 할 때 고려 할 기준: -- 개인의 생각을 중요시하고 상호 교류가 잘 일어나는 것이 중요 -- 문서화 할 시간에 더 나은 제품 -- 고객과 협력에 집중하고 계약 협상에 대한 생각은 나중에 -- 필요에 따른 변화를 우선. 계획에 집착하기보다 [test] 깨달은점: - test 코드 파일 작성 쉽게 가능하다 느낀점: - 아직 SOLID가 안되는 문제점은 말씀해주시지 않았다

  • spring
  • 객체지향
Tai Sun Park 댓글 1 좋아요 1 조회수 234

MemberRepository 공유가 되나요?

스프링 핵심 원리 - 기본편

질문: - Member Repository가 OrderService와 MemberService 사이에 어떻게 공유 될 수 있을지 => 내 생각: final이 영향을 준다? => 실제 답: repository 내 store가 static으로 선언되어서 그렇다 느낀점: - 단위테스트가 중요하다 => 단위테스트로 점점 쌓아 점점 더 크게 테스트하는 것이다 - 이렇게 역할과 구현을 나눠서 개발만 한 것도 잘한 것이다 => 실무에서 이렇게만 해주는 것을 1차 단계로 해보자

  • spring
  • 객체지향
Tai Sun Park 댓글 1 좋아요 0 조회수 367

discountPrice가 최종 할인된 가격 맞을까요?

스프링 핵심 원리 - 기본편

[수업 노트 공유] 깨달음: 1. 단일 설계 원칙을 잘 지켰다: - "Order 생성 시 DiscountPolicy는 나는 모르겠고~ 할 수 있다. 질문: 1. discountPrice가 최종 할인된 가격 맞을까요? - discount 함수는 얼마나 할인 되는지를 알려주는 함수 아닌가요?

  • spring
  • 객체지향
Tai Sun Park 댓글 1 좋아요 0 조회수 332

여러분은 어떤 깨달음이 있으셨나요?

스프링 핵심 원리 - 기본편

< 노트 > 깨달음: 주문 서비스를 하나 둔다 => 주문 생성 서비스 제공하고 => 결과로 주문 결과를 반영 => 주문 결과에는 회원 등급 별 할인 정책에 의한 가격이 들어감 ==> 회원 등급 조회하기 위한 회원 서비스 ==> 할인 정책 적용하기 위한 할인 정책 서비스가 필요함 할인 정책이 하나의 역할이 될 수 있다 => 구현은 정액, 정률. 협력 관계: 역할을 통한 체계 => 재사용: 구현 바꿔서 체계 세부 내용을 바꿀 수 있다

  • spring
  • 객체지향
Tai Sun Park 댓글 0 좋아요 0 조회수 219

한번 정리해보았어요! 어떠신가요?

스프링 핵심 원리 - 기본편

[리뷰] 클래스 다이어그램 => 정적 객체 다이어그램 => 동적 [JUNIT] 배운점: - 사용시 given, when, then 적기 검증: - org.assertj.core.api 쓰기 이제 테스트: - 눈으로 검증 하는 테스트 => 테스트 코드를 통한 검증 [DIP] DIP 위반: => 한개의 클래스 내에서 인터페이스와 구현체 두가지를 의존함

  • spring
  • 객체지향
Tai Sun Park 댓글 1 좋아요 0 조회수 208

인기 태그

인프런 TOP Writers

주간 인기글