* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 18. 추상 클래스 대신 인터페이스를 사용하라 자바에는 여러가지 구현을 허용하는 자료형을 만드는 두 가지 방법이 있다. 바로 인터페이스와 추상 클래스 추상 클래스(abstract class)는 구현된 메서드를 포함할 수 있지만 인터페이스는 그럴 수 없다. * 자바 1.8부터 인터페이스도 default / static 메서드를 통해 미리 메서드를 구현해둘 수 있게 되었다. (default 메서드는 재정의가 가능하고, static 메서드는 재정의가 불가능하다.) 인터페이스는 인터페이스에 포함된 모든 메서드를 정의하고 인터페이스가 규정하는 일반 규약을 지키기만 하면 되고, 또한 인터페이스를 통한 다중 상속도 가능하다. 반면 추상 클래스가 규정..
* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 15. 변경 가능성을 최소화하라 변경 불가능(immutable) 클래스는 그 객체를 수정할 수 없는 클래스이다. - 대표적으로 String 클래스, Wrapper 클래스, BigInteger 클래스 등등... - 객체 내부의 정보는 객체가 생성될 때 주어지며, 객체가 살아있는 동안 변경되지 않고 그대로 보존된다. -> 변경 가능 클래스에 비해 설계하기 쉽고, 구현하기 쉬우며 오류 가능성도 적고 안전하다. 1. 객체 상태를 변경하는 메서드(수정자, setter 등)를 제공하지 마라 2. 계승(상속)할 수 없도록 해라 - 잘못 작성되거나, 악의적인 하위 클래스가 객체상태가 변경된 것 처럼 동작해서 불변성을 깨뜨리는 일을 방지할 수 있다. -..
* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 14. public 클래스 안에는 public 필드를 두지말고 접근자 메서드를 사용하라 데이터 필드를 외부에서 직접 조작할 수 있는 클래스는 캡슐화의 이점을 누릴 수 없다. - API를 변경하지 않고서는 내부 표현을 변경할 수 없고, 불변식도 강제할 수 없고, 필드를 사용하는 순간에 어떤 동작이 실행되도록 만들 수도 없다. -> private 필드와 public 접근자 메서드(getter)로 변경하라! (변경 가능 클래스라면 수정자 메서드(setter)도 같이..) = 꼭 getter/setter 메서드가 아니더라도, 메서드를 통해서만 필드에 접근/변경이 가능하도록 만들어라!! @Getter @Setter public class Poin..
* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 13. 클래스와 멤버의 접근 권한은 최소화하라 잘 설계된 모듈과 그렇지 못한 모듈을 구별짓는 가장 중요한 속성 중 하나는, 모듈 내부의 데이터를 비롯한 구현 세부사항을 다른 모듈에게 잘 감추느냐의 여부이다 - 잘 설계된 모듈은 구현 세부사항을 전부 API 뒤에 감춘다. 모듈들은 서로 API를 통해서만 통신하며, 각자 내부적으로는 무슨 일을 하는지 신경 쓸 필요가없다. (캡슐화, 은닉화) -- 소프트웨어 설계의 기본 원칙. 정보 은닉이 중요한 이유는 정보 은닉이 시스템을 구성하는 모듈 사이의 의존성을 낮춰서 각자 개별적으로 개발/시험/최적화/이해/변경이 가능하도록 해주기 때문이다. 병렬적 개발을 가능하게 만들어 주고, 시스템이 완성된 다음..
* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 10. toString은 항상 재정의하라 잘 만들어놓은 toString은 클래스를 좀 더 쾌적하게 사용할 수 있도록 도움을 준다. - 가능하면 toString 메서드는 객체 내의 중요 정보를 전부 담아 반환해줘야 한다. toString을 따로 재정의하지 않으면 Object에 정의된 toString 메서드가 사용되는데 이는.. public String toString() { return getClass().getName() + "@" + Integer.toHexString(hashCode()); } - 클래스 이름@16진수 해시코드가 출력되게 된다. 썩 마음에 들지가 않는다 - 모든 하위 클래스는 이 메서드를 재정의함이 바람직하다. 사람이..
4. 객체 생성을 막을 때는 private 생성자를 사용하라 정적 메소드나 필드를 모아놓고 사용하는 유틸리티 클래스의 경우는 객체를 만들 목적의 클래스가 아니다 - 대표적으로 java.lang.Math, java.util.Arrays, java.util.Collections 객체를 만들 생각이 없다고 생성자를 만들지 않으면.. 객체 생성을 막을 수 있는 것이 아니라 디폴트 생성자가 만들어진다. * 디폴트 생성자: 객체가 생성될 때 사용자가 초깃값을 명시하지 않으면 컴파일러가 자동으로 생성해주는 생성자 - NoArgsConstructor와 같음 클래스를 abstract로 추상 클래스로 만든다고 해도 소용없다. -> 하위 클래스를 정의하면 객체 생성이 가능해지기 때문. 그럼 어떻게? => private 생성..
3. private 생성자나 enum 자료형은 싱글톤 패턴을 따르도록 해라 (중요) 여기서의 싱글톤 패턴은 스프링 컨테이너에 의해 관리되는 싱글톤이 아니기에, 안티패턴의 문제점을 갖고있는 싱글톤임을 참고!! # 싱글톤 패턴이 안티패턴으로 불리는 이유 ========= 1. private 생성자를 갖고있어 상속 불가 2. 테스트 하기 어려움 (목 객체로 대체할 수 없음) 3. 객체지향의 의도와 전혀 맞지않음 => 위 문제점들은 스프링에서는 "스프링 컨테이너"의 활약으로 모두 해결된다 ========================================== 싱글톤은 생성자를 private로 선언해두고, 싱글톤 객체는 정적 팩토리 메서드( getInstance() )를 이용하거나, 정적 필드를 통해 얻어오..
2. 생성자 인자가 많을때는 빌더 패턴 생성자에 들어가는 파라미터 개수가 많을 경우 사용해볼만한 패턴은 다음과 같다 1. 점층적 생성자 패턴 - 필수 인자만 받는 생성자 하나 정의 - 그 이후부터 선택적 인자를 추가해가면서 생성자를 계속 쌓아나가는 방식 - 각 파라미터가 무슨 값인지 의미를 알기 어렵고, 자료형이 같은 인자들끼리 순서를 잘못 넣어 문제를 일으킬 가능성이 상당히 높다. 2. 자바빈 패턴 - 일단 인자 없는 생성자(NoArgsConstructor)를 호출해서 빈 객체를 만듬 - 그 다음에 setter 프로퍼티를 이용해서 값을 하나하나 채워주는 방식 - 1회의 함수 호출로 객체 생성을 끝낼 수 없으므로, 객체의 일관성이 일시적으로 깨질 수 있다. - 변경 불가능(immutable)한 클래스를 ..