본문 바로가기

프로젝트40

객체 구조를 어떻게 설정할까? 일단 인터페이스의 존재 이유를 깨닫자. 정보처리기사 출처 - 인터페이스란, 두 어플리케이션 간의 상호작용을 위한 중간다리 역할. 그렇다면 우리는 이 interface를 활용해서, 각 객체간의 의존성 관계를 줄여야 한다. ex) 카드사의 결제 구조를 생각한다면, service에 각 카드별 find 등을 구현한다면 최종 paycontroller에서는 수많은 객체들(삼성,bc카드)등과 다 의존되어야 한다. 그렇다면, 신한카드, 우리카드 등에 따라 다른 service를 구현해야할때, 이 모든 것을 interface로 묶어, 이 interface를 controller에서 의존받아서 사용하는 방식이 내부 정보를 가리고, 의존성을 감소시키는 데에 큰 도움이 된다. 1. 객체의 크기 findby id, findbyem.. 2024. 1. 20.
ERROR /예외 처리 NULL요건을 지키지 않았거나, 문제가 발생했을때는 어떡할까? HTTP MESSAGE 중 배열이 비어있을경우 NULL이 아닌 빈 배열을 응답하게 된다. 404,403등의 수많은 ERROR MESSAGE를 보았다. 그 중에 4XX,5XX과 같은 경우에는 항상 동일한 포멧을 RETURN하는 형태로 ERROR처리가 이루어져야 한다. ERROR에 대한 처리를 MAP 객체를 통하는 방식은, 지양하자. ERRORRESPONSE를, 별도의 CLASS로 선언하여 객체 형태로 RETURN 하는 것이 좋다. 1. ERROR RESPONSE -> 안에 내부 FIELD로 ERRORCODE를 사용한다 . 2. 그 후의 ERRORCODE는 주로 ENUM 형태로, MESSAGE를 전송한다. CONTROLLER ERROR 처리 . .. 2024. 1. 20.
Exception의 종류들 Exception을 control하는게 리팩토링에서 굉장히 중요하기 때문에, Exception의 종류들과 특징을 정리하고자 한다. Exception은 CHECKED, RUNTIME->UNCHECKED이렇게 2가지 종류가 크게 있다고 할 수 있다. ERROR는, OUTOFMEMEORY,SLIDEDEATH 등등 처리하기가 굉장히 힘들다 . 우리는 주로 EXCEPTION에 집중한다. CHECKED EXCEPTION과 UNCHECKED의 차이는, UNCHECKED는 RUNTIMEEXCEPTION을 상속 받는 다는 것이다! CHECKED EXCEPTION의 경우에는 반드시 예외를 처리해야한다. 1. METHOD에 THROWS EXCEPTION 추가 2. TRY -> CATCH방식으로 예외를 처리해야한다 . ROL.. 2024. 1. 16.
오류보단, 예외로 처리하자 주로 Controller에서 발생한다. -> shutdown이라는 method가 있을때, 그 내부에서 exception까지를 모두 control하기 때문. 주로 try,catch에 따라서 처리를 하게되고 . 해당 exception을 control하는 역할을 분리한다. 1. 예외가 발생했는데 catch에서 하는일이 없다? : 이는 반드시 지양하며, 최소한 log라도 발생시켜주는 것이 좋다. 2. try catch를 사용하지 않는 것이 좋기는 좋다 ex) 환율이나 경제 api를 가져올때 -> 신한에서 없으면 하나은행으로 3. 만약에 필요하다면.. 예외를 받아서 더 구체적인 예외를 발생시키자. 이 느낌이다. 만약에 service에서 무슨 일을 한다고 하면. 그때 exception이 발생할 것이다. 이때 발생하.. 2024. 1. 16.
객체를 망치지 않는, Lombok의 사용 여태까지는 모든 공부 과정에서 Lombok을 사용해왔다. 이러한 Lombok은 생성자의 형성 등 간단하고 명료하게 객체의 생성을 지원한다. 허나 Lombok의 오사용은, 객체를 망가뜨릴수 있다. 1. @DATA를 지양해야 할 수 있다. ID,EMAIL,NAME이 있는 TABLE이 있다고 생각해보자 . 무분별하게 모든 FIELD에 대해 생성자를 형성했다고도 가정해보자 . 그렇다면 , 생성자로 들어올 수 있는 EMAIL은 EMAIL의 변경이 가능함을 의미하는 것이 아닌가? 혹은, EMAIL과 NAME이 동시에 바뀌어야 한다면 (즉, 데이터의 쌍이 있다면) SETTER가 이러한 쌍의 변경이 아닌 한 데이터만의 변환을 유발할 수도 있다. @EQUALSANDHASHCODE는 두 객체의 값과 동일성을 비교해준다. .. 2024. 1. 16.
패키지 구조 Layer과, Domain 형 계층이 있다 . Layer는 controller끼리, config끼리 묶이고 domian 같은 경우는 coupon -> controller,domain등으로 묶는 구조이다. Layer구조시는, 전체적인 구조를 쉽게 파악 할 수 있다. -> controller면 거기서 하면 된다. 하지만, 코드의 응집력 (코드끼리 분리되어 있는 것)이 떨어질 수 밖에 없다. Domain : 코드들이 응집되어있어, 상세적인 이해가 가능하다. 하지만 도메인 구조 없이는 이해가 굉장히 힘들다. Domain 구조가 최근에는 가장 권장하는 구조이다. 주로 config,error(exception),service,dto,table,repository등을 포함한 구졸 설계한다. 전체 범위에 적용되는 것도.. 2024. 1. 16.
개인 보안 노트 프로젝트 작성 과정 , 느낀점 해당 프로젝트는 클론 코딩의 일부로써, 개인이 진행하였다. spring security의 사용 뿐만 아니라, 앞서 진행했던 spring의 기본기와 spring boot등을 최대한 활용하고자 하였다. Package는 Admin, notes,notice,user,config 이렇게 기능이 아닌 각 도메인별로 분할하였다. 과정 진행중 특히 Spring Security 6와의 차이 때문에 애를 많이 먹었다. 현재 Spring Security가 6이 되며, 기존 코드들이 많이 decrepted 되어 설정이 특히나 어려웠다. 해당 configuriation을, https://jihyukcoding.tistory.com/94에 작성해 두었다. 이제 각 도메인 별로 설명을 진행하고자 한다. 1. User databas.. 2024. 1. 11.
개인 보안 노트 서비스 프로젝트 목적: 해당 목적이, 기능과 실제 사용자의 요구보단 spring secuirty의 필요 상황을 경험하고 구현에 있음에 유의하자. 프로젝트 요구사항 : 1. USER는 본인의 게시글을 저장,삭제,SELECT 가능 (본인 게시글에 대한 CURD기능) 2. 다른 USER의 게시글은 볼 수 없다. 3. ADMIN은, 다른 USER들의 게시글 제목 리스트만 볼 수 있다. 4. ADMIN만 공지사항을 작성가능하고, USER들은 이를 볼 수(만) 있다. API 요청 문서는, SPRING SECURITY를 활용하기 위한 목적의 PROJECT이기 때문에 보류 하도록 한다. 사용 스펙 WEBMVC 웹 프레임 워크 LOMBOK - GETTER SETTER등의 간단하게 코드 작성을 위함 Thymeleaf (간단 한 .. 2024. 1. 8.
개발자 키우기 프로젝트 구성도 패스트캠퍼스 강의를 토대로, 구성도를 가볍게 표현했다. 1. CLIENT가 REQUEST 2. SERVER가 BINDING,검증 3. DB에 트랜젝션, 요청과 데이터를 받고 보내고 4. 예외 처리 후 응답. 기능 : 1. 개발자 생성 (POST METHOD) 2. GET을 통해 개발자 정보확인 3. PUT을 통해 개발자 정보 수정 (완전히 개발자의 모든 정보를 수정한다) 그래서 PUT 4. DELETE로 개발자 정보 삭제 (분리보관) HTTP -> 프로토콜 (약속의 규약) HTTp Request 메세지 스팩 REQUEST BODY의 TYPE이 JSON, 그리고 응답도 JSON을 받고 싶다 TOKEN값을 헤더에 담기도 한다. 응답을 날려야겠다 이제 (중간과제 생략 ) 1개의 공백라인 이후 HEADE.. 2023. 12. 27.
to do list 1. TODO ITEM 추가 . POST METHOD로 , 내가 할 일을 적어서 서버에 UPDATE 해야 하기 때문에 POST METHOD를 사용하였다. 별도의 ENDPOINT가 존재하지 않는다. POST기 때문에 REQUEST가 존재하고, 이에 따른 RESPONSE로 추가한 내용을 보이게끔 한다 . 2. LIST 조회 서버의 데이터에 접근하여 조회만을 한다. REQUEST 없이 RESPONSE로 조회한 내용을 반환한다. 3. TODO ITEM 조회 ID에 따라서 ! 할 일을 조회하기 떄문에, ENDPOINT에 ID가 추가 되었다. 조회기 떄문에 GET을 사용, RESPONSE로 조회한 내용을 반환한다. 4. TODO ITEM 수정 본인의 ID에 들어가서 수정하기 때문에 ENDPOINT에 ID가 추가되었.. 2023. 12. 20.

티스토리툴바