Effective Java 검색 결과

해당 글 24건

Effective Java#15 변경 가능성을 최소화 하라

변경 불가능 클래스는 그 객체를 수정할 수 없는 클래스다. 객체 내부의 정보는 객체가 생성될 때 주어진 것이며, 객체가 살아 있는 동안 그대로 보존된다. 자바 플랫폼 라이브러리에는 이런 클래스가 많다. String, 기본 자료형 클래스, Biginteger, BigDecimal 등이 그런 클래스다. 변경 불가능 클래스를 만드는 이유는 다양하다. 우선 변경 불가능 클래스는 변경 가능 클래스보다 설계하기 쉽고, 구현하기 쉽고, 오류 가능성이 적고 더 안전하다. 변경 불가능 클래스를 만들 때 5가지 아래 규칙 1. 객체 생태를 변경하는 메서드(수정자 및 setter)를 제공하지 않는다.2. 계승할 수 없도록 한다. 잘못 작성되거나 악의적인 하위 클래스가 객체 상태가 변경된 것처럼 동작해서 변경 불가능성을 깨뜨..
Effective Java/3장 클래스와 인터페이스 2018. 11. 24. 23:30

Effective Java#14 public 클래스 안에는 public 필드를 두지 말고 접근자 메서드를 사용하라

필드를 모으는 것 말고 아무 기능이 없는 클래스를 만들 때가 있다. 1234class Poing { public double x; public double y;} 이런 클래스는 데이터 필드를 직접 조작할 수 있어서 캡슐화의 이점을 누릴 수가 없다. API를 변경하지 않고서는 내부 표현을 변경할 수 없고, 불편식도 강제할 수 없고, 필드를 사용하는 순간에 어떤 동작이 실행되도록 만들 수도 없다. 객체 지향 개념에 충실하고자 하는 프로그래머에게 이런 클래스는 저주와 같다. private 필드와 public 접근자 메서드getter, setter이 있어야 하고, 변경 가능 클래스라면 생성자와 getter, setter도 제공해야 한다. 선언된 패키지 밖에서도 사용 가능한 클래스에는 접근자 메서드를 제공해야한다..
Effective Java/3장 클래스와 인터페이스 2018. 11. 24. 22:30

Effective Java #7 종료자 사용을 피하라

종료자는 예측 불가능하며, 대체로 위험하고 일반적으로 불필요하다. 종료자를 사용하면 시스템 오류, 성능 문제, 이식성 문제가 발생할 수 있다. 종료자의 단점은 즉시 실행되리라는 보장이 전혀 없다는 것이다. 어떤 객체에 대한 모든 참조가 사라지고 나서 종료자가 실행되기까지는 긴 시간이 걸릴 수도 있다. 따라서 긴급한 작업을 종료자 안에서 처리하면 안된다. 예를 들어 종료자 안에 파일을 닫도록 하면 치명적이다. 종료자 실행 시점은 GC 알고리즘에 좌우되는데, 이 알고리즘은 JVM 마다 크게 다르다. 자바 명세에는 종료자가 즉시 실행되어야 한다는 문구도 없지만, 종료자가 결국에는 반드시실행되어야 한다는 문구도 없다. 따라서 종료자가실행되지 않은 객체가 남은 상태로 프로그램이 끝나게 되는 일도 충분히 가능하다...
Effective Java/1장 객체의 생성과 삭제 2018. 11. 24. 21:30

Effective Java#13 클래스와 멤버의 접근 권한은 최소화 하라

잘 설계된 모듈과 그렇지 못한 모듈을 구별 짓는 가장 중요한 속성 하나는 구현 세부사항을 다른 모듈에 잘 감추느냐의 여부다. 잘 설계된 모듈은 구현 세부사항을 전부 API 뒤쪽에 감춘다. 모듈들은 이 API를 통해서만 서로 통신하며, 각자 내부적으로 무슨 짓을 하는지는 신경쓰지 않는다. 이 개념은 정보은닉 또는 캡슐화라고 하며 잘 알려진 설계 원칙이다. 각 클래스와 멤버는 가능한 한 접근 불가능하도록 만들라. 다시 말해서 개발 중인 소프트웨어의 정상적인 동작을 보증하는 한도 내에서 가장 낮은 접근 권한을 설정하라 ● 최상위 레벨 클래스와 인터페이스에 부여할 수 있는 접근 권한은 package-private와 public 두가지이다. ● 최상위 레벨 클래스너 인터페이스는 가능한 package-private..
Effective Java/3장 클래스와 인터페이스 2018. 11. 24. 21:18

Effective Java #6 유효기간이 지난 객체 참조는 폐기하라

C나 C++ 처럼 손수 메모리 관리를 하다가 GC가 있는 Java를 사용하면 무척이나 편하다. 볼 일 없는 객체는 자동적으로 반환되기 때문에 메모리 관리가 필요하다는 사실을 망각하게 되는데 잘못된 습관이다.아래 스택 코드에는 뚜렷하게 잘못된 부분이 없다. 아무리 많은 테스트를 하더라도 통과할 것이다 하지만 이 프로그램은 보이지 않는 문제가 있다. 123456789101112131415161718192021222324252627class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { elements = new Object[..
Effective Java/1장 객체의 생성과 삭제 2018. 10. 20. 14:00

Effective Java #5 불필요한 객체는 만들지 마라

기능적으로 동일한 객체는 필요할 때마다 만드는 것보다 재사용하는 편이 더 낫다. 객체를 재사용하는 프로그램은 더 빠르고 우아하다. 변경 불가능 객체는 언제나 재사용할 수 있다. 절대로 피해야 할 극단적 예를 하나 들어보자. 아래 예제를 실행될 때마다 String 객체를 만드는데, 쓸데 없는 짓이다. 생성자 호출로 만들어 지는 모든 객체와 기능이 같다. 만일 아래 문장이 순환문이나 자주 호출되는 메서드 안에 있다면 수백만 개의 String 객체가 만들어 질 것이다. 아래 코드에서 5번과 같이 사용하는 것이 바람직하다. 12345//최악의 코드String str = new String("Effective Java"); //바람직한 코드String str = "Effective Java"; 5번 라인같이 실행..
Effective Java/1장 객체의 생성과 삭제 2018. 10. 20. 12:37

Effective Java #4 객체 생성을 막을 때는 private 생성자를 사용하라

때로는 정적 메서드나 필드만 모은 클래스를 만들고 싶을 때가 있다. 자바의 기본 자료형 값 또는 배열에 적용되는 메서드를 한군데 모아둘 때 유용하다. java.lang.Math나 java.util.Arrays가 좋은 예다.특정 인터페이스를 구현하는 객체를 만드는 팩터리 메서드 등의 정적 메서드를 모아놓을 때도 사용할 수 있다. java.util.Collections는 그 좋은 예다. 이런 유틸리티 클래스들은 객체를 만들 목적의 클래스가 아니다. 객체를 만들면 이상하다. 하지만 생성자를 생략하면 컴파일러는 자동으로 인자 없는 public 기본 생성자를 만들어 버린다. 사용자는 이 생성자를 일반 생성자와 구별할 수 없다. 따라서 원래 의도와는 달리 객체 생성이 가능한 클래스가 공개 API에 포함되느 일도 드..
Effective Java/1장 객체의 생성과 삭제 2018. 10. 18. 16:30

Effective Java #3 private 생성자나 enum 자료형은 싱글턴 패턴을 따르도록 설계하라

싱글턴은 객체를 하나만 만들 수 있는 클래스다. 싱글턴은 보통 유일할 수 밖에 없는 시스템 컴포넌트를 나타낸다. 창 관리자나 파일 시스템 같은 것들이 그 예다. 그런데 클래스를 싱글턴으로 만들면 클라이언트를 테스트하기가 어려워질 수가 있다. 싱글턴이 어떤 인터페이스를 구현하는 것이 아니면 가짜 구현으로 대체할 수 없기 때문이다. JDK 1.5 이전에는 싱글턴을 구현하는 방법이 두 가지였다. 두 방법 다 생성자는 private로 선언하고, 싱글턴 객체는정적 멤버를 통해 이용한다. 첫 번째 방법의 경우, 정적 멤버는 final로 선언한다. 1234public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() {};}..
Effective Java/1장 객체의 생성과 삭제 2018. 10. 18. 14:17

Effective Java #2 생성자 인자가 많을 때는 빌더 패턴 적용을 고려하라

빌더 패턴에 대한 간략한 개념과 코드를 블로그에 포스팅 한 것이 있다. 그 글을 읽고 나서 아래 글을 읽는 것이 더 좋을 듯하여 링크를 남긴다. 디자인 패턴 - 빌더 패턴(Builder Pattern) 정적 팩터리나 생성자는 같은 문제를 갖고 있다. 클라스 안에 인자가 많은 상황에 잘 적응하지 못한다는 것. 아래 Person 클래스가 있다. 이런 클래스에는 어떤 생성자나 정적 팩터리 메서드가 적합할까? 보통 개발자는 아래의 예제 코드와 같이 점층적 생성자 패턴을 적용한다. 필수 인자만 받는 생성자를 하나 정의하고, 선택적 인자를 하나 받는 생성자를 추가하고, 또 추가하고 계속 추가하여 쌓아 올리는 것처럼 추가하는 것이다. 1234567891011121314151617181920212223242526272..
Effective Java/1장 객체의 생성과 삭제 2018. 10. 17. 16:38

Effective Java #1 생성자 대신 정적 팩토리 메서드를 사용할 수 없는지 생각해 보라

클래스를 통해 객체를 만드는 일반적인 방법은 public으로 선언된 생성자를 사용하는 것이다. 그러나 반드시 알고 있어야 하는 또 하나의 다른 방법은 클래스에 public으로 선언된 정적 팩토리 메서드를 추가하는 것이다. 아래 예제는 기본타입 boolean의 값을 Boolean 객체에 대한 참조로 반환한다. 1234public static Boolean valueOf(boolean b) { return b ? Boolean.TRUE : Boolean.FALSE;} 클래스를 정의할 때 생성자 대신 정적 팩토리 방식으로 메서드를 제공할 수 있다. 생성자 대신 정적 팩터리 메서드를 사용하면 어떤 장점이 있을까 ? 정적 팩터리 메서드의 장점 첫 번째 장점은, 생성자와는 달리 정적 팩터리 메서드에는 이름(name..
Effective Java/1장 객체의 생성과 삭제 2018. 10. 16. 22:14