JAVA/effective java

(24.04.00) Item68: 일반적으로 통용되는 명명 규칙을 따르라. ## (24.04.00) Item67: 최적화는 신중히 하라. ## (24.04.00) Item66: 네이티브 메서드는 신중히 사용하라. ## (24.04.00) Item65: 리플렉션보다는 인터페이스를 사용하라. ## (24.04.16) Item64: 객체는 인터페이스를 사용해 참조하라. ##클래스를 타입으로 사용 금지 리턴, 변수, 필드, 파라미터 타입 모두 해당. 인터페이스 타입으로 선언해라. ##다만 구현체를 갈아끼울 때 조심하자. 예를들면 A클래스의 반복자의 특정 순회 정책에 따라 주변 코드가 동작하는 상황에서, B클래스로 갈아끼우면 순회 순서를 보장하지 않아 문제가 될 수 있다. 갈아끼울 구현체는 같은 기능을 제공하고 ..

✨ 상수 인터페이스를 사용하지 말자 인터페이스는, 구현체 인스턴스를 참조할 수 있는 타입 역할을 한다. 오직 이 용도로만 사용해야 한다! 이 지침에 맞지 않는 안티패턴은 '상수 인터페이스'이다. 상수 인터페이스는 내부 구현에 static final 필드로만 가득 찬 인터페이스다. 자바 플랫폼에도 java.io.ObjectSteamConstants 등 상수 인터페이스가 몇 개 있지만, 따라해서는 안된다. 잘못 활용한 것이므로.. 구현체가 이런 상수 인터페이스를 implements 하면 이 상수들에 종속된다. 만약 다음 릴리즈에서 상수들을 사용 안 할 거여도, 호환성을 위해 여전히 상수 인터페이스를 구현하고 있어야 한다는 문제가 생긴다. final이 아닌 클래스가 상수 인터페이스를 구현한다면, 모든 하위 클..

솔직히 이번에 공부한 내용이 와닿지 않는다. 이번 Item은 다시 학습해야 한다. 그런데 일단 래퍼클래스의 이점을 취하는 이야기가 또 나와서 좀 이 래퍼 클래스에 대해 알고 싶고, 자바의 AbstractXXX가 골격 구현 개념과 관련 있다는 것을 인지했다. 일단 내가 전체적으로 잘 모르는 것 같고, 아래 설명 중 Object 메서드들은 디폴트 메서드로 제공해서는 안 되므로, 해당 메서드들은 모두 골격 구현 클래스에 구현한다는 것도 와닿지 않는다. 재학습 대상 아이템으로 두자! ✨ 추상 클래스보다는 인터페이스를 우선하라. 자바8부터 인터페이스도 default method를 제공하므로, 인터페이스와 추상클래스 모두 '구현 메서드'를 제공할 수 있다. 다만 추상 클래스 방식은 좀 제약이 걸리는 것이, 자바는 ..

🪄 상속용 클래스는 신경써라 상속용 클래스는 반드시 상속을 염두에 두고 설계해야 한다(Item18). 이번 아이템에서는 상속을 고려한 설계와 문서화가 뭔지 공부한다. 상속을 허용할 클래스는, 클래스에서 재정의 가능 메서드를 호출할 수 있는 모든 상황을 문서로 남겨야 한다. 클래스의 API로 공개된 메서드에서, 클래스 자신의 또 다른 메서드를 호출할 수도 있다(자기사용). 그런데 만약 '재정의 가능 메서드'를 호출하는 형태라면, 호출하는 메서드의 API 설명에 그 사실을 적시해야 한다. 어떤 순서로 호출하는지, 각 호출 결과가 처리에 어떤 영향을 주는지 말이다. *재정의 가능이란?: public과 protected 메서드 중 final이 아닌 모든 메서드다. *백그라운드 스레드나 정적 초기화 과정에서도 호..

🪄 상속은 캡슐화를 깨뜨린다 상속은 좋은 의도로 사용된다. 1. 공통 코드를 재사용하여 중복 줄임 2. 유지보수, 확장, 유연함 등.. 그런데 상속이 캡슐화를 깨뜨린다라.. 무엇을 이야기하는 걸까? 하위 클래스들이 "상위 클래스의 변화에 종속되어 끌려다니는" 좋지 못한 상황을 이야기하는 것이다. *만약 상위 클래스가 확장을 잘 고려했고, 문서화도 잘 해두었다면 안전하여 괜찮다. *참고: 상속용으로 설계한 클래스는 하위 클래스를 만들어서 검증해야 한다. . . 상속은 상위클래스와 하위클래스가 순수한 is-a 관계일 때만 써야 한다. 무엇보다도 상속 관계는 is-a 및 is kind of 관계, 컴포지션은 has-a 및 is part of 관계라고도 할 수 있다. 예를 들어 Car is-a Automobil..

불변 클래스 불변 클래스는 내부 값을 수정할 수 없는 클래스다. 즉 불변 인스턴스에 간직된 정보는 고정되어, 객체가 파괴되는 순간까지 절대 변하지 않는다. 또한 불변 클래스는 가변 클래스보다 설계, 구현, 사용이 쉬우며, 오류의 여지가 적어 안전하다. 자바에서도 다양한 불변 클래스가 있는데, String, BigInteger, BigDecimal이 있다. . . ─ 불변 클래스가 따르는 5가지 규칙 1. 객체의 상태를 변경하는 Setter를 제공하지 않는다. 2. 클래스를 확장할 수 없도록 한다. - 하위 클래스에서 실수로, 악의로 객체의 상태를 변하게 하는 사태를 막아야 함 - 상속을 막는 대표적인 방법은 final 클래스로 선언하는 것이고, 다른 방법도 뒤에서 언급할 것임 3. 모든 필드를 final..

필드를 노출하면 캡슐화가 깨진다 public 클래스에는 절대 가변 필드를 직접 노출해서는 안된다. (불변 필드도 안심할 수 없다.) 하지만 package-private 클래스나 private 중첩 클래스에서는 종종 필드를 필드를 노출하는 편이 나을 때도 있다. 일단 public 클래스에서 데이터 필드에 직접 접근한다면 캡슐화가 깨지는 것이다(Item15). 그렇게 되면 단점이 많은데, 불변식을 보장할 수도 없고, 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다. 그래서 필드는 모두 private으로 바꾸고, 접근자(getter) 및 변경자(mutator, setter)를 두는 방식으로 개선할 수 있다. 노출해도 되는 상황이 있나요? 하지만 pakage-private 클래스 혹은 private 중..

캡슐화 잘 설계된 컴포넌트의 기본은 내부 정보를 외부로부터 잘 은닉하기! 즉 캡슐화이다. 내부 구현을 완벽히 숨겨서 "구현"과 "API"를 깔끔히 분리하는 것이다. 소프트웨어 설계의 근간이다! 항상 고민하도록 하자. 캡슐화 장점은 간단히.. - 시스템 개발 속도를 높인다. - 시스템 관리 비용을 낮춘다. - 캡슐화 자체가 성능을 높여주진 않으나 최적화에 도움을 준다. (다른 컴포넌트에 영향 주지 않고 해당 컴포넌트만 최적화 가능) - 재사용성을 높인다. - 큰 시스템 제작 난이도를 낮춘다. 접근 제한자를 잘 다루는 것이 중요 private, protected, public ... 을 잘 활용하는 것이 캡슐화의 핵심이다! 기본 원칙은 간단하다. "모든 클래스와 멤버의 접근성을 가능한 좁혀야 한다"는 것이다..

최적화의 어두운 진실 최적화는 해로운 결과로 이어지기 쉽다. 빠르지도, 제대로 동작하지도 않고, 수정하기도 어려운 소프트웨어를 탄생시킬 수 있다. 성능 때문에 견고한 구조를 희생하지 말자. 빠른 프로그램보다는 좋은 프로그램을 작성하라. 좋은 프로그램은 정보 은닉 원칙을 따르므로, 구성요소의 각 내부를 독립적으로 재설계 가능하다(Item15) . . 책에서는 "모든 사람이 마음 깊이 새겨야 할 최적화 격언 세 개"를 소개하고 있다. 이 격언들은 자바가 탄생하기 20년 전에 나온 것으로, 최적화의 어두운 진실을 이야기해준다. (맹목적인 어리석음을 포함해) 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨터 죄악이 더 많다(심지어 효율을 높이지도 못하면서). ─ 윌리엄 울프 (전체의 97% 정도인) 자그마..

네이티브 메서드 네이티브 메서드란, C나 C++같은 네이티브 프로그래밍 언어로 작성한 메서드를 말한다. 자바 네이티브 인터페이스(JNI)는 자바 프로그램이 그런 네이티브 메서드를 호출하는 기술이다. 네이티브 메서드의 주요 쓰임 1. 레지스트리 같은 플랫폼 특화 기능을 사용할 때 └ 필요성 줄어드는 중임: 자바가 성숙해가면서 하부 플랫폼(OS 등)의 기능들을 점차 흡수중 2. 네이티브 라이브러리(네이티브 코드로 작성된)를 사용할 때 └ 네이티브 라이브러리는 특히 GNU 다중 정밀 연산 라이브러리(GMP)를 필두로 개선 작업 계속되어옴 └ 고성능 다중 정밀 연산이 필요하다면, 네이티브 메서드를 통해 GMP를 사용하는 것을 고려해도 좋음 3. 성능 개선을 목적으로 사용함 └ 비권장: 요즘 자바는 다른 플랫폼에..