개발자 준비/개발 공부14 방심하기 쉬운 캡슐화에 대한 고찰 캡슐화가 뭔가요? 라고하면 책임들을 하나로 묶고 실제 구현을 외부로 부터 감추는 것이라고 알고있습니다 객체의 책임을 잘 묶으면 응집도가 올라가 자율적인 객체가 됩니다. 자율적인 객체가 되면 단순히 데이터 전달자 역할이 아니라, 자신의 상태를 스스로 처리할 수 있습니다. 하지만, 이 상황에서 은닉화가 잘 이루어지지 않는다면 외부 객체가 은닉화가 지켜지지 않은 객체의 정보를 너무 많이 알게 되고, 깊게 의존하는 코드를 작성하게 될 위험이 존재합니다, 이는 곧 두 객체 모두 높은 결합도와 낮은 응집도를 지닌 수동적인 객체가 됨을 의미합니다 이는, 변경이 힘들게 하여 유지보수가 어렵게 됩니다 은닉화 실수하기 쉬운 케이스 은닉화가 잘 이루어지지 않았다는것 객체가 자신의 데이터 존재나 상태, 그리고 책임을 외부로 .. 2022. 12. 6. API 사용성 개선: 사용자 정의 예외를 이용한 API 응답 세분화 및 상세화 사용자 정의 예외를 통해 API 응답 세분화를 적용한 이유 API 원작자 없이도 프론트엔드 같은 API 이용자가 API를 쉽고 정확하게 사용하도록 하기 위해선, API 명세서 뿐만 아니라 상태코드와 메세지를 통한 상세하고 정교한 응답이 필수적이라고 생각합니다. 이 과정에서, 특정 요청을 처리함에 있어 잘못 되었다면 어떻게 잘못 되었는지 어떤 처리를 해줘야 하는지 알려줘야 합니다. 또한, 정교한 예외 처리로 서버의 리소스가 훼손되는 문제도 방지해야 합니다. 이를 위해, 발생할 수 있는 예외별로 사용자 정의 예외를 생성하고 상태코드와 에러메세지를 통해 상세한 예외 상황을 응답할 수 있도록 할 것입니다. 이 과정에서, Spring ExceptionResolver를 이용하여 예외 관리가 편리하게 코드를 개선한 .. 2022. 12. 2. 전략 패턴과 캡슐화 개념을 이용한 도메인과 검증 로직 최적 분리 과정 💫시작하기 전에 프로젝트에서 스케줄러 기능을 개발하면서 ‘검증 로직을 도메인 클래스에서 분리’한 과정을 기록하고자 합니다. 해결 과정은 아래와 같습니다. 검증 책임을 가진 클래스를 별도 생성하여 분리 JPA 임베디드 타입과 전략 패턴을 이용한 분리(feat. 래퍼 클래스) JPA 임베디트 타입과 스프링 validation 혼합 시스템에서 발생한 에러를 적절히 처리해서 사용자의 불편을 최소화하는 것은 개발의 기본 덕목이지만, 보통 에러는 클라이언트의 잘못된 요청이나 입력에서 비롯되는 경우가 많았습니다. 에러 처리를 위한 코드가 늘어나다 보니 시스템 복잡도가 점점 증가했습니다. 때문에, 이 이상 에러 처리에 고집하기보다 에러 예방을 통해 위험 발생 가능성을 사전에 최대한 배제하는 것이 좋겠다고 생각했습니다... 2022. 12. 2. JWT 토큰 탈취시 대처법에 대한 고찰 AS-IS 사용자에게 다가가는 서비스를 만들기 위해선 보안도 반드시 고려해보아야 한다고 생각합니다 이번에 보안을 적용해볼 프로젝트는 MVVM의 단순 DB I/O 작업을 하는 서버이며, 아래와 같은 구조로 동작합니다 로그인을 통해 인가된 사용자 보낸 요청(일정 CRUD)을 서버가 응답합니다 저는 사용자를 인증하는 부분:기밀성에서의 위험을 최소화 할 수 있는 방법을 고민해 보았습니다 기존 토큰 인증 방식 로그인 - access-token 발급 - 서비스 요청 - 서버에서 access-token 검증 - 서비스 응답 //토큰 검증기 public JwtCode validateToken(String token) { try { Jwts.parserBuilder().setSigningKey(key).build().p.. 2022. 12. 2. 이전 1 2 3 4 다음
