studybook
  • Introduction
  • 실무 하며 깨닫는 부분 정리
    • 옵션에 대해서
    • 코드 작성의 순서
    • 자바 프로그램에 문제가 생겼다면
    • 장애 대처법
  • Logstash, Beats 정리
  • Zookeeper 정리
  • Message Queue 정리
    • RabbitMQ 삽질
  • Java 관련 정리
    • Java Primitive Wrapper class
    • Java NIO
    • Java8 Double colon operator
    • Effective Java
      • 4장
      • 5장
      • 6장 - Enum, Annotation
      • 7장 - Method
      • 8장 - 프로그래밍 일반
      • 9장 - Exception
    • Java8 Lambda expression
    • JDBC
    • Linux에서 WatchService 이상동작
  • Spring 관련 정리
    • Spring Bean init, destroy 순서
    • Spring Async Controller
    • Spring Executable jar 웹 개발 및 배포
    • Spring Boot Font 배포 에러
    • Spring AOP
      • Spring AOP로 모든 Request 로그 남기기
    • Spring Cache
    • Spring Cloud
      • Consul로 spring 설정 관리하기
    • Spring Test
      • Spring Test DirtiesContext
      • Spring Test MockBean, SpyBean
      • Spring Test Dynamic @Scheduled
    • Spring JDBC
    • Spring Validation
    • Spring Transaction Management
      • Spring with JTA 삽질
    • Spring에서 효율적으로 Static resource 관리하기
    • Zuul을 사용해서 Spring Reverse proxy 만들기
    • Spring Security
    • 스프링 어노테이션이 안 먹힐 때 의심해볼만한 것
    • Spring Data
    • Spring Webflux
      • Tobi 강연
  • 코드 리팩토링
    • 한번에 하나씩
  • 지속적 통합 (CI)
    • Jenkins pipeline 삽질기
  • Log Aggregator 정리
    • Flume 테스트
    • Fluentd 테스트
  • Web Socket 정리
  • Akka
    • Actor 모델
    • Supervision
  • IE 8 대응 정리
  • 함수형 프로그래밍
    • 모나드
  • Netty
    • Netty 기본 예제
    • Netty 주요 특징
    • Netty 부트스트랩
    • Netty 채널 파이프라인, 코덱
    • Netty 이벤트 모델
    • Netty 바이트 버퍼
  • 스칼라 관련 정리
    • Maven으로 컴파일하기
    • Scala def 괄호 여부의 차이
    • 스칼라 function, method 차이점
    • ScalaTest와 Spring 연동하기
    • Programming in Scala
  • J2S 컨퍼런스
  • Android
    • 테스트
    • NDK
  • DDOS
  • HTTP
  • HttpClient
  • Container
    • Image 개요
    • cri-o
    • kata containers
    • Open Container Initiative Image
    • Buildkit
  • Github pages
  • Static Website
  • Webhook
  • Service Discovery Tools
    • Etcd
    • Eureka
    • Consul
      • ACL
    • 비교
  • React
    • JSX
    • React Element
    • Components, Props
    • State, Lifecycle
    • Handling Event
    • Flux
  • Vagrant
    • SSH 접속
  • Linux
    • Systemd
    • Alternatives
  • Messaging protocols
    • XMPP
    • AMQP
  • Windows
    • Windows10 내장 우분투에 ssh 클라이언트로 접속하기
    • Windows10 Hyper-V와 Virtual Box가 충돌을 일으켰을 때
    • Hyper-V 기반 docker에서 Shared Drives 설정 실패할 때
    • 윈도우 개발환경 설정
    • Docker desktop 없이 docker 환경 세팅하기
    • UWP 앱을 항상 관리자권한으로 실행하는 바로가기 만들기
  • Spring camp 2017
    • Project Reactive
    • 이벤트 소싱
    • CQRS
  • Spring webflux
  • 리액티브 프로그래밍
  • Linux Settings
    • 홈서버 백업 및 복구기
    • 홈서버 트러블슈팅
  • Kubernetes
    • k3s 설치 및 삽질
    • pod resources
    • Argo workflow
    • 트러블 슈팅
      • Kubernetes namespace의 phase가 Terminating에서 멈춰있을 때
    • 쿠버네티스 마스터
    • Knative
    • Knative Pipeline
    • Aggrerated API server
    • Accessing the API
      • Authenticating
  • Sonarqube
  • HTTP/2
  • Go
    • Go Module
    • Go dependency injection
    • Go Error handling
    • Go in Action
      • 3장 패키지
      • 4장 배열, 슬라이스, 맵
      • 5장 GO의 타입 시스템
      • 6장 동시성
      • 7장 동시성 패턴
      • 8장 표준 라이브러리
      • 9장 테스트와 벤치마킹
    • Go Channel 사용법
  • Cloud Native
Powered by GitBook
On this page
  • int 대신에 enum 쓰기
  • ordinal 대신에 인스턴스 필드 쓰기
  • bit field 대신에 EnumSet 쓰기
  • 굳이 확장이 필요하다면 enum이 interface를 상속하게 만들기
  • 특별한 네이밍 패턴을 만드는 대신에 Annotation을 쓰기
  • 네이밍 패턴의 단점
  • Annotation
  • 가능하면 @Override Annotation을 모조리 붙이기
  • Marker Interface vs Marker Annotation
  1. Java 관련 정리
  2. Effective Java

6장 - Enum, Annotation

int 대신에 enum 쓰기

  • 타입 안전이 보장된다

  • 출력, 또는 디버깅할 때 어떤 값인지 쉽게 알아볼 수 있다

  • 성능적으로 int를 사용하는 것과 비슷하다

    • 물론 메모리는 약간 더 먹긴 한다

  • enum은 별개의 네임스페이스를 가지기 때문에 동일한 이름의 상수를 만드는데 지장이 없다

  • enum에다가 별도의 메소드나 필드를 정의해서 좀 더 편리하게 사용할 수 있다

  • enum에다가 abstract 메소드를 넣고 각각의 인스턴스마다 각자 구현한 다음 그 메소드를 호출하게끔 하여 switch-case문을 대체할 수 있다. 이 경우 enum의 요소가 늘어나더라도 switch-case의 case를 늘린다던가 하는 불편한 점이 없어진다.

    • 불필요하게 코드가 중복된다 싶으면 한 depth를 늘려서 중첩 enum을 만든 다음 거기에서 구현하게 하는 방법도 있다

ordinal 대신에 인스턴스 필드 쓰기

ordinal을 사용하는 로직은 enum 인스턴스의 순서가 바뀌거나 새로운 요소를 추가할 때 문제를 일으킬 수 있음

bit field 대신에 EnumSet 쓰기

  • 비트 연산자를 쓰게 되면 알아보기 어렵고 각 요소를 차례대로 반복해서 처리할 방법이 없다

  • EnumSet의 각 요소들은 내부적으로 bit vector으로 표현되며, 갯수가 64개 이하라면 전체가 하나의 long으로 처리된다. (RegularEnumSet)

굳이 확장이 필요하다면 enum이 interface를 상속하게 만들기

  • 대부분의 경우에는 필요없음. 단점이 더 많으므로.

특별한 네이밍 패턴을 만드는 대신에 Annotation을 쓰기

네이밍 패턴의 단점

  1. 오타가 났을 때 별도의 에러메세지 없이 그냥 무시, 스킵한다.

  2. 경우에 따라서는 원하지 않는 경우에도 실행해버릴 수 있다.

  3. 이름에다가 별도의 패러미터를 지정하게 될 경우, 컴파일러가 그 패러미터를 검사 할 수 없으므로 직접 돌려보기 전까지는 무슨 문제가 있는지 알 수 없다.

Annotation

  • Target, Retention 등의 meta-annotation을 가짐

  • 별도의 변수를 가지지 않는 annotation을 marker annotation이라고 부름

  • annotation 자체로는 아무런 의미도 가지지 않음. 그냥 말 그대로 metadata를 제공할 뿐. annotation을 달고 나서 리플렉션을 사용하여 별도의 로직을 수행해야함.

가능하면 @Override Annotation을 모조리 붙이기

  • 패러미터나 이름을 착각해서 override 대신에 overloading을 한다던가, 새로 구현한 메소드 대신에 super class의 메소드를 호출한다던가 하는 버그들을 막아준다.

Marker Interface vs Marker Annotation

  • marker interface의 경우 runtime이 아닌 compile 시점에서 몇몇 문제점들을 미리 확인할 수 있다는 장점을 가지고 있다. 반면에 marker annotation은 돌려봐야 알 수 있다.

  • marker interface의 경우 marker annotation에 비해서 좀 더 정확한 타겟을 지정할 수 있다. 예를 들어 Collection 인터페이스와 상속하는 클래스들에만 사용가능한 marker를 만들고 싶다고 가정했을 때 marker interface는 그냥 Collection 을 상속한 인터페이스를 marker interface로 정의하면 끝이지만, annotation은 @Target 에 TYPE 이 들어가면 어떤 클래스나 인터페이스든지 붙일 수 있기 때문에 누군가 엉뚱한 클래스에 붙이는 것을 막기 힘들다.

  • marker annotation은 이미 사용중인 api라도 annotation을 더 늘리는 것으로 정보 추가가 가능하다. interface는 불가능하다.

  • Method, Field 등 class, interface 외 다른 요소에 써야한다면 marker annotation을 쓰는 것이 맞다.

  • marker가 지정된 클래스 내지는 인터페이스만을 다루는 메소드가 하나 이상 존재한다면 marker interface가 유리하다

Previous5장Next7장 - Method

Last updated 7 years ago