꾸준한 연습장

개요 class Point { public double x; public double y; } 위같은 클래스는 필드에 직접 접근이 가능하므로 다음과 같은 캡슐화의 이점을 제공하지 못 한다. 1. API를 수정하지 않고 내부 표현을 바꿀 수 없다. 필드의 수정이 필요할 경우 구현의 세부사항이 외부로 노출되어 있기 때문에 API를 수정해야 한다. 이미 외부에서 해당 필드를 직접 사용하고 있을 경우 API 수정이 어렵게 되어 유지보수가 힘들어진다. 2. 불변식을 보장할 수 없다. 외부에서 직접 가변 데이터 필드에 접근할 수 있으므로 불변식을 보장할 수 없다. 모든 필드를 public final 로 선언한다면 불변식을 보장할 수 있지만, 1번과 동일한 문제가 남아있게 된다. 3. 외부에서 필드에 접근할 때 부수..

개요 Object 클래스에서 기본으로 작성된 toString 메서드는 PhoneNumber@adbbd 처럼 단순히 '클래스 이름@16진수 해시코드' 로 반환한다. // Object의 toString 기본 메서드 public String toString() { return getClass().getName() + "@" + Integer.toHexString(hashCode()); } 하지만 위에서 언급한 형태보다는 010-1234-5678 처럼 실제 그 클래스의 핵심적인 정보를 읽기 쉬운 형태로 제공하는 것이 좋을 것이다. 이는 toString의 일반 규약이고, 실제로 모든 Object의 하위 클래스는 toString을 재정의하라고 규약을 정의하고 있다. 개발자가 직접 toString을 사용하지 않더라도..

개요 프로젝트 내에 정적 메서드와 정적 필드만을 담은, 예를 들면 java.lang.Math나 java.util.Arrays 같은 클래스를 생성하고 싶을 수 있다. 이러한 유틸리티 클래스는 인스턴스로 만들어 사용하고자 하는 것이 아니지만, 생성자를 명시하지 않으면 컴파일러가 자동으로 매개변수가 없는 기본 생성자를 만들어주기 때문에 인스턴스화될 여지가 있다. 따라서 생성자를 private으로 선언해줌으로써 인스턴스화를 방지할 수 있다. 아이템 1에서 소개되었던 내용이기도 하다. 만약 클래스를 추상 클래스로 만든다면 인스턴스화되지 않기는 하지만, 이는 완벽하게 인스턴스화를 막는 방법이 아니다. 클래스를 상속해서 인스턴스화 하면 되기 때문이다. 그리고 이런 방법은 명시적인 설명이 없다면 오히려 상속해서 사용하..

개요 현재 진행하는 중인 프로젝트의 한 기능이 로컬 환경, 심지어 고객사에서도 문제 없이 작동하다가 Dev 서버에서는 갑자기 위같은 오류가 발생하며 작동하지 않는 이슈가 있었다. 따라서 코드 문제는 아닌 것 같고 환경 설정이나 버전 관련 문제인 줄 알았는데, crypto API는 https 환경에서만 작동하는 것이 원인이었다. localhost는 secure origin으로 판단되기 때문에 로컬 환경에선 문제없이 작동했고 고객사 홈페이지 또한 도메인을 따 https 연결을 사용하고 있었으니 정상 작동하였는데, dev 서버는 http 연결을 사용했기 때문에 위같은 오류를 뱉는 것이었다. 해결 uuid 를 생성하는 메서드가 있는 다른 라이브러리 사용 직접 uuid를 생성하는 메서드 작성 필자는 다행히 프로젝..

개요 싱글턴(singleton)이란 디자인 패턴 중 하나로, 인스턴스를 오직 하나만 가질 수 있도록 보장하는 클래스를 말한다. 싱글턴의 예로는 무상태(stateless) 객체나 설계상 유일해야 하는 시스템 컴포넌트를 들 수 있다. @Service, @Controller 등으로 생성되는 스프링 빈 또한 싱글턴의 일종이다. 싱글턴을 생성하는 방법은 여러 가지가 있는데, 아래 3가지 방식에 대해 소개한다. public static final 필드 방식(Eager Initialization) 정적 팩터리 방식 열거 타입 방식(Enum Initialization) 1번과 2번 방식이 싱글턴을 만들 때 일반적으로 사용되지만, 이펙티브 자바의 저작자는 열거 타입 방식이 대부분의 상황에서 가장 좋은 방법이라 말한다. ..

개요 생성자와 정적 팩터리 메서드에는 공통적인 제약이 하나 있는데, 바로 매개변수가 많을 경우 적절히 대응하기 힘들다는 점이다. 식품 포장의 영양정보를 표현하는 클래스가 있다고 가정하자. 이 클래스에는 다양한 영양 정보를 표시하기 위해 수많은 필드들이 있을 것이다. 만약 특정 식품 포장에 영양정보를 표현하기 위해 이 클래스를 사용한다면 대부분의 제품은 필수 값을 제외하고 선택 항목들의 값이 0이 될 것이다. 위와 같은 문제를 해결하기 위해 다음과 같은 대안이 있다. 점층적 생성자 패턴(telescoping constructor pattern) 자바 빈즈 패턴(JavaBeans pattern) 빌더 패턴(Builder pattern) 빌더 패턴이 가장 권장되는 것처럼 제목에서부터 언급하지만, 그 이유를 알..

개요 클래스의 새로운 인스턴스를 얻으려고 할 때 보통은 생성자를 이용한다. 하지만 특정 상황에 따라 생성자 대신 '정적 팩터리 메서드'를 통해 인스턴스를 반환하는 것을 고려해볼 수 있다(디자인 패턴의 팩터리 메서드 패턴과는 관계가 없다). 정적 팩터리 메서드가 생성자보다 무조건 좋은 것은 아니며, 경우에 따라 둘 중 하나 또는 두 가지 모두 제공할 수 있다. 정적 팩터리 메서드를 사용할 경우 아래와 같은 장단점이 존재한다. 장점 1. 메서드명, 즉 이름을 가질 수 있다. 2. 호출될 때마다 새로운 객체를 생성할 필요가 없다. 3. 반환 타입의 하위 타입 객체를 반환할 수 있다. 4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다. 5. 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체..

서론 프로젝트를 진행하며 더미 데이터를 검출 후 제거하는 기능이 추가되었고, 이를 테스트할 데이터를 쌓는 일이 필요해졌다. 단, 테스트를 진행하여 데이터를 정제하면 다음 번 테스트를 위해 다시 데이터를 쌓아야 하기 때문에, 스키마를 통째로(데이터 포함) 백업한 뒤 복원하는 것이 좋겠다고 판단했다. 시행착오를 다시 거치지 않기 위해 InteliiJ IDE 환경에서 PostgreSQL의 데이터베이스 및 스키마 백업/복원을 손쉽게 하는 방법을 기술한다. 개요 테스트를 반복하기 위해 데이터를 백업 및 복원할 때 많은 시간이 소요되면 작업 효율성이 떨어질 수밖에 없다. 따라서 보다 빠르게 백업 및 복원할 수 있는 이진 형식으로 dump 파일을 생성하여 저장하기로 결정했다. 해당 방법으로 복원하기 위해선 psql ..

오류 메시지 more than one row with the given identifier was found 원인 @OneToOne 으로 관계가 매핑된 Entity에 동일한 식별자를 가진 데이터가 중복으로 들어갔기 때문에 발생하는 예외였다. OneToOne 이므로 특정 id로 데이터를 조회했을 때 한 개만 조회되어야 하는데, 여러개가 조회되기 때문이다... 해결 중복된 데이터를 DB에서 제거하여 해결이 가능했다. 또한 해당 컬럼에 Constraint Key를 걸어주어 재발 방지가 가능하였다.

개요 개발 중 이슈가 생겨 디버깅을 하던 도중, Long 과 Long 타입을 비교하는 구문에서 서로 두 값이 동일함에도 불구하고 간헐적으로 true가 아닌 false 가 반환되는 현상을 확인하였다. 원인 확인 결과, == 연산자와 equals 의 차이에서 오는 문제였다. 원인 Java에서 객체 비교는 대표적으로 == 연산자와 equals() 메서드를 사용하여 수행할 수 있다. == 연산자는 객체의 주소값을 비교하기 때문에 같은 값을 가지고 있어도 주소값이 다르다면 false를 반환한다. 단, 위에서 언급했듯 간헐적으로 값을 정상적으로 비교할 수 있었던 이유는 Java에서 Long과 Integer의 경우 값을 -128부터 127까지의 범위에 대해 캐시하고 있기 때문에 동일한 주소의 객체로 인식하기 때문이다..