item34. int 상수 대신 열거 타입을 사용하라int 상수 패턴public static final int APPLE_FUJI = 0;public static final int APPLE_PIPPIN = 1;public static final int APPLE_GRANNY_SMITH = 2;public static final int ORANGE_NAVEL = 0;public static final int ORANGE_TEMPLE = 1;public static final int ORANGE_BLOOD = 2;특정 경우를 상수 값으로 치환하여 표현하는 방식이다.int 상수 패턴의 단점타입 안전을 보장할 방법 x, 표현력도 안 좋음네임스페이스가 없기에 동일한 접두어가 반복됨오렌지와 사과를 대체해도 == ..
item26.로 타입은 사용하지 말라클래스 혹은 인터페이스 선언에 타입 매개변수가 쓰이면 이를 제네릭 타입이라고 한다.제네릭 타입은 일련의 매개변수화 타입을 정의한다.제네릭 타입을 정의하면 그에 딸린 raw type을 정의한다.raw type은 제네릭 타입에서 타입 매개변수를 사용하지 않은 것 ex) List, Set// 제네릭을 지원하기 전엔 컬렉션을 아래와 같이 선언private final Collection stamps = ...;stamps.add(new Coin(...));for (Iterator it = stamps.iterator(); i.hasNext();) { Stamp stamp = (Stamp) i.next(); // ClassCastException stamp.cancel();}..
item15. 클래스와 멤버의 접근 권한을 최소화하라내부 데이터와 내부 구현 정보를 외부로부터 얼마나 잘 숨겼는지가 중요하다정보은닉, 캡슐화라고 함시스템을 구성하는 컴포넌트를 독립시켜 개발, 테스트, 최적화, 적용, 분석, 수정이 개별적으로 가능해야 함장점컴포넌트 간 의존성 x → 독립적인 병렬 개발이 가능 → 개발 속도 증가컴포넌트별 디버깅이 가능 → 관리 비용이 절약컴포넌트별 최적화가 가능 → 성능 최적화 적용이 쉬움컴포넌트 간 의존성 x → 재사용 가능컴포넌트별 테스트 가능 → 제작 난이도 낮아짐컴포넌트 간 의존성을 없애는 것의 핵심이 접근 제한자임 → 가능하면 가장 낮은 접근 수준을 유지private: 멤버를 선언한 톱레벨 클래스에서만 접근 가능package-private: 멤버가 소속된 패키지 ..
item10. equals는 일반 규약을 지켜 재정의하라 equals() 메서드는 객체의 내용이 동일한지 논리적 동치성을 확인하는 메서드이다.equals를 구현하지 않아야 할 때각 인스턴스가 본질적으로 고유할 때인스턴스의 논리적 동치성을 검사할 일이 없을 때상위 클래스에서 재정의한 equals()가 하위 클래스에서도 문제없이 이용 가능할 때equals를 구현해요 할 때상위 클래스에 equals()를 재사용할 수 없고, 객체 간의 논리적 동치성을 구현해야 할 때주로 Integer, String과 같은 값 클래스의 경우.. 등등equals() 메서드의 일반 규약null-아님 : null 이 아닌 모든 참조 값 x에 대해 x.equals(null)은 false이다.반사성 : x.equals(x)는 true이다..
오늘은 이펙티브 자바를 오랜만에 다시 복습하고 중요한 부분만 간단하게 정리할 예정이다. item1. 생성자 대신 정적 팩토리 메서드를 고려하라.객체 생성을 할 때 생성자가 아닌 정적 팩토리 메서드를 객체 생성 용도로 쓰는 것은 경우에 따라 좋다.장점 1: 생성자가 이름을 가질 수 있다.예를 들면 Integer.parseInt()는 정적 팩토리 메서드이다.이름에서 무엇을 의미하는지 파악하기 쉬움 → 의도가 명확함장점 2: 매 호출 시 인스턴스를 새로 생성할 필요가 없다.public final class Boolean implements java.io.Serializable, Comparable{ /** * The {@code B..
마지막 미션은 새로운 주제의 미션이었다. 이번에도 그전과 동일하게 회고의 느낌으로 작성할 예정이다. 내가 고민한 점과 적용한 점 수정했던 부분 및 이유를 작성할 것이다. 고민거리 이번에 enum을 적용해야 하는 상황이 거의 필수적으로 일어났다고 생각했다. 그래서 이를 적용했는데, 문제는 얼마나 나눌 것인가에 대한 고민이었다. 처음에는 카테고리마다 전부 나누고 메뉴판에서 통일하는 방식을 생각했다. 하지만 이러한 방법은 복잡도가 올라간다는 생각도 했고, 입력으로 들어온 값을 찾기가(이름으로 매칭되는 값) 번거롭다는 느낌을 받았다. 물론 분리가 잘되어있다는 생각이 들긴 함. 그래서 한눈에 보기에도 편하고 매칭되는 값을 찾기도 편하게 전부 모아서 관리하였다. 물론 정말 확장 가능성도 생각한다면 다른 방법이 더 ..
우아한테크코스 6기 프리코스 3주 차는 로또였다. 이번에도 그전과 동일하게 회고의 느낌으로 작성할 예정이다. 내가 고민했던 부분과 적용한 점 수정했던 부분을 이유로 작성할 것이다. 미션에서 Randoms.pickUniqueNumberInRange를 사용해야 했기에 이를 먼저 분석했다. validate를 통해 검증을 거치는데, 이때 validate 메서드의 이름이 validateRange로 되어있었다. 네이밍에 대한 고민이 많던 나에게는 큰 도움이 되었다. 범위 내의 숫자를 담고 셔플을 통해 섞은 다음 필요한 크기로 잘라내는 로직이었다. 이런 역할 분리를 보고 각각의 메서드가 하나의 일만 수행하며 적절히 분리되어 있다고 느꼈다. 그동안 정적 팩토리 메서드를 사용하는 모습과 거의 동일하여 이대로 진행하면 되..
우아한 테크코스 6기 프리코스 2주 차는 자동차 경주였다. 이번에도 저번 숫자 야구 게임에 이어서 회고의 느낌으로 작성할 예정이다. 내가 했던 고민과 수정했던 부분에 대한 이유를 주로 작성할 것이다. 고민거리 미션 중에 시도 횟수만큼 반복을 하는데, 이때 이 시도 횟수를 어떻게 처리할지에 대한 고민을 했다. 정확히 말하자면 나는 시도 횟수는 양의 정수여야 한다고 판단했다. 그렇다면 이 값에 대한 검증이 존재해야 하는데 이를 어디서 진행할 것인가? 나는 총 3가지를 고민했다. 첫 번째는 InputValidator였다. 즉 inputView를 받자마자 이를 예외를 검증하는 것이다. 하지만 이는 단순히 시도 횟수만을 위한 검증이라는 생각이 들기도 하였고, InputValidator는 빈 값만 체크하도록 전체 ..
이번에 우아한 테크코스 6기 프리코스에서 숫자 야구 게임을 구현해 보았다. 공통 피드백도 나왔기에 회고의 느낌으로 작성할 예정이다. 평소에도 객체지향에 관심이 많았고, 이를 충분히 적용하려고 노력하였다. 하지만 역시 코드에 정답은 없기에 미션을 수행하면서도 많은 고민을 하였다. 우선 구현에 사용하도록 외부 라이브러리가 포함되어 있었다. 이를 분석하고, 사용하기 위해 클래스 내부를 뜯어보았다. 내부에서 ThreadLocalRandom를 사용하여 랜덤 값을 생성하는데, ThreadLocalRandom를 찾아보니 동시성 문제에도 성능 저하 없이 사용할 수 있다는 특징이 있었다. Console의 경우에는 scanner를 싱클톤으로 사용하여 효율적으로 리소스를 활용하는 모습이었다. 살아있는 문서 가장 처음 목표로..
저번 블랙잭을 이후로 이번에는 체스를 구현해 보았다. 우선 설계를 조금 디테일하게 잡아서 진행하였다. 물론 첫 설계를 끝까지 가져가지는 못했다.. 중간에 추가된 부분이 조금은 있다. 그래도 처음보단 설계하는 실력도 늘었다고 생각한다. 진행하면서 고민하고 배운 것을 정리하였다. 고민했던 것 우선 첫 번째 고민은 각각의 기물들의 위치와 기물을 Map으로 관리하였다. 이때 위치를 단순하게 String으로 관리하려 했다. 하지만 이럴 경우 예외처리를 하는 경계도 애매해지고, 관리하기가 힘들 것 같다고 판단하였다. 그래서 위치 즉 Location도 객체로 관리하여 예외를 처리하도록 하였다. 위치도 더욱 나눌 수 있기 때문에 행과 열을 체스의 용어에 맞게 분리하여 코드를 작성했다. 또 다른 고민으로는 기물이 없는 ..
