본문 바로가기

책, 강의 정리

[세미나정리] 그런 REST API로 괜찮은가 https://www.youtube.com/watch?v=RP_f5dMoHFc - 이응준님의 세미나를 보고 정리한 내용입니다. 들어가기전에 며칠전에 REST API 가 무엇이냐는 질문을 받았다. 명확하지 않은 점이 있어서 말끝을 흐리며 "자원과 Method 만으로 어떤 API인지 알 수 있도록 하는 표준" 이라고 대답했던 것 같다.(사실 이것보다 훨씬 버벅거렸겠지요 .. ㅎㅅㅎ ) 강의를 듣고 생각해보니 Self-descriptive, HATEOAS 키워드만 얘기했어도 참 좋았을 것 같다. 알고보니 대학생 때 한창 면접준비할 때 "REST"가 이해가 안가서 봤었던 자료였고, 지금 다시 보니 그때보다 더 이해가 가는 것 같기도 해서 좋았다. 시작하며 "REST 스럽지 않은 것 같아요 .. REST API .. 책, 강의 정리/세미나정리 2020. 3. 13.
아이템 [9] - try-finally 보다는 try-with-resources 를 사용하라 try-finally 의 문제점 try 문과 finally 문 모두에서 Exception 이 발생하면 finally 에서 발생한 Exception 만 보이기 때문에 디버깅이 어렵다. try-with-resources 를 사용하자 - 예외 발생 시 close 문에서 나오는 예외는 숨겨지기 때문에 try 문에서의 예외를 확인할 수 있다. - catch 문을 사용하여 예외 발생 시 또 다른 값을 반환하도록 할 수 있다. public class SampleResource implements AutoCloseable{ public void hello(){ System.out.println("Hello!"); } @Override public void close() throws Exception { System.o.. 책, 강의 정리/이펙티브자바 2020. 1. 10.
아이템 [8] - finalizer 와 cleaner 사용을 피하라 자바의 객체 소멸자: finalizer(자바 9 부터 deprecated), cleaner(자바 9) 사용하지 말아야 할 이유 1. 사용시기, 사용유무 모두 불확실하고 느리다. System.gc, System.runFinalization 으로 GC 실행의 가능성을 높여줄 수 는 있지만 보장하진 않는다. 2. System,.runFinalizersOnExit, Runtime.runFinalizersOnExit 은 finalizer 실행을 보장하지만 "쓰레드가 멈출 수 있다"는 치명적인 단점이 있다. 3. finalizer 동작 중 예외가 발생하면 마무리가 덜 된 상태로 종료될 수 있다. 4. finalizer 공격에 노출될 수 있다. - A 를 상속받는 B 클래스의 생성자 또는 직렬화 과정에서 except.. 책, 강의 정리/이펙티브자바 2020. 1. 10.
아이템 [7] - 다 쓴 객체 참조를 해제하라 자바를 사용할 때 "GC"에 의존하여 메모리 자원 관리에 소홀해서는 안된다. GC 의 손이 닿지 않는 자원이 생기지 않도록 주의해야한다. GC 관련 포스팅은> https://javabom.tistory.com/7 Memory Leak 예시 다 쓴 참조(obselete reference) 더이상 사용하지 않지만 참조되어있어 수거되지 않음. 뿐만 아니라 그 객체가 참조하고 있는 또 다른 객체까지 수거되지 않기 때문에 큰 문제가 발생할 수 있음. 메모리 누수 케이스 1. 자기 자신의 자원을 관리하는 클래스 이펙티브 자바 책에서는 Stack 을 예시로 든다. Stack이 자원을 pop 하기만 한다고 GC 대상이 되지는 않는다. 일반적으로 구현하는 pop 의 로직에는 stack size 를 -1 해줄 뿐이기 때문.. 책, 강의 정리/이펙티브자바 2020. 1. 10.
아이템 [6] - 불필요한 객체생성을 피하라 객체 생성이 잦은데 그 비용이 크다면? "불필요한 객체 생성을 피하면서 자원을 절약해야한다" 1. 같은 값임에도 다른 레퍼런스인 경우 같은 값을 가지고 동시에 불변객체라면 같은 레퍼런스를 가져야한다. 다시말해, 같은 값을 가지는 인스턴스가 두 개 이상 만들어 지는 것은 "불필요한 객체생성"이다. 대표적인 불편클래스 String 을 예로들면, String 클래스는 같은 문자열이라면 같은 레퍼런스를 지닌다. 두 객체가 같은 레퍼런스를 참조한다 그런데 만약 String s = new String("String") 방식으로 스트링 객체를 생성한다면, 이후에 String s2 = new String("String") 시에 같은 문자열임에도 다른 레퍼런스를 가지게 된다. 이렇게 쓰지 말라고 회색처리도 해준다. 2... 책, 강의 정리/이펙티브자바 2020. 1. 6.
아이템 [5] - 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 사전객체에 의존하는 맞춤법 검사기 클래스를 정적 유틸리티 클래스, 또는 싱글턴 클래스로 만든다는 것? -> 사전객체의 종류가 얼마든지 바뀔 수 있다는 판단을 하지 못한 것. -> 필드에 사전을 가지고 있는 순간 final 을 제거하여 사전을 교체할 수 있다고 하더라도 멀티 스레드환경에서 안정적이지 못하다. 동시에 여러 스레드가 해당 필드에 접근하고 있는데 누군가 이 필드를 다른 사전으로 교체한다면? 즉, 클래스가 하나 이상의 자원에 의존하고 그 자원이 클래스의 동작에 영향을 준다면 정적 유틸리티 클래스나 싱글턴 방식은 적합하지 않다. 다시 말해 이 클래스는 사용자마다 다른 사전을 가지고 맞춤법 검사 기능을 제공해야 한다. 이를 해결할 수 있는 방법으로는 "인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨.. 책, 강의 정리/이펙티브자바 2020. 1. 3.
아이템 [4] - 인스턴스화를 막으려거든 private 생성자를 사용하라 인스턴스화를 할 수 없는 클래스 ex) 정적 멤버만 담은 유틸리티 클래스(Arrays, Collections) 생성자를 명시하지 않으면 자동으로 퍼블릭 기본 생성자가 생성된다. 그렇기 때문에 인스턴스화를 원하지 않으면 직접 private 기본 생성자를 작성해야 한다. 추상클래를 만들어도 구현해서 생성자를 만들면 되기 때문에 인스턴스화가 불가하다고 말할 수 없다. 좀 더 확실히 해두고 싶다면 private 생성자에 Exception을 throw 하는 코드를 작성하자. private 생성자는 인스턴스화를 막을 뿐 아니라 상속을 막는효과도 있다. 상속은 기본적으로 public 또는 protected 접근이 가능한 기본 생성자가 있어야 하기 때문이다. 책, 강의 정리/이펙티브자바 2020. 1. 3.
아이템 [3] - private 생성자나 열거타입으로 싱글턴임을 보증하라 싱글턴 인스턴스를 오직 하나만 생성할 수 있는 클래스 ex) 함수 싱글턴의 한계? 싱글턴을 사용하는 클라이언트 테스트가 어렵다. 싱글턴을 만드는 방법 1. 싱글턴 인스턴스를 public static final 필드로 만들고 생성자를 private 으로 한다. public class Foo{ public static final Foo INSTANCE = new Foo(); private Foo(){}; } @Test public void 싱글턴테스트(){ Foo foo1 = Foo.INSTANCE; Foo foo2 = Foo.INSTANCE; assertThat(foo1).isEqualTo(foo2); // success } 장점: 간결하고 API 에 싱글턴임이 명백히 드러남(명확하게 이해 안됨) 예외) .. 책, 강의 정리/이펙티브자바 2020. 1. 1.

티스토리툴바