java

이펙티브 자바 - 4장. 클래스와 인터페이스

4장 - 클래스와 인터페이스 💡 클래스와 멤버의 접근 권한을 최소화하라 “접근 권한을 가능한 한 좁히자” 1. 정보 은닉(캡슐화) 어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 “클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐”다. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨기며 오직 API를 통해서 다른 컴포넌트와 소통함. → 정보은닉(캡슐화) 정보 은닉의 장점 컴포넌트를 병렬로 개발할 수 있음 → 시스템 개발 속도↑ 컴포넌트 교체 부담↓ → 시스템 관리 비용↓ 외부에 거의 의존하지 않고 독자적으로 동작할 수 있는 컴포넌트 → 소프트웨어 재사용성↑ 시스템 전체가 완성되지 않았어도 개별 컴포넌트 동작 검증 가능 → 시스템 제작 난이도↓ 자바에서 ..

이펙티브 자바 - 3장. 모든 객체의 공통 메서드

3장 - 모든 객체의 공통 메서드 💡 equals는 일반 규약을 지켜 재정의하라 “꼭 필요한 경우가 아니면 equals를 재정의하지 말자” 1. 재정의를 최대한 피하자 equals 메서드는 재정의하기 쉬워 보이지만 곳곳에 함정이 도사리고 있음 문제를 회피하는 가장 쉬운 길은 아예 재정의하지 않는 것 많은 경우에 Object의 equals가 비교적 정확히 수행해 줌 2. equals 재정의가 필요한 상황 객체 식별성이 아니라 논리적 동치성을 확인해야 하는데, 상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의되지 않았을 때. 객체 식별성 : 두 객체가 물리적으로 같은가(주소), == 연산자로 확인 논리적 동치성 : 값이 같은가?, equals 메서드로 확인 주로 Integer, String처럼 ..

이펙티브 자바 - 2장. 객체 생성과 파괴

2장 - 객체 생성과 파괴 💡 생성자 대신 정적 팩터리 메서드를 고려하라 “정적 팩터리를 사용하는 게 유리한 경우가 더 많으므로, 무작정 public 생성자를 제공하던 습관이 있다면 고치자” 1. 정적 팩터리 메서드 그 클래스의 인스턴스를 반환하는 단순한 정적 메서드 ex) Boolean.valueOf 메서드 public static Boolean valueOf(boolean b) { return b ? Boolean.TRUE : Boolean.FALSE; } 2. 정적 팩터리 메서드의 장점 5가지 a) 이름을 가질 수 있다. 생성자 BigInteger(int, int, Random)과 정적 팩터리 메서드 BigInteger.probablePrime 중 어느 쪽이 ‘값이 소수인 BigInteger를 반환..