Home
Youngho's Devlog
Cancel

[이펙티브자바] 아이템16-public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

객체 지향 프로그래머는 필드를을 모두 private으로 바꾸고, public 접근 제어자(getter)를 추가한다. // 이처럼 툅환 클래스는 public이어선 안된다. class Point { public double x; public double y; } 위와 같은 클래스는 데이터 필드에 직접 접근할 수 있으니 캡슐화의 이점을 제공하지...

[이펙티브자바] 아이템15-클래스와 멤버의 접근 권한을 최소화하라

컴포넌트 설계 어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스의 내부 데이터와 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐이다. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는...

[Spring] Spring Data JPA 멀티 테넌시

출처 https://velog.io/@gaegulgaegul/Spring-Data-JPA-%EB%A9%80%ED%8B%B0-%ED%85%8C%EB%84%8C%EC%8B%9C

[이펙티브자바] 아이템14-Comparable을 구현할지 고려하라

Comparable 인터페이스란? Comparable 인터페이스는 객체를 정렬하는데 사용되는 메서드인 compareTo를 정의하고 있다. Comparable 인터페이스를 구현한 클래스는 반드시 compareTo를 정의해야 한다. Comparable 인터페이스 특징 자바에서 같은 타입의 인스턴스를 비교해야만 하는 클래스들은 모두 Com...

[이펙티브자바] 아이템13-clone 재정의는 주의해서 진행하라

Cloneable 인터페이스를 구현하는 모든 클래스는 clone을 재정의해야 한다 이때 접근 제한자는 public으로, 반환 타입은 클래스 자신으로 변경한다. 이 메서드는 가장 먼저 super.clone을 호출한 후 필요한 필드를 전부 적절히 수정한다. 일반적으로 이 말은 그 객체의 내부 깊은 구조에 숨어 있는 모든 가변 객체를 복사하고,...

[이펙티브자바] 아이템12-toString을 항상 재정의하라

toString의 일반 규약에 따르면서 ‘간결하면서 사람이 읽기 쉬운 형태의 유익한 정보’를 반환해야 한다. Object의 toString을 재정의하지 않고 사용할 경우 아래와 같이 클래스명@16진수로 표시한 해시코드로 나타나게 된다. 이는 해당 객체가 어떤 상태인지 어떤 정보를 담고 있는지를 전혀 알 수 없다. 또한 toStri...

[이펙티브자바] 아이템11-equals를 재정의하려거든 hashcode도 재정의하라

equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet과 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다. Object 명세에서 언급하는 hashcode 규약 equals 비교에 사용되는 정보가 변경...

[이펙티브자바] 아이템10-equals는 일반 규약을 지켜 재정의하라

equals 메서드를 재정의 하지 않을 때는 언제인가? equals 메서드는 재정의하기 쉬워보이지만 곳곳에 함정이 도사리고 있음, 그러기에 자칫 하면 끔찍한 결과를 초래 문제를 회피하는 방법은 아예 재정의하지 않는 것, 그 클래스의 인스턴스는 오직 자기 자신과만 같게됨 그게 언제일까? 1) 각 인스턴스가 본질적으로 고유 할 때 값...

[학습할래][JPA-Episode2] 영속성 컨텍스트

이전 JPA 에피소드 1탄에서 SQL 중심적인 개발의 문제점과 JPA를 왜 써야하는지?에 대해서 알아보았는데요, 또한 JPA에서 가장 중요한 2가지를 언급드렸었습니다. 1) 객체와 관게형 데이터베이스 매핑하기(Object Relational mapping) DB를 어떻게 설계하고 객체를 어떻게 설계해서 중간에 어떻게 JPA로...

[이펙티브자바] 아이템9-try-finally보다는 try-with-resources를 사용하라

자바에선 InputStream, OutputStream, java.sql.Connection 등과 같은 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많다. 이는 예측할 수 없는 성능 문제로 이어지기도 한다. 전통적으로 자원이 제대로 닫힘을 보장하는 수단으로 try-finally가 있다. 예외가 발생하거나 메서드에서 반환되는 경우를...