비전공자의 JAVA개발 일기

자바 8에서 도입된 람다 표현식과 스트림 API는 자바 프로그래밍의 패러다임을 완전히 바꿔놓았습니다. 함수형 프로그래밍의 장점을 자바에 도입하여 더 간결하고 읽기 쉬운 코드를 작성할 수 있게 되었죠.람다 표현식 기본 문법람다 표현식은 (파라미터) -> 실행문 형태로 작성됩니다. 파라미터와 리턴값의 유무에 따라 다양한 형태로 사용할 수 있습니다.파라미터와 리턴값 조합별 람다 표현식파라미터 리턴값 예시함수 인터페이스파라미터리턴값RunnableXXSupplierXOConsumer OOFunctionOXPredicateOO(boolean) //e.g// 파라미터 없음, 리턴값 없음Runnable task = () -> System.out.println("작업 실행");// 파라미터 없음, 리턴값 있음Suppli..

추상화어떤 양상, 세부 사항, 구조를 좀더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다. 복잡성을 다루기 위해 추상화는 두 차원에서 이뤄진다.첫 번째 차원은 구체적인 사물들 간의 공통점은 취하고 차이점은 버리는 일반화를 통해 단순하게 만드는 것두 번째 차원은 중요한 부분을 강조하기 위해 불필요한 세부 사항을 제거함으로써 단순하게 만드는 것모든 경우에는 추상화의 목적은 복잡성을 이해하기 쉬운 수준으로 단순화하는 것이라는 점을 기억해야 한다. 개념공통점을 기반으로 객체들을 묶기 위한 그릇을 개념이라고 한다. 개념이란 일번적으로 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념을 뜻한다.이런 개념을 이용하면 객체를 여러 그룹으..

객체, 그리고 소프트웨어 나라객체란 식별 가능한 개체 또는 사물이다. 객체는 만질수 있는 구체적인 사물일 수 있고, 시간처럼 추상적인 개념일 수도 있다. 객체는 구별이 가능한 식별자, 특징적인 행동, 변경이 가능한 상태를 가지고 소프트웨어 안에서 저장된 상태와 실행 가능한 코드를 통해 구현된다. 상태가 왜 필요한가? 객체가 주변 환경과의 상호작용에 어떻게 반응하는가는 그 시점까지 객체에 어떤 일이 발생 했느냐에 좌우된다.예를 들어 여행을 가기위해 비행기를 타려면 탑승전 항공권을 발권해야한다. 이때 발권해놨다면 비행기 좌석에 앉아 출발하지만 발권을 하지 않았다면 비행기를 탈수없듯 이런 발권을 했냐 안했냐의 과거의 행동이 비행기 탑승여부에 영향을 주는것이다.상태를 이용하면 과거의 모든 행동이력을 설명하지 않..

지금까지 프로젝트를 진행해오면서 관련 개념과 지식이 부족하다고 많이 느끼게되었다. 관련 서적을 읽어가며 되돌아보는 시간을 갖기로 했다.그 첫번째로는 객체지향의 사실과 오해 를 읽고 정리해보고자 한다. 1장 협력하는 객체들 (e.g 커피와 바리스타)우리가 실생활에서 커피를 마식 위해 커피전문점을 방문하여 커피를 주문하는 과정을 살펴보자.우선 커피를 주문(Req)을 캐시어에게 하고 캐시어는 이 주문을 다시 바리스타에게 요청하여 바리스타가 커피를 만들고 캐시어에게 전달이후 다시 캐시어가 주문자에게 전달하며 커피를 받는다.이때 손님이 캐시어에게 또는 캐시어가 바리스타에게 요청을 보내는것을 Request라하고 그 Request에 응답하는것을 Response라 한다. (영문 단어뜻 그대로임)이러한 요청과 응답을 통..

객체 지향 설계의 5원칙으로 해당 원칙에 따르면 자식클래스의 인스턴스가 부모 클래스의 인스턴스를 대신하더라도 의도에 맞게 작동해야한다. 따라서 SOLID 원칙이란 객체지향 설계에서 지켜줘야 할 5개의 소프트웨어 개발 원칙이다.S : SRP(Single Responsibility Principle) 단일 책임 원칙O : OCP (Open Closed Principle) 개방 폐쇄 원칙L : LSP (Liskov Substitution Principle) 리스코프 치환 원칙I : ISP (Interface Segregation Principle) 인터페이스 분리 원칙D : DIP (Dependency Inversion Principle) 의존 역전 원칙으로 각각의 원칙에 대해 알아보자.1. SRP (Sing..

WebSocket 구동 원리WebSocket은 클라이언트와 서버 간의 양방향 실시간 통신을 가능하게 하는 프로토콜입니다. 기본적인 연결 과정은 다음과 같습니다.연결 설정 과정HTTP 핸드셰이크 시작클라이언트가 서버에 HTTP/1.1 요청을 보냅니다요청 헤더에 Upgrade: websocket과 Connection: Upgrade를 포함합니다프로토콜 업그레이드서버가 WebSocket 연결을 수락하면 HTTP 101 상태 코드를 반환합니다이후 HTTP 프로토콜에서 WebSocket 프로토콜로 전환됩니다실시간 통신 시작연결이 설정되면 클라이언트와 서버 간에 양방향 데이터 전송이 가능해집니다TCP 연결을 유지하면서 지속적인 통신이 이루어집니다클라이언트 -> 서버: GET /chat HTTP/1.1 ..

최근 프로젝트를 진행하면서 디버깅의 중요성에 대해 뼈저리게 느끼게 되었습니다. 그동안 버그가 발생했을 때 제대로 된 디버깅 과정 없이 추측만으로 문제를 해결하려 했던 제 자신을 돌아보며, 이 경험을 공유하고자 한다.과거의 잘못된 디버깅 방식추측에 의존한 문제 해결프로젝트를 진행하면서 버그가 발생하면, 저는 주로 다음과 같은 방식으로 접근했었다.코드를 대충 훑어보고 "이 부분이 문제일 것 같다"고 추측Request/Response 값들을 제대로 확인하지 않음데이터가 올바르게 전달되는지 검증하지 않음문제가 프론트엔드에서 발생한 것인지, 백엔드에서 발생한 것인지 구분하지 않음결과적으로 발생한 문제들이런 방식으로 접근하다 보니:문제가 점점 복잡하게 얽히게 됨해결 시간이 예상보다 훨씬 오래 걸림같은 유형의 버그가..

"코드가 돌아가는데 뭐가 문제냐고?" 지금 팀원이 작성한 코드를 코드리뷰하며 타 팀원이 지적한문제를 정리하고자 한다.처음에 AuthenticationManager를 생성자 주입해서 쓸 때도 동작은 했어.근데 이 방식은 Spring의 DI 원칙을 무시하는 꼼수였다. 차이점을 명확히 알자!1. DI 원칙 위반 → 유지보수 문제원본 코드 (문제점) private final AuthenticationManager authenticationManager; //문제인 부분 @Override public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response) throws Authenticatio..

맥에서 잘되던 프로젝트가 윈도우에서 작업 하면 문제가 생길때가 있다 특히 도커로 프로젝트를 실행했을때 나는 다음과 같은 문제를 직면했다이를 해결하기위해서 인텔리제이에서 gradlew파일들을 하나하나 lf로 변경했다이후 server.sh를 실행했더니 잘되었다. 왜 CRLF와 LF문제가 자주 생길까? 이를 좀 알아보고자 한다.먼저, 윈도우와 맥(리눅스) 환경의 가장 큰 차이 중 하나가 바로 줄바꿈 문자(Line Ending) 방식이다.윈도우는 CRLF(\r\n)맥과 리눅스는 LF(\n)이 차이 때문에, 맥에서 잘 동작하던 쉘 스크립트나 gradlew 같은 파일이 윈도우에서 CRLF로 저장되면, 도커나 리눅스 환경에서 실행할 때 에러가 발생한다. 대표적으로 /bin/bash^M: bad interpreter:..

최근 매칭관련 매칭이 가능한 유저를 조회하는 로직에서 es를 사용하게 되었는데 이때 filter를 사용해서 충족되어야하는 조건, 그리고 조건에 포함되면안되는 조건, 선택 조건 등 검색시 조건을 추가하여 검색하는 로직을 만들었는데. 이를 정리하고자한다.Elasticsearch 쿼리 조건 타입ES에서 검색 조건을 설정할 때 주로 사용하는 세 가지 주요 쿼리 타입이 있다.must - 반드시 충족해야 하는 조건이 조건에 맞지 않는 문서는 결과에서 완전히 제외됨필수 조건으로 작동하며 AND 연산자와 유사함should - 충족하면 좋은 조건이 조건을 만족하면 문서의 관련성 점수가 높아짐가중치를 부여하는 방식으로 작동함필수는 아니지만 만족할수록 검색 결과 상위에 노출됨must_not - 포함되면 안 되는 조건이 조건..