1. 현재 학습 진도 몇 챕터/몇 강을 수강 중이신가요? 4-8 여기까지 이해하신 내용은 무엇인가요? 외래키 제약조건으로 인해 발생한 데드락 문제를 해결하기 위해 INSERT 하려는 테이블에 외래 키를 제거한다. 2. 어려움을 겪는 부분 외래키를 만약에 제거한다면, 어플리케이션 레벨에서 직접 관리한다고 했는데, 구체적으로 어떻게 관리를 하는 건지 궁금합니다! INSERT 하려는 테이블과 연관된 테이블들을 먼저 조회( findXXX() )를 하고, 만약에 없다면 예외를 발생시켜서 트랜잭션을 롤백시키는 방식으로 처리하나요? 실무에서 주로 어떻게 해결하는지 궁금합니다. 그리고 외래키를 사용하지 않는 첫 번째 방법은 이미 테이블이 생성된 시점( INSERT 하려는 테이블에 외래키가 추가되어 있는 상황)에서도 적용할 수 있는건가요? 예를 들어, 이미 테이블에 데이터가 추가되어 있는 상황에서 첫 번째 방법을 적용하려면, 테이블 구조를 아예 바꿔야 할텐데 이 경우에는 두 번째 방법인 쿼리 순서를 바꾸는 걸 대안으로 사용하는 건가요?
강의에선 되게 단순하게 큰 틀 위주로 알려주시는 것 같아서 개인적으로 더 자세한 의미나 추가적인 개념이 궁금할 때 검색해보는 편인데, DI라는 것이 클래스 간의 결합도를 낮추고 객체의 유연성을 높이기 위해 빈 객체를 만들어 주입하는 것을 의미한다고 정리했습니다. 이게 맞게 정리한건지 궁금합니다. 또 추상 클래스와 인터페이스 간의 차이점은 찾아봐도 이해가 어렵길래 선생님의 친절한 설명이 필요할 것 같아서 추가로 여쭤봅니다!
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] Array 연습 문제 5번을 제가 스스로 풀어보았을 때 이런 식으로 코드가 나왔고, 실행시켜봤을 때 답은 똑같이 나오는 것 같습니다. 다만 풀이와는 코드가 조금 다른 부분이 있는데 혹시 제가 풀어 본 코드도 맞는 코드인가요? 아니면 틀린 걸까요?
안녕하세요, 토비님. 강의 초반에 말씀해 주신 것처럼, 리팩토링 과정에서 “제가 했다면 어떻게 했을까”를 계속 생각해 보며 토비님의 의사결정 과정을 따라가고 있습니다. MemberService.register() 메소드에서 emailSender.send(...) 를 sendWelcomeEmail() 로 분리하시는 과정을 보며 두 가지 고민이 생겼습니다. 첫째, 환영 이메일의 내용이나 정책이 변경될 때마다 MemberService 의 코드가 함께 변경되어야 한다면, 이는 SRP 위반에 해당하지 않는지에 대한 고민입니다. 이 경우 환영 이메일 전송에 대한 책임을 EmailSender 인터페이스 쪽으로 옮기는 것이 더 적절한지 궁금해졌습니다. 둘째, 만약 EmailSender 인터페이스에 해당 메소드를 추가한다면, 구현체가 늘어날수록 인터페이스가 비대해지거나 향후 구현 복잡도가 증가할 수 있다고 느꼈습니다. 이런 경우 default method 로 제공하는 방식에 대해서는 어떻게 생각하시는지도 궁금합니다.
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 질문드립니다. 클래스에서 static 메서드엔 static 변수와 메서드만 사용할 수 있고 인스턴스 변수와 메서드를 사용하지 못하는 이유는 '인스턴스는 생성이 되어야 참조값이 생성되기에 아직 생성되지 않은 클래스 내에서는 인스턴스를 사용할 수 없다.'로 이해하고 있습니다. 그러면 해당 클래스의 인스턴스 메서드 에서는 아직 생성되지 않은 클래스인데 인스턴스 변수와 메서드를 사용할 수 있는 이유가 무엇일까요?
다른 분이 질문한 내용을 읽어보고 고민하고 생각해봤는데도 이해가 안되서 질문 합니다. str == ch 는 0 이되는건 알겠는데 그 옆 str+1로 다음 글자 인것도 알겠습니다 근데 그옆에 ch는 무슨뜻이죠?? ch는 그냥 무시하는 건가요? return( *str == ch)여기에서 0이 되는건 이해됩니다. 그런데 charFreq(str + 1, ch)에서 ch는 그냥 무시되어버리는 도저히 이해가 안됩니다 ㅠㅠ 도와주세요 charFreq(str + 1,ch) 여기 값에서는 무슨 짓을 해도 계속 0이 나오는건가요?
Express는 비동기 에러를 잡지 못한다고 강의에서 배웠습니다. 이게 혹시 싱글 스레드와 관련이 있을까요? 그렇다면 스프링의 경우는 어떻게 다를까요? Express는 에러 발생 지점에 가까이 정의된 에러 처리 미들웨어를 우선적으로 처리한다고 배웠습니다. 단순 코드적으로 위치가 가까운 거 맞나요? 에러 처리 미들웨어가 여러 개 있고 파일 내에 섞여있으면 코드 파악이 어려워질 수 있을 것 같아요. 실무에서 보통 권장되는 방식은 뭘까요? 에러처리 미들웨어를 하나만 두는지, 나눠서 같은 코드 위치에 두는지, 나누서 서로 다른 코드 위치 (라우터 사이)에 두는지 궁금합니다.
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 좋아요에 대한 정합성을 (article_id, user_id) 유니크 인덱스로 보장하는 것은 DB의 역할이라고 생각합니다. 그렇다면, 다수의 동시 요청이나 사용자의 반복 클릭(예: 좋아요 버튼을 연속으로 누르는 경우) 상황에서 불필요한 DB 부하와 예외 발생을 줄이기 위해 애플리케이션 단에서는 어떤 방식으로 이를 보완하고 처리하는 것이 적절한가요? 좋아요에 대한 정합성을 (article_id, user_id) 유니크 인덱스로 보장하는 것은 DB의 역할이라고 생각합니다. 다만, 다수의 동시 요청이나 사용자의 반복 클릭(예: 좋아요 버튼을 연속으로 누르는 경우) 상황에서는 애플리케이션 단의 단순한 선행 검증만으로는 이를 제어하기 어렵다고 느꼈습니다. 예를 들어, 아래와 같은 코드에서는 다음과 같은 경쟁 상태(race condition)가 발생할 수 있습니다. T1: exists → false T2: exists → false T1: insert T2: insert ❌ (유니크 제약 위반) if (!likeRepository.exists(postId, userId)) { likeRepository.save(...); } 이처럼 애플리케이션 레벨의 exists → insert 패턴이 동시성 문제를 해결하지 못하는 상황에서 DB 예외에만 의존하지 않고 불필요한 중복 요청과 예외 발생을 줄이기 위해 애플리케이션 단에서는 어떤 방식으로 이를 보완하는 것이 바람직하다고 보시는지 궁금합니다.
킬구형 ㅎㅇ 요즘에 배치 다시 학습하면서 좀 고민인 부분이 있음. 현재 회사에서 배치 Job이 좀 많이 늘어나면서 코드 관리가 너무 어렵더라고. Spring MVC에서는 Controller-Service-Repository 같은 레이어드 아키텍처나 클린 아키텍처처럼 널리 쓰이는 구조가 있는데, 배치 쪽은 이런 패키지 구조나 설계 방식에 대한 레퍼런스가 상대적으로 적은 것 같아서. 최근에 클린 아키텍처를 배우면서 배치에도 이런 구조를 적용할 수 있는지 궁금해졌거든. 지금 나는 대략 이런 식으로 구성하고 있어: batch/ ├── order/ │ ├── confirm/ │ │ ├── OrderConfirmJobConfig.java │ │ ├── OrderConfirmReader.java │ │ ├── OrderConfirmProcessor.java │ │ ├── OrderConfirmWriter.java │ │ └── OrderConfirmJobListener.java ├── payment/ │ ├── settle/ │ └── cancel/ ├── support/ ├── domain/ ├── application/ └── infrastructure/ 하나의 Job을 하나의 큰 애그리게이트처럼 보고 있어서, 관련 클래스를 패키지별로 분리하기보다 한 폴더 안에서 로우 레벨로 관리하는 게 더 편하더라고. 근데 Job이 계속 많아질수록 이게 맞는 건지, 더 나은 방법이 있는 건지 잘 모르겠어서. 혹시 형은 실무에서 Job이 많아졌을 때 패키지 구조나 코드 구성을 어떻게 가져가? 객체 간 위계나 import 의존성 방향 같은 것도 신경 써서 설계하는지도 궁금해. 물론 사람마다 차이가 있겠지만 시간 괜찮으면 경험 공유해주면 도움이 많이 될 것 같아!
