책 (36) 썸네일형 리스트형 열거 타입과 애너테이션 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 사용) - 객체 하나를 만들려면 메서드를 여러 .. 03. 계정 관리와 권한 부여 AWS 계정 관리AWS Organizations - 파일 시스템 처럼 트리 구조를 이용해 계정을 그룹화함 - Organization : 관리하고 싶은 계정 그룹을 묶는 부모 그룹. Organization 단위로 결제를 통합할 수 있음 - Root : Organization의 트리 구조에서 최상위의 개념 - Organization Unit : 자식 계정을 묶는 논리 그룹. 하위에 다른 Organization Unit을 생성할 수도 있음 - 계정 : 개별 계정 AWS Organizations의 기능1. 계정 생성2. 결제 일원 관리3. 계정에서 이용 가능한 AWS 서비스에 제한 설정(JSON 형식의 권한 설정) AWS Organizations의 도입과 정책 설정1. 마스터 계정으로 Organization을 .. 02. 전체 설계 AWS 계정과 IAM 사용자AWS 계정 - 기본 설정은 메일 주소와 패스워드만으로 로그인이 가능함. 권한에 비해 보안 수준이 낮으므로 다요소 인증 설정을 해야함(토큰 기반) IAM의 구조 - IAM 사용자 : AWS 이용자 - IAM 그룹 : IAM 사용자를 역할별로 그룹을 만들어 사용. 사용자는 복수의 그룹에 속할 수 있음 - IAM 정책 : 권한을 기술한 규칙 - IAM 역할 : AWS의 서비스에 권한을 부여하는 방식 복수의 AWS 계정 관리일괄 결제 기능 - 여러 AWS 계정에서 발생하는 결제를 계정 하나로 통합 하는 기능(계정 전체를 대상으로 한 통합 결제로 인해 큰 할인 혜택을 받거나 인스턴스를 돌려 쓸 수 있음) 조직 계정 - 일괄 결제 기능을 포함하고, AWS 계정에 대해 IAM처럼 정책 제.. 01. AWS 서비스 개요 AWS와 온프레미스의 차이 온프레미스 AWS 비용 초기에 전액 필요 초기 비용 불필요. 종량제로 분산해서 비용 발생 서버의 조달 기간 몇 주 ~ 몇 개월 몇 분 서버의 추가/변경 시간과 비용 발생 리소스 차액 만큼 비용 지불 AWS의 이점1. 스몰 스타트로 시작, 필요 없어지면 삭제 - 사용한 만큼만 과금되며 이용을 중지하면 그 이후는 과금 되지 않음2. 빠른 인프라 구축 속도 - 브라우저의 관리 콘솔에서 간단히 새로운 가상 서버 추가 가능3. 사전 리소스 확보 불필요 - 실제 리소스에 맞춰 증감이 가능(종량 과금제 이므로 사용한 만큼만 과금), 사전 설계 보다 구현에 시간을 투자 할 수 있음4. 빠르게 실패(Fail Fast) - 사전 검토에 많은 시간을 투자하는 것 보다 실제 테스트를 하고 결과를 확.. 이전 1 2 3 4 5 다음