codingBird

CORS 와 Preflight 그리고 설정파일 설명이 있었던 1편에 이어서 실제 코드를 보여주는 2편입니다. 1편을 작성하고 바로 2편을 작성하려 했지만 기존 프로젝트에서 @PreAuthorize 을 이용해 Method Security를 적용하는 모습을 보고 테스트 프로젝트에도 Method Security를 구현하고 싶어졌습니다. 그러기 위해서는 SpringContextHolder 그리고 Authentication의 학습이 필요했고 충분히 이해하고 나서야 구현할 수 있었기 때문에 조금 늦게 되었습니다. (사실 젤다의 영향도 아주 조금 있습니다…) 테스트 프로젝트 CORS 설정에 집중할 수 있도록 클라이언트와 서버 모두 최소한의 구현만 갖춘 프로젝트입니다. 다만 개인적인 욕심으로 Spring AOP 을 활..

전 최근 Spring Security 를 공부하고 있습니다. 물론 Spring Security 프레임워크는 매우 방대하기 때문에 모든 범위를 공부하고 있지는 않고 대략적인 아키텍처와 회사에서 사용하고 있는 인증과 인가 부분만 공식 문서 그리고 예제 코드를 통해 공부하는 중이라고 할 수 있습니다. 적다보니 내용이 길어져 배경 설명이 포함된 1편과 실제 코드와 테스트가 포함된 2편으로 나누어 구성했습니다. 글솜씨가 매우 부족해 읽기 힘들 수 있고 정확하지 않은 내용이 있을 수도 있다는 점을 참고해서 읽어주시면 좋겠습니다. (피드백은 환영입니다!) CORS 와 Preflight 아래 내용은 CORS 가 무엇인지 알고 있다는 가정하에 작성된 내용이라 혹시 모르더라도 이해할 수 있도록 CORS 를 간단하게 설명하..

Item2 - 생성자에 매개변수가 많다면 빌더를 고려하라. 점층적 생성자 패턴은 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기 어려워진다. 자바빈즈 패턴은 객체의 일관성이 깨져 오류가 발생하기 쉽다. 필수 인자와 필수 인자가 아닌 값들을 필드로 가지는 객체를 생성할 때 명명된 선택적 매개변수를 흉내낸 빌더를 사용해 유연하게 생성해보자. public class Product { private String name; private int price; private String color; private String size; private Product(Builder builder) { this.name = builder.name; this.price = builder.price; this.co..

Item1 - 생성자 대신 정적 팩터리 메서드를 고려하라 정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는 것이 좋다. 하지만 정적 팩터리를 사용하는 게 유리한 경우가 많으므로 무작정 public 생성자를 제공하던 습관이 있다면 고치자. 정적 팩터리 메서드 장점 이름을 가질 수 있다 생성자는 매개변수와 생성자만으로 반환될 객체 특성을 살리지 못 한다. 반면 정적 팩터리는 이름만 잘 지으면 반환될 객체 특성을 쉽게 묘사할 수 있다 // 값이 소수인 BigInteger를 반환하는 생성자 시그니처 BigInteger(int, int, Random) // 값이 소수인 BigInteger를 반환하는 정적 팩터리 메서드 BigInteger.probablePrime..

홀 : 그래서 Static멤버는 왜 인스턴스를 생성하지 않아도 사용할 수 있는 거죠? 나 : 클래스가 로딩될 때 method area에 메타데이터가 올라가서...? 홀 : 그럼 그게 어떻게 된다는 거죠? 나 : 모릅니당... 맞다. Method Area에 뭔가가 있다고만 알고 있고 무엇이 들어있는지 실제로 찾아보진 않았다. 그래서 인터넷을 뒤지며 찾았는데도 제대로 된 정보가 나오지 않아 포기를 하려던 도중에 중국어로 작성된 글이 있어 한번 봤는데 꽤나 자세하게 나와있고 작가가 원래 책으로 출판을 하려던 내용을 출판사와 계약이 깨지는 바람에 블로그에 글을 올리게 되었다고 하니 어느 정도 믿을 수 있지 않을까 해서 정리하게 되었다. 참고로 작가는 대만대 컴공과를 졸업하고 퍼블릭 아이비리그인 UIUC에서 석사..

객체지향에는 상속이라는 특징이 있다. 상속은 기존 객체를 토대로 새로운 객체를 생성하는 것으로 기존 객체의 특징을 웬만하면 전부 가지고 있고 (접근 제한자 public이라는 가정하에는 전부, protected는 해당 패키지의 클래스를 상속했다면 가능, default는 해당 패키지 안에서만, private은 불가), 기존 객체를 토대로 자신만의 특성을 확장하여 사용이 가능하다. 근데, 이거 evil이라고 하더라. 객체지향의 꽃인 다형성을 피우기 위해 상속이라는 개념은 객체지향에서 매우 중요하다고 어디선가 본거 같은데 정작 상속이 evil이라니? 그럼 애당초 패러다임에 문제가 있는 게 아닌가? 상속할 수 있어서 상속받아 사용했는데 왜 나빠? 암튼 이런 생각을 가지고 상속은 정말 나쁜지, 아니면 나쁜 상황이 ..