불변 클래스란? 그 인스턴스의 내부 값을 수정할 수 없는 클래스로, 인스턴스 내 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대로 변경되지 않는다. 예) 자바 플랫폼 라이브러리에는 String과 기본타입의 박싱된 클래스인 BigInteger와 BigDecimal이 여기 속한다. 불변 클래스의 장점 설계 및 구현 용이 낮은 오류 발생률 불변 클래스 생성에 대한 다섯 가지 규칙 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다. 클래스를 확장할 수 없도록 한다. 하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 만드는상태를 막아준다. 대표적인 방법으로 class의 final 선언이 있다. 모든 필드를 final로 선언한다. 시스템이 강제하는 수단을 통해 설계자의 의도를 명확히 드..
클래스나 필드를 아무 이유 없이 public으로 선언한다면? 캡슐화의 이점을 제공하지 못함. API를 수정하지 않고는 내부 표현 수정 불가 불변식 보장 불가 외부에서 필드에 접근할 때 부수 작업을 수행할 수 없음 → 필드의 접근 제한자를 public → private 변경 및 setter, getter 추가를 통해 패키지 외부에서 접근하는 클래스에게 접근자 제공. 주의사항.package-private 클래스 혹은 private 중첩 클래스라면 데이터 필드를 노출한다 해도 문제 없으며 그 클래스가 표현하는 추상 개념만 올바르게 표현하면 문제 없음. 클라이언트 코드가 클래스 내부 표현에 묶이기는 하지만, 클라이언트도 어차피 이 클래스를 포함하는 패키지 안에서만 동작하는 코드이기 떄문이다.
어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 차이점 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐의 차이. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다. 정보 은닉 혹은 캡슐화는 소프트웨어 설계의 근간이 된다. 정보은닉의 장점 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다. 각 컴포넌트간 영향을 주지 않기 때문에 가능하다. 시스템 관리 비용을 낮춘다. 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담이 적기 때문이다. 특정 기능을 개선해야할 때 관련 컴포넌트만 분석하여 개..
이번 아이템에서는 Comparable 인터페이스의 비교, 정렬, 제네릭이란 특성을 가진 메서드인 compareTo()에 대해 알아보겠다. compareTo는 단순 동치성 비교에 더해 순서까지 비교할 수 있으며, 제네릭하다. Comparable을 구현했다는 것은 그 클래스의 인스턴스들에는 자연적인 순서가 있음을 뜻한다. Comparable을 구현한 Collections와 Arrays 등의 객체의 배열은 다음처럼 쉽게 정렬할 수 있다. Arrays.sort(/* 배열 객체*/); Collections.sort(/* 컬렉션 하위 객체*/);그 외에도 검색, 극단값 계산, 자동 정렬되는 컬렉션 관리도 쉽게할 수 있다.아래는 중복 제거 후 알파벳으로 출력하는 코드다. /* [code] Item14_Main.jav..
toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다. 오류 메시지 로깅시 자동으로 호출되여 명확한 상황이 남기 때문이다. 실전에서 toString은 그 객체가 가긴 주요 정보 모두를 반환하는게 좋다. 또한 toString을 구현할 때면 반환값의 포맷을 문서화할지 정해야 한다. 전화번호나 행렬같은 값 클래스라면 문서화하기를 권한다. 그 값 그대로 입출력에 사용하거나 CSV 파일처럼 사람이 읽을 수 있는 데이터 객체로 저장할 수도 있다. 포맷을 명시한다면, 명시한 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는정적 팩토리나 생성자를 함께 제공해주면 좋다. 포맷을 명시하게 될 경우 단점은 평생 그 포맷에 얽매이게 된다. 포맷을 명시하든 아니든 toStr..
equals를 재정의 했을 때 hashcode도 재정의 해야하는 이유 재정의 하지 않을 시 hashcode 일반 규약을 어기게되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다. 아래는 object 명세에서 발췌한 규약이다. equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashcode 메서드는 몇번을 호출 해도 일관되게 같은 값을 반환해야한다. 단, 애플리케이션 재 실행시에는 값이 변경되어도 상관 없다. equals(object)가 두 객체를 같다고 판단했다면, 두 객체의 hashcode는 똑같은 값을 반환해야 한다. equals(object)가 두 객체를 다르다고 판단했더라도, 두 객체의 ..
equals 재정의시 주의사항 equal 메서드는 재정의 하기 쉬워 보이지만 자칫하면 끔직한 결과를 초래한다. 아래 케이스에 해당하면 재정의를 하지말자. 각 인스턴스가 본질적으로 고유하다. 값을 표현하는게 아니라 동작하는 개체를 표현하는 클래스가 여기 해당한다. 인스턴스의 논리적 동치성(Logical Equality)을 검사할 일이 없다. java.util.regex.Pattern이란 정규식을 담는 클래스를 재정의해서 두 패턴의 인스턴스가 같은 정규표현식을 나타내는지 논리적 동치성을 검사하는 방법도 있지만, 설계자가 원하지 않거나 불필요할 수 있다. 후자의 경우에는 Object의 기본 equals로 충분하다. 상위클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다. 예컨데 Set구현체는 Ab..
자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많다. 대표적으로 inputStream, OutputStream, java.sql.Connection 등이 좋은 예다. 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어진다. 이런 자원 중 상당수가 안전망으로 finalizer를 활용하고는 있지만 finalizer는 그리 믿을만 하지 못하다. 또한 try 문을 중첩해서 사용할 경우 가독성은 급격히 내려간다. try-with-resource 문을 사용하기 위해서는 해당 클래스가 AutoCloseable 인터페이스를 구현해야한다. 이 인터페이스는 단순히 void를 반환하는 close 메서드 하나만 덩그러니 정의한 인터페이스다. 아래는 AutoCloseable을 실..
C, C++처럼 메모리를 직접 관리해야 하는 언어와 달리 자바는 가비지 컬렉터를 갖춘 언어이다. 하지만 그럼에도 불구하고 메모리 누수가 발생한다. 아래 코드가 대표적인 메모리 누수가 일어나는 클래스다. public class Stack { private Object[] elements ; private int size = 0; // ... public Object pop(){ if(size == 0 ){ throw new EmptyStackException(); } return elements[--size]; } // ... }Stack 이란 자료구조는 원래 pop을 하면서 해당 데이터가 내보내는데, 위 코드에서는 size 변수의 값을 1 내림으로써 pop한 데이터를 남긴다. public class St..
똑같은 기능의 객체를 매번 생성하기보다는 객체하나를 재사용하는 편이 나을 때가 많다. 재사용은 빠르고 세련되다. 특히 불변 객체는 언제든 재사용할 수 있다. 불변 객체 객체 내부의 변수값을 변경할 수 없는 객체 아래 코드를 보자. String s = new String("jordy"); 이 문장을 실행될 때마다 String 인스턴스를 새로 만든다. 이를 대신하여 직접 문자열을 할당할 경우에 기존 메모리에 저장되어있던 데이터를 재사용이 할 수 있다. hashcode(객체가 저장된 메모리 주소) 메서드를 사용하여 아래와 같이 비교해보면 확인 가능하다. String jordy = "niniz"; String scappy = "niniz"; System.out.println(jordy.hashCode() == ..
- Total
- Today
- Yesterday
- Delete
- POD
- k8s
- Java Memory Structure
- 자바 메모리 구조
- Java
- Replication Controller
- Effective Java
- JMM
- JVM
- kubernetes
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |