한 3달 전쯤인가 코틀린으로 안드로이드 프로그래밍을 간단하게 맛(?)만 봤는데 그 과정에서 프론트의 이벤트를 처리하는 코드가 많아졌고 이러한 이벤트를 처리하기 위한 이벤트 리스너 인터페이스를 구현해야하는데 그 과정에서 Override해야할 메서드가 너무 많아져 Adapter 클래스를 만들었는데 그걸 자바에서 간단하게 예시로 해보며 생각을 정리 해봤다. WebSocket에서 Listener을 사용해야하는 상황에 해당 인터페이스중 내가 사용하는 메서드가 1개일 경우 나머지 모든 메서드에 관해 Dummy값으로 채워 간단하게 사용하는게 Adapter라고 보면된다. 이럴 경우 따로 Listener를 구현하는 클래스를 만들어서 사용하는 메서드만 재정의하고 나머지는 dummy로 채워주자 인텔리제이 IDE가 자동으로 ..

우선 필요한 경우가 아니면 equals를 재정의하지 말고 필요하다면 equals와 hashCode는 왠만하면 인텔리제이나 다른 IDE에서 제공해주는 오버라이딩을 사용하자,, 클래스의 equals를 재정의하지 않는 것이 좋은 상황은 언제일까? 각 인스턴스가 본질적으로 고유하다. 인스턴스의 '논리적 동치성'을 검사할 일이 없다. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어 맞는다. 클래스가 private이거나 package-private이고 eqauls 메서드를 호출할 일이 없다 각 인스턴스가 본질적으로 고유하다는 말은 해당 인스턴스가 어떠한 값을 표현하기 위한 목적이 아니라 동작하는 인스턴스를 표현하는 클래스에 해당한다. '논리적 동치성'이란 어떠한 문장 P와 Q가 존재하며 P가 Q의 ..

이전 글에서 말한 것 처럼 자바에서 자원을 닫아야하는 경우에 finalizer,cleaner보다는 try-finally를 쓰는 것이 전통적인 방법이다. 백기선님이 JAVA STUDY에서도 언급하셨던 내용으로 실무에서 무조건 적용하라고 하셨다..! 기존의 try-finally방식으로는 자원 한 개의 사용에서는 별 이상을 못 느낀다. 하지만 자원이 한 개 더 추가된다면? 첫 번째 예외의 finally에서도 예외가 발생할 수 있다. 이런 상황에서는 위와 같은 코드는 자원수에 따라 더 길고 지저분해질 것이다. 하지만 AutoCloseable 인터페이스를 구현한 자원을 닫아야하는 클래스를 작성하면 자바 7에서 추가된 try-with-resource를 사용할 수 있다. 이처럼 finally에서 자원을 해제 하지 않..

finalizer와 cleaner 사용을 피하라 finalizer 와 cleaner는 자바에서 제공하는 두 가지 객체 소멸자로 finalizer는 deprecated되었다. finalizer는 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다. cleaner는 finalizer 보다는 덜 위험하지만 , 여전히 예측할 수 없고, 느려 일반적으로 불필요하다. 자바는 gc가 특정 객체와 관련된 자원을 회수하고 비메모리 자원 또한 try-with-resource를 사용해 회수가 가능한데 finalizer와 cleaner는 객체에 접근할 수 없게 된 후 실행되기까지 얼마나 걸릴지 알 수 가 없다 즉, 제때 실행되어야 하는 작업은 절대 할 수 없다. finalizer와 cleaner의 수행 시작 ..