메서드 매개변수가 유효한지 검사하라 - 메서드나 생성자를 작성할 때 매개변수들에 어떤 제약이 있을지 생각하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다. - public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다. - 자바 7에 추가된 java.util.Objects.requireNonNull 메서드는 유연하고 사용하기도 편하니, 더 이상 null 검사를 수동으로 하지 않아도 된다.this.stratergy = Objects.requireNonNull(strategy, "전략"); 적시에 방어적 복사본을 만들라 - 클라이언트에서 불변식을 깨뜨리려고 한다고 가정하고 방어적으로 프로그래밍해야 한다. - Date는 낡은 API이니 새로운 코드를 작성할 때는 더 이상.. 람다와 스트림 익명 클래스보다는 람다를 사용하라 - 익명 클래스Collection.sort(words, new Compareator() {public int compare(String s1, String s2) {return Integer.compare(s1.length(), s2.length());}} - 람다식을 함수 객체로 사용Collection.sort(words, (s1, s2) -> Integer.compare(s1.length(), s2.length())); - 타입을 명시해야 코드가 더 명확할 때를 제외하고는, 람다의 모든 매개변수 타입은 생략하자. - 람다는 이름이 없고 문서화도 못 한다. 따라서 코드 자체로 동작이 명확히 설명되지 않거나 코드 줄 수가 많아지면 람다를 쓰지 말아야 한다. - 람다를 직.. 열거 타입과 애너테이션 int 상수 대신 열거 타입을 사용하라 - 컴파일 타입 안정성을 제공한다. - 더 읽기 쉽고 안전하다. - 각 상수를 특정 데이터와 연결지으려면 생성자에서 데이터를 받아 인스턴스 필드에 저장하면 된다. - 상수 일부가 같은 동작을 공유한다면 전략 열거 타입 패턴을 사용하자. ordinal 메서드 대신 인스턴스 필드를 사용하라 - ordinal 메서드는 해당 상수가 그 열거 타입에서 몇 번째 위치인지를 반환한다. - 열거 타입 상수에 연결된 값은 ordinal 메서드로 얻지 말고 인스턴스 필드에 저장하자 - ordinal()의 값을 사용public enum Ensemble {SOLO, DUET, TRIO; public int numberOfMusicians() { return ordinal() + 1; }.. 제네릭 로 타입은 사용하지 말라 - 안 좋은 예final Collection stamps = ...;for (Iterator i = stamps.iterator(); i.hasNext();) {Stamp stamp = (Stamp) i.next();...;} - 좋은 예final Collection stamps = ...;for (Stamp i : stamps) {Stamp stamp = i;...;} 비검사 경고를 제거하라 - 할 수 있는 한 모든 비검사 경고를 제거하라. - 경고를 제거할 수는 없지만 타입 안전하다고 확신할 수 있다면 @SuppressWarnings("unchecked") 애너테이션을 달아 경고를 숨기자. (가능한 좁은 범위에 사용하고, 경고를 무시해도 되는 안전한 이유를 항상 주석으로 남겨.. 클래스와 인터페이스 클래스와 멤버의 접근 권한을 최소화하라 - 모든 클래스와 멤버의 접근성을 가능한 좁혀야 한다. - public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다. - public 가변 필드를 갖는 클래스는 일반적으로 스레드 안전하지 않다. ((public static final로 선언된 상수 제외) - public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공해서는 안 된다. (배열은 private으로 만들고, 반환 객체는 불변 리스트 혹은 배열의 복사본으로 한다.) public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 - public 클래스라면 데이터 필드를 직접 노출하지 말고 접근자, 변경자 메소드를 제공하자. - package-p.. 모든 객체의 공통 메서드 equals는 일반 규약을 지켜 재정의하라재정의하지 않아도 되는 경우 - 각 인스턴스가 본질적으로 고유하다. ex) Thread - 인스턴스의 논리적 동치성을 검사할 일이 없다. - 상위 클래스에서 재 정의한 eqauls가 하위 클래스에도 딱 맞는다. - 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다.재정의해야 할 때 - 논리적 동치성을 확인해야 하는데, 상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의되지 않았을 때. ex) String, Integer (값 클래스) - 5가지 규약을 지켜야 한다. (반사성, 대칭성, 추이성, 일관성, null-아님) equals를 재정의하려거든 hashCode도 재정의하라 - equals가 두 객체를 .. 객체 생성과 파괴 생성자 대신 정적 팩토리 메서드를 고려하라장점 - 이름을 가질 수 있다. - 호출될 때 마다 인스턴스를 새로 생성하지 않아도 된다. - 반환 타입의 하위 타입 객체를 반환할 수 있다. - 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다. - 정적 팩토리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.단점 - 상속을 하려면 public이나 protected 생성자가 필요하니 정적 팩토리 메서드만 제공하면 하위 클래스를 만들 수 없다. - 사용자가 찾기가 어렵다. 생성자에 매개변수가 많다면 빌더를 고려하라점층적 생성자 패턴 - 매개변수 개수가 많아지면 코드를 작성하거나 읽기 어렵다.자바빈즈 패턴(setter method 사용) - 객체 하나를 만들려면 메서드를 여러 .. GraphQL REST vs GraphQLREST1. 하나의 resource당 하나의 endpoint를 가짐2. GET, POST, PUT, DELETE 사용3. 응답의 형태가 정해져 있어서 필요한 정보만 요청하기 힘듦 GraphQL1. 단일 endpoint를 권장 (요청 query문에 따라 응답이 바뀜)2. GET -> Query, POST, PUT, DELETE -> Mutation 사용3. 클라이언트에서 필요한 정보만 선택하여 요청 GraphQL의 장점1. REST API는 각 resource 종류별로 요청을 해야하므로 요청 횟수가 필요한 resource에 비례하지만 GraphQL은 원하는 정보를 한번의 Query에서 요청할 수 있음2. 필요한 정보만 선택하여 요청할 수 있어서 HTTP 응답의 사이즈를 줄일 수 .. 이전 1 ··· 3 4 5 6 7 8 9 ··· 12 다음