공부하는 개발자

짧은 코멘트 클래스와 메소드, 그리고 필드의 접근 권한을 적절히 설정하는 일은 단순히 접근할 수 있다 / 없다 뿐 아니라, 코드를 읽는 사람 입장에서, '이 필드는 밖에서도 사용되나?' / '이 코드는 내부에서만 사용되구나'를 유추할 수 있게 해주는 수단이다. 때문에 clean code에 있어 기초적이면서도 중요하다고 생각한다. 가끔 단위 테스트를 작성하기 위해 private method를 public method로 만드는 분들이 계시는데, 그 보다 나은 방법은 default 접근 권한을 사용하는 것이다. 그리고 그 보다 조금 더 나은 방법은 테스트 해야할 부분과 테스트를 해야하지 않을 부분을 명확히 구분하여 외부로 하여금 내부를 테스트 하게 하는 것이다. (lannstark.tistory.com/105..

짧은 코멘트 Comparable을 생각보다 종종 구현을 하게 된다. 안타깝게 항상 헷갈리는 부분이 있는데 결과가 음수 혹은 양수일때 어떤 것이 앞에 가느냐... 이다 이럴때 해당 객체에 대한 단위 테스트를 깔끔하게 작성해주면 정말 좋다 👍 Comparable을 구현할지 고려하라 compareTo는 Object equals와 유사하다. 다른 점이라곤, compareTo는 단순 동치성 비교에 더해 순서까지 비교할 수 있으며 제네릭 한 것과 Comparable을 구현했다는 것은 그 클래스의 인스턴스들에는 자연적인 순서가 있음을 뜻하는 것이다. Comparable을 구현하면 검색, 극단값 계산, 자동 정렬되는 컬렉션 관리도 쉽게 할 수 있다. 자바 플랫폼 라이브러리의 모든 값 클래스와 열거타입은 Comparab..

짧은 코멘트 Cloneable을 실제로 구현해본 적은 없는 듯 하다. 백엔드 개발자로써 특정 객체에 복제를 해야할 일이 드물기 때문이다. 얕은 복사(shallow copy)와 깊은 복사(deep copy) 차이는 알아두는 것이 좋다. 얕은 복사는 객체 내부에 있는 참조 객체가 복제되지 않는 것이고, 깊은 복사는 객체 내부에 있는 참조 객체까지 복제되는 것이다. clone 재정의는 주의해서 징행하라 Cloneable은 복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스이다. 믹스인 : 클래스가 구현할 수 있는 타입. 믹스인이라 부르는 이유는 실제 클래스가 가지고 있는 주된 기능에 특정 타입을 구현함으로써 선택적인 기능을 혼합하기 때문이다 예시) public interface Comparable { ..

짧은 코멘트 lombok의 @ToString을 사용하면 Object의 toString을 쉽게 재정의할 수 있다. 모든 객체에 @ToString을 붙일 필요는 없지만, DTO에 붙이는 것은 디버깅시 꽤 유용했던 경험이 많다. toString을 항상 재정의 하라 Object 클래스의 기본 메소드 toString은 클래스이름@해시코드를 반환한다. 때문에 모든 클래스의 toString은 항상 재정의 하는 것이 좋다. 심지어 Object 클래스의 tostring의 규약은 “모든 하위 클래스에서 이 메소드를 재정의하라”이기도 하다. toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다. 또한 toString을 작성할 때 의도를 명확히 밝혀야 한다. 포맷 명시 toString을 구현할 때면 반환값의 ..

짧은 코멘트 equals 관련 코멘트에서 다루었던 것처럼 @EqualsAndHashCode 를 사용할 수 있다. 단, 이때 컬렉션이나 순환참조 객체 등을 @EqualsAndHashCode 대상 필드에 포함시키면 문제가 될 수 있다. IntelliJ 에서 command + N(윈도우는 아마 control + N..?) 을 눌러, equals And hashCode를 자동으로 만들어줄 수 있다. hashCode equals를 재정의한 클래스 모두에서는 hashCode도 재정의 해야 한다 hashCode의 규약 중 일부는 이렇다 - equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메소드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다 -..

짧은 코멘트 1. 테스트를 작성할때 equals를 활용할 수 있다. // 1. getter를 사용하는 방식 Person result = getPerson(); assertThat(result.getName()).isEqualTo("lannstark"); assertThat(result.getAge()).isEqualTo(20); // 2. equals를 사용하는 방식 Person result = getPerson(); assertThat(result).isEqualTo(new Person("lannstark", 20)); 2. lombok의 @EqualsAndHashCode를 이용하면 편리하다. 3. 실무에서 DB Table과 매핑되는 객체에 사용하기에는 다소 어려움이 있다. 필드가 굉장히 많기 때문. ..

짧은 코멘트 당연히 try with resources를 사용해야 한다. JDK 7부터 try with resources를 사용할 수 있게 되었는데 혹시 프로젝트가 JDK 6이라면.... (와.. AWS AMI에서 JDK8도 사라지고 JDK11을 권장하고 있는데, JDK 6이요..?) 다른회사로 도망쳐야 한다 try-finally 보다는 try-with-resources를 사용하라 자바 라이브러리에는 close 메소드를 호출하여 직접 닫아줘야 하는 자원이 많다. (ex. InputStream, OutputStream, java.sql.Connection) 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기도 한다 전통적으로 자원 닫힘을 보장하는 수단으로는 try - finally가..

짧은 코멘트 실제로 사용해본적이 없다. ThreadPoolExecutor가 finalizer 역할을 제공한다고 되어 있지만 JDK 버전에 따라 다른 모습을 보여준다. (모든 버전을 확인해본 것은 아니지만, 9버전부터 아무것도 하지 않게 변경된 것 같다. // Override without "throws Throwable" for compatibility with subclasses // whose finalize method invokes super.finalize() (as is recommended). // Before JDK 11, finalize() had a non-empty method body. /** * @implNote Previous versions of this class had a ..

짧은 코멘트 다 쓴 객체의 참조를 해제하지 않아 메모리 문제가 된적은 아직까지 경험해보지 못했다. 하지만 OOM이 발생한 적은 몇 번 존재했는데, OOM 발생시 heap dump를 뜨게 해둔 옵션이 OOM을 해결하는데 큰 도움을 주었다. JAVA 개발자라면 head dump 를 연습삼아 한 번 씩 떠보는 것도 좋아 보인다. 다 쓴 객체의 참조를 해제하라 다음 Stack 코드에서 이상한 부분을 발견할 수 있는가? public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { elements = new Object[D..

짧은 코멘트 스프링을 사용하는 개발자라면, 생성비용이 아주 비싼 객체를 캐싱하고 있는 컴포넌트를 빈으로 등록해 활용할 수 있다. JPA를 사용할때는 Auto boxing을 사용할 수 있다. (DB column에 들어가는 null을 표현하기 위해) 하지만 연산이 들어가기 전에 가능한 빨리 primitive type으로 바꿔주는 것이 좋다. Long과 long 연산 단위가 수만회를 넘어가면 차이가 꽤 큰 것을 확인할 수 있다. String과 StringBuilder 역시 불필요한 객체 생성을 하는 예시라 할 수 있다. 불필요한 객체 생성을 피해라 String s = new String("JAVA"); String s = "JAVA"; 첫 번째 코드보다 두 번째 코드가 좋다. 두 번째 코드는 새로운 인스턴스를..