자바 애노테이션

애노테이션 (Annotation) 프로그램 실행 중에 읽어서 사용할 수 있는 특별한 주석 내부에서 리플렉션 같은 기술 등을 활용 e.g. Class ,Method ,Field ,Constructor 클래스는 getAnnotation() 제공 참고: 본래 주석은 코드가 아니므로 컴파일 시점에 모두 제거됨 코드에 메모를 달아 놓는 것처럼 코드에 대한 메타데이터를 표현 프로그램 코드가 아니어서 애노테이션이 달린 메서드를 호출해도 영향을 주지 않음 애노테이션 정의 규칙 @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) @Documented public @interface AnnoElement { String value(); int count() default 0; String[] tags() default {}; Class<? extends MyLogger> annoData() default MyLogger.class; //MyLogger data(); // 다른 타입은 적용X } 정의: @interface 키워드 속성: 애노테이션은 속성을 가질 수 있음 요소 이름 메서드 형태로 정의 괄호()를 포함하되 매개변수는 없어야 함 데이터 타입 기본 타입 (int, float, boolean 등) String Class (메타데이터) 또는 인터페이스 (직접 정의한 것이 아닌 Class에 대한 정보) enum 다른 애노테이션 타입 위의 타입들의 배열 앞서 설명한 타입 외에는 정의 불가 (즉, 일반적인 클래스를 사용할 수 없음) 예) Member , User , MyLogger default 값 요소에 default 값을 지정 가능 예: String value() default "기본 값을 적용합니다."; 반환 값 void 반환 타입 사용 불가 예외 예외 선언 불가 메타 애노테이션: 애노테이션을 정의하는데 사용하는 특별한 애노테이션 @Retention 애노테이션의 생존 기간을 지정 종류: RetentionPolicy enum RetentionPolicy.SOURCE (특별한 경우 사용) 소스코드에서만 생존 -> 컴파일 시점에 제거 RetentionPolicy.CLASS (기본값, 그러나 거의 사용 X) 컴파일 후 .class 파일까지 생존 -> 자바 실행 시점에 제거 RetentionPolicy.RUNTIME (대부분 사용) 자바 실행 중에도 생존 런타임에 리플렉션으로 읽을 수 있어 자주 사용됨 @Target 애노테이션을 적용할 수 있는 위치 지정 지정하지 않은 곳에 애노테이션을 적용하면 컴파일 오류 발생 종류: ElementType enum 주로 TYPE, FIELD, METHOD 사용 e.g. 배열로 여러 위치도 적용 가능 @Target({ElementType.METHOD, ElementType.TYPE}) @Documented (보통 함께 사용) 자바 API 문서를 만들 때, 해당 애노테이션이 문서에 포함되어 표현되도록 지정 @Inherited 자식 클래스가 애노테이션을 상속 받을 수 있게 함 애노테이션 사용법 기본 @AnnoElement(value = "data", count = 10, tags = {"t1", "t2"}) public class ElementData1 { } 배열 항목이 하나인 경우 {} 생략 가능 & default 항목은 생략 가능 @AnnoElement(value = "data", tags = "t1") public class ElementData2 { } 입력 요소가 하나인 경우 value 키 생략 가능 (value = "data" 와 동일) @AnnoElement("data") public class ElementData3 { } 애노테이션과 상속 public interface Annotation { boolean equals(Object obj); int hashCode(); String toString(); Class<? extends Annotation> annotationType(); //애노테이션 타입 반환 } 자바에서 애노테이션은 특별한 형태의 인터페이스로 간주 모든 애노테이션은 java.lang.annotation.Annotation 인터페이스를 묵시적으로 상속 받음 @interface로 정의하면 자바 컴파일러가 자동으로 Annotation 인터페이스를 확장 애노테이션 정의 public @interface MyCustomAnnotation {} 자바가 자동으로 처리 public interface MyCustomAnnotation extends java.lang.annotation.Annotation {} 다만, 애노테이션 사이에는 상속이라는 개념이 존재 X 애노테이션은 오직 Annotation 인터페이스만 상속 애노테이션은 다른 애노테이션이나 인터페이스를 직접 상속할 수 없음 @Inherited 애노테이션을 적용한 클래스의 자식 클래스도 해당 애노테이션을 부여 받을 수 있음 클래스 상속에서만 작동 (인터페이스 구현에는 적용 X) 자바 기본 애노테이션 @Override 메서드 재정의가 정확하게 잘 되었는지 컴파일러가 체크하는데 사용 @Deprecated 더 이상 사용되지 않는다는 뜻을 표현하며, 적용된 기능은 사용을 권장하지 않음 컴파일 시점에 경고를 나타내지만, 프로그램은 작동 옵션 since : 더 이상 사용하지 않게된 버전 정보 forRemoval : 미래 버전에 코드가 제거될 예정 (더더욱 강력한 경고) 예제 @Deprecated -> 진짜 쓰지마 @Deprecated(since = "2.4", forRemoval = true) -> 진짜진짜 쓰지마 @SuppressWarnings 자바 컴파일러가 문제를 경고하지만, 개발자가 문제를 잘 알고 있으니 경고하지 말라고 지시 왠만하면 사용 X (제네릭 쓰다보면 개발자가 책임지겠다고 쓸 때 정도 있음) 옵션 all: 모든 경고 억제 deprecation: deprecated 코드를 사용할 때 발생하는 경고 억제 unchecked: 제네릭 타입과 관련된 unchecked 경고 억제 serial: Serializable 인터페이스를 구현할 때 serialVersionUID 필드를 선언하지 않은 경우 발생하는 경고 억제 rawtypes: 제네릭 타입이 명시되지 않은(raw) 타입을 사용할 때 발생하는 경고 억제 unused: 사용되지 않는 변수, 메서드, 필드 등을 선언했을 때 발생하는 경고 억제 참고: 애노테이션 기반 검증기 활용 예제 public class Validator { public static void validate(Object obj) throws Exception { Field[] fields = obj.getClass().getDeclaredFields(); for (Field field : fields) { field.setAccessible(true); // @NotEmpty 어노테이션 검사 if (field.isAnnotationPresent(NotEmpty.class)) { String value = (String) field.get(obj); NotEmpty annotation = field.getAnnotation(NotEmpty.class); if (value == null || value.isEmpty()) { throw new RuntimeException(annotation.message()); } } // @Range 어노테이션 검사 if (field.isAnnotationPresent(Range.class)) { long value = field.getLong(obj); Range annotation = field.getAnnotation(Range.class); if (value < annotation.min() || value > annotation.max()) { throw new RuntimeException(annotation.message()); } } } } } Reference 김영한의 실전 자바 - 고급 2편, I/O, 네트워크, 리플렉션

Java-Ecosystem · 2025-03-25

자바 리플렉션

리플렉션 클래스가 제공하는 다양한 정보(메타 데이터)를 런타임에 동적으로 분석하고 사용하는 기능 e.g. 스프링 프레임워크가 내가 만든 클래스를 대신 생성해주는 경우 메타데이터 종류 클래스 e.g. 클래스 이름, 접근 제어자, 부모 클래스, 구현한 인터페이스 필드 e.g. 필드 이름, 타입, 접근 제어자 런타임에 동적으로 해당 필드 값을 읽거나 수정 가능 메서드 e.g. 메서드 이름, 반환 타입, 매개변수 정보 런타임에 동적으로 메서드 조회 및 호출 가능 생성자 e.g. 매개변수 타입 및 개수 런타임에 동적으로 생성자 조회 및 객체 생성 가능 주의점 리플렉션 코드는 특별한 상황에서 사용 공통 문제를 해결하는 유틸리티, 프레임워크, 라이브러리 개발 테스트 등 일반적인 애플리케이션은 권장 X 무분별한 리플렉션 사용은 코드의 가독성과 안정성이 크게 저하 e.g. private 직접 접근은 객체 지향 원칙을 위반 (캡슐화 및 유지보수성 저하) 클래스 내부 구조나 구현 세부사항이 변경되면 쉽게 깨지거나 버그를 초래 리플렉션은 문자를 활용하므로, 필드 및 메서드 이름 변경 시 컴파일러가 놓침 클래스 메타데이터 클래스의 메타데이터는 Class 클래스로 표현 Class 조회 방법 클래스에서 찾기 클래스명.class e.g. Class<BasicData> basicDataClass1 = BasicData.class; 인스턴스에서 찾기 인스턴스.getClass() e.g. BasicData basicInstance = new BasicData(); Class<? extends BasicData> basicDataClass2 = basicInstance.getClass(); 문자로 찾기 Class.forName(패키지명문자열) e.g. String className = "reflection.data.BasicData"; Class<?> basicDataClass3 = Class.forName(className); 기본 정보 탐색 클래스 이름 경로 포함 이름: basicData.getName() //reflection.data.BasicData 클래스 이름: basicData.getSimpleName() //BasicData 패키지 basicData.getPackage() //package reflection.data 부모 클래스 basicData.getSuperclass() //class java.lang.Object 구현한 인터페이스 basicData.getInterfaces() //[] 조건 판별 basicData.isInterface() //false basicData.isEnum() //false basicData.isAnnotation() //false 수정자 정보 (규칙있는 숫자로 리턴) basicData.getModifiers() //1 참고: 수정자는 접근제어자와 비접근제어자(기타 수정자)로 분류 접근 제어자: public , protected , default ( package-private ), private 비 접근 제어자: static , final , abstract , synchronized , volatile 등 메서드 메타데이터 Method 클래스로 표현 (클래스 메타데이터를 통해 획득 가능) 메서드 메타데이터 조회 getMethod(메서드이름, 매개변수타입) 해당 클래스와 상위 클래스에서 상속된 모든 public 메서드 중 지정 메서드 조회 e.g. String methodName = "hello"; Method method = helloClass.getMethod(methodName, String.class); getDeclaredMethod(메서드이름, 매개변수타입) 해당 클래스에서 선언된 모든 메서드 중 지정 메서드 조회 e.g. String methodName = "hello"; Method method = helloClass.getMethod(methodName, String.class); getMethods() 해당 클래스와 상위 클래스에서 상속된 모든 public 메서드를 반환 e.g. Class<BasicData> helloClass = BasicData.class; Method[] methods = helloClass.getMethods(); getDeclaredMethods() 해당 클래스에서 선언된 모든 메서드를 반환 접근 제어자에 관계 X, 상속된 메서드 포함 X e.g. Class<BasicData> helloClass = BasicData.class; Method[] declaredMethods = helloClass.getDeclaredMethods(); 동적 메서드 호출 메서드 이름을 입력 받으면, 호출 대상 메서드를 동적으로 조회해 호출 가능 getMethod(), getDeclaredMethod()로 메서드 동적 조회 Method 객체의 invoke(인스턴스, 인자1, ...) 로 메서드 호출 e.g. Class<? extends BasicData> helloClass = helloInstance.getClass(); String methodName = "hello"; Method method = helloClass.getDeclaredMethod(methodName, String.class); Object returnValue = method.invoke(helloInstance, "hi"); 필드 메타데이터 Field 클래스로 표현 (클래스 메타데이터를 통해 획득 가능) 필드 조회 getField(필드이름) 해당 클래스와 상위 클래스에서 상속된 모든 public 필드 중 지정 필드 조회 e.g. Field nameField = aClass.getField("name"); getDeclaredField(필드이름) 해당 클래스에서 선언된 모든 필드 중 지정 필드 조회 e.g. Field nameField = aClass.getDeclaredField("name"); getFields() 해당 클래스와 상위 클래스에서 상속된 모든 public 필드를 반환 e.g. Class<BasicData> helloClass = BasicData.class; Field[] fields = helloClass.getFields(); getDeclaredFields() 해당 클래스에서 선언된 모든 필드를 반환 접근 제어자에 관계 X, 상속된 필드 포함 X e.g. Class<BasicData> helloClass = BasicData.class; Field[] declaredFields = helloClass.getDeclaredFields(); 필드 값 변경 setAccessible(true) private 필드에 직접 접근해 변경할 수 있는 기능 e.g. nameField.setAccessible(true) 참고: private 메서드, 생성자에서도 사용 가능 (Method, Constructor) set(인스턴스, 변경값) 필드 값 변경 메서드 e.g. nameField.set(user, "userB") 생성자 메타데이터 Constructor 클래스로 표현 (클래스 메타데이터를 통해 획득 가능) 생성자 조회 getConstructor(매개변수타입) 해당 클래스와 상위 클래스에서 상속된 모든 public 생성자 중 지정 생성자 조회 e.g. Constructor<?> constructor = aClass.getConstructor(String.class); getDeclaredConstructor(매개변수타입) 해당 클래스에서 선언된 모든 생성자 중 지정 생성자 조회 e.g. Constructor<?> constructor = aClass.getDeclaredConstructor(String.class); getConstructors() 해당 클래스와 상위 클래스에서 상속된 모든 public 생성자를 반환 e.g. helloClass.getConstructors(); getDeclaredConstructors() 해당 클래스에서 선언된 모든 생성자를 반환 접근 제어자에 관계 X, 상속된 생성자 포함 X e.g. helloClass.getDeclaredConstructors(); 동적 인스턴스 생성 setAccessible(true) private 생성자에 직접 접근해 호출할 수 있는 기능 e.g. constructor.setAccessible(true) newInstance(인자) 생성자를 호출해 동적으로 객체 생성 e.g. Object instance = constructor.newInstance("hello") Reference 김영한의 실전 자바 - 고급 2편, I/O, 네트워크, 리플렉션

Java-Ecosystem · 2025-03-15

자바 I/O & 네트워크

Java-Ecosystem · 2025-02-28

자바 멀티스레드와 동시성

Java-Ecosystem · 2024-10-02

자바 Collection Framework

Java-Ecosystem · 2024-09-05

자바 제네릭

Java-Ecosystem · 2024-09-04

자바 예외 기본

예외 계층 Object: 모든 객체의 최상위 부모 Throwable: 최상위 예외, 잡으면 안됨 (Error까지 잡히므로) Error 애플리케이션에서 복구 불가능한 시스템 예외 (메모리 부족, 심각한 시스템 오류…) 애플리케이션 개발자는 이 예외를 잡지 않아야 함 언체크 예외 Exception: 체크 예외 (런타임 예외 제외), 애플리케이션에서 개발자가 잡아야 할 실질적최상위 예외 RuntimeException: 언체크 예외 (=런타임 예외) 체크예외 VS 언체크 예외 핵심 언체크 예외는 throws 선언하지 않고 생략 가능 (자동 예외 던지기) 나머지는 동일 체크 예외 컴파일러가 체크하는 예외 체크 예외의 장단점 예외를 누락하지 않도록 컴파일러가 안전 장치 역할 (누락 시 컴파일 오류) 크게 신경쓰지 않고 싶은 예외까지 모두 반드시 잡거나 던져야 함 언체크 예외 컴파일러가 체크하지 않는 예외 중요 예외의 경우 throws를 선언해두면 IDE를 통해 개발자가 편리하게 인지 가능 (보통은 생략) 언체크 예외의 장단점 신경쓰고 싶지 않은 언체크 예외 무시 가능 개발자가 실수로 예외 누락 가능 예외 처리 기본 기본 규칙 예외는 잡아서 처리하거나 던져야 한다 예외를 잡는 코드: catch 예외를 던지는 코드: throws 예외를 잡거나 던질 때 지정한 예외 뿐만 아니라 그 예외의 자식들도 함께 처리된다 기본적으로 언체크(런타임) 예외를 사용하자 체크 예외들은 바깥으로 던져야 하는데 이 과정에서 의존 관계 문제 발생 실무에서 발생하는 대부분의 예외는 복구 불가능한 시스템 예외 (애플리케이션 단에서 처리 불가) 의존 관계 문제 컨트롤러, 서비스는 본인이 처리할 수 없어도 throws를 선언해 예외를 던져야 함 컨트롤러, 서비스가 해당 체크 예외에 의존하게 되어 구현 기술 변경 시 OCP 위반 예를 들어, DB 접근 기술을 변경한다면 예외를 포함한 컨트롤러, 서비스 코드를 수정 수 많은 체크 예외를 일일이 명시해 던지는 것도 부담 런타임 예외를 사용하면 처리할 수 없는 예외를 별도 선언 없이 그냥 두면 됨 의존성 발생 X -> 기술 변경이 있어도 컨트롤러, 서비스 코드 변경 X -> OCP 준수 대부분의 최근 라이브러리는 런타임 예외를 기본으로 제공 (스프링, JPA…) 런타임 예외는 놓칠 수 있기 때문에 문서화가 중요 (혹은 명시적으로 코드에 throws 남기기) 처리할 수 없는 예외들은 한 곳에서 공통처리 서블릿 오류 페이지, 스프링 MVC ControllerAdvice 예외 공통 처리 고객: 오류 페이지 내부 개발자: 별도 로그, 슬랙, 문자, 메일을 통해 개발자가 빠르게 인지 API는 상태코드 500 응답 예시 코드 public class Main { public static void main(String[] args) { NetworkService networkService = new NetworkService(); try { networkService.sendMessage(); } catch (Exception e) { // 모든 예외를 잡아서 처리 exceptionHandler(e); } } //공통 예외 처리 private static void exceptionHandler(Exception e) { //공통 처리 System.out.println("사용자 메시지: 죄송합니다. 알 수 없는 문제가 발생했습니다."); System.out.println("==개발자용 디버깅 메시지=="); e.printStackTrace(System.out); // 스택 트레이스 출력 //e.printStackTrace(); // System.err에 스택 트레이스 출력 //실무에서는 보통 Slf4j 사용해 로그를 콘솔 출력 + 파일로 저장 //e.printStackTrace는 콘솔에만 출력하므로 사용 X //필요하면 예외 별로 별도의 추가 처리 가능 if (e instanceof SendException sendEx) { System.out.println("[전송 오류] 전송 데이터: " + sendEx.getSendData()); } } } 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용 매우 심각한 문제는 개발자가 실수로 예외를 놓치면 안된다고 판단할 수 있음 체크 예외 예시 (무조건 해야하는 건 아님) 계좌 이체 실패 예외 결제시 포인트 부족 예외 로그인 ID, PW 불일치 예외 Exception을 던지지 말자 코드가 깔끔해지는 것 같지만, 모든 체크 예외를 다 던져 버려서 중요한 체크 예외를 놓침 꼭 필요한 경우가 아니면 Exception 자체를 밖으로 던지는 것은 좋은 방법이 아님 스택 트레이스를 남기자 로그 남기기 log.info("예외 처리, message={}", e.getMessage(), e); 로그의 마지막 인수에 예외 객체 전달하면 로그에 스택 트레이스를 출력 예외를 전환할 때는 반드시 기존 예외를 포함하자 throw new RuntimeSQLException(e); - 기존 예외 e 포함 덕분에 기존 예외와 스택 트레이스까지 확인 가능 포함하지 않으면 실제 DB에서 발생한 근본적인 원인을 확인할 수 없는 심각한 문제 발생 예외를 계속 던지면 벌어지는 상황 자바 main() 쓰레드의 경우 예외 로그를 출력하면서 시스템이 종료 웹 애플리케이션의 경우 WAS가 예외를 받아 처리하고 개발자가 지정한 오류 페이지 보여줌 (예외 하나로 시스템이 종료되면 안됨) 사용자 예외 만들기 Exception을 상속 받으면 체크 예외 RuntimeException을 상속 받으면 언체크 예외 오류 메시지 보관하기 생성자를 통해 오류 메시지를 보관할 것 (예외가 제공하는 기본 기능) super(message)로 전달한 메시지는 Throwable의 detailMessage에 보관됨 getMessage()로 조회 가능 public class MyCheckedException extends Exception { public MyCheckedException(String message) { super(message); } } 적당한 예외 계층화하기 (너무 많아도 문제) 상속을 사용해 예외를 계층화하면 보다 세밀한 예외 처리 가능 e.g. NetworkClientException (부모) ConnectException (자식, 내부 연결 시도 address 보관) SendException (자식, 내부 전송 시도 데이터 sendData 보관) 각각의 하위 예외에 고유 기능을 만들어 활용 가능 e.g. e.getAddress(), e.getSendData() 부모 예외를 잡아 자식까지 한 번에 처리하거나 특정 하위 예외만 잡아 처리 가능 중요한 특정 하위 예외만 메시지를 명확히 남기고 나머지는 공통 처리 가능 e.g. [연결 오류] 주소: ... (하위 예외) [네트워크 오류] 메시지: ... (부모 예외) [알 수 없는 오류] 메시지: ... (그 외 예외 공통 처리) 예외 처리 발전 과정 예시 (e.g. NetworkClient) 반환 값(문자열)으로 예외 처리 분기 처리 및 return으로 네트워크 연결 및 해제, 데이터 전송 관리 등이 가능 가장 중요한 정상 흐름이 한눈에 들어오지 않음 (정상 흐름과 예외 흐름 분리 X, 가독성 감소) 예외 처리 메커니즘 사용 (try ~ catch ~ finally) 성공 여부를 반환값이 아닌 메서드 정상 종료 여부로 판단 정상 흐름과 예외 흐름을 명확히 분리해 가독성 상승 (try 블록, catch 블록) 반드시 실행되어야 하는 코드를 안전하게 호출하도록 보장 (finally) finally가 없으면 catch에서 잡지 못한 예외가 발생할 때 문제가 생김 외부 자원 해제 등에 편리 finally finally 블록은 어떤 경우라도 반드시 호출된다. 주로 try에서 사용한 자원을 해제할 때 사용한다. 예외를 직접 잡을 일이 없다면, try ~ finally만 사용하는 것도 가능하다. 정상 흐름 (try) -> finally 예외 잡음 (catch) -> finally 예외 던짐 -> finally (finally 블록 끝난 이후 예외가 밖으로 던져짐) 자원 해제 외부 리소스는 사용 후 반드시 연결을 해제하고 자원을 반납해야 메모리 고갈을 피할 수 있다. (네트워크 연결 자원, DB 연결 자원…) 자바는 GC로 JVM 메모리 상 인스턴스들을 자동으로 해제하지만, 외부 연결 같은 자바 외부 자원은 자동으로 해제되지 않는다. 여러 예외 한 번에 잡는 Syntax catch 블록에서 | 키워드를 사용해 예외를 나열할 수 있다. 다만, 이 경우 각 예외들의 공통 부모 기능만 사용할 수 있다. e.g. catch (ConnectException | SendException e) {...} // 이 경우 공통 부모인 NetworkClientException의 기능만 사용 가능 try-with-resources 구문 finally 없이 편리한 외부 자원 해제 지원 사용 방법 외부 자원 클래스에 AutoCloseable 인터페이스를 구현 (implements AutoCloseable) close() 메서드를 오버라이드해 자원 반납 방법 정의 메서드가 예외를 던지지 않으면 인터페이스의 throws Exception은 생략 try-with-resources 구문 사용 try (Resource resource = new Resource()) { // 리소스를 사용하는 코드 } try 괄호 안에 사용할 자원을 명시 e.g. try (NetworkClient client = new NetworkClient(address)) {...} try 블록이 끝나면 자동으로 AutoCloseable.close() 호출해 자원 해제 try 블록만 단독으로도 사용 가능 (catch, finally 없이 사용 가능) 장점 리소스 누수 방지 실수로 finally 블록 혹은 그 내부에 자원 해제 코드를 누락하는 문제 예방 코드 간결성 및 가독성 향상 리소스 스코프 범위 한정 리소스 객체 변수의 스코프를 try 블록으로 한정해 코드 유지보수성 향상 조금 더 빠른 자원 해제 기존에는 catch 이후에 자원을 반납 (try -> catch -> finally) try with resources는 try 블록이 끝나면 즉시 close() 호출 Reference 김영한의 실전 자바 - 중급 1편

Java-Ecosystem · 2024-08-24

자바 중첩 클래스

Java-Ecosystem · 2024-08-17

자바 날짜 시간 라이브러리

날짜 시간 라이브러리의 필요성 날짜 라이브러리는 복잡한 계산을 추상화해 제공하므로, 안정적이고 정확한 개발 가능 자바 8에서 java.time 패키지(JSR-310)를 표준 API(기능의 모음)로 도입 외부 라이브러리였던 Joda-Time의 개발자를 데려와 새로운 자바 표준 API를 함께 정의 이전 문제가 많던 API를 크게 개선 (사용성, 성능, 스레드 안정성, 타임존 처리, 불변 객체 설계 등) 날짜 계산이 어려운 이유 각 달은 28~31일로 다르게 분포 윤년 (Leap Year) 지구가 태양을 한 바퀴 도는 평균 시간은 약 365.2425일 (약 365일 5시간 48분 45초) 우리가 사용하는 그레고리력은 1년이 365일 윤년은 둘의 간극을 매우기 위한 해결책으로 4년마다 하루를 추가 (2월 29일) 100년 단위는 윤년이 아니며 400년 단위는 다시 윤년 일광 절약 시간 (Daylight Saving Time, DST) - 썸머타임 보통 3월 중순~11월 초 태양이 일찍 뜨는 것에 맞춰 1시간 앞당기는 제도 국가나 지역에 따라 적용 여부 및 시작 종료 날짜가 다름 타임존 계산 각각의 타임존은 UTC(세계 협정시)로부터의 시간 차이로 정의 London / UTC / GMT는 세계 시간의 기준이 되는 00:00 시간대 GMT (그리니치 평균시, Greenwich Mean Time) 처음 세계 시간은 영국 런던 그리니치 천문대를 기준으로 만듦 UTC (협정 세계시, Universal Time Coordinated) GMT를 대체하기 위해 도입 (둘은 실질적으로 같은 시간대) 다만, UTC는 원자 시계를 사용해 측정해 보다 정확한 시간 유지 타임존 예시 Europe/London GMT UTC America/New_York -05:00 Asia/Seoul +09:00 자바 날짜 시간 라이브러리 (time) - 클래스 분류표 유의점 모든 날짜 클래스는 불변 -> 변경이 발생하는 경우 새로운 객체를 생성해 반환 초는 나노초 정밀도로 캡처 가능 Year, Month, YearMonth, MonthDay: 자주 사용 X DayOfWeek: 월, 화, 수, 목, 금, 토, 일을 나타내는 Enum (ChronoField) 날짜와 시간 핵심 인터페이스 TemporalAccessor 인터페이스 날짜와 시간을 읽기 위한 기본 인터페이스 날짜와 시간의 2가지 개념 (특정 시점의 시간 & 시간의 간격) Temporal 인터페이스 - 특정시점의 시간 날짜와 시간을 조작하기 위한 기능 추가 제공 상위 인터페이스 덕분에 읽기와 쓰기 모두 지원 구현체 LocalDateTime, LocalDate, LocalTime ZonedDateTime, OffsetDateTime Instant TemporalAmount 인터페이스 - 시간의 간격 특정 날짜 시간 객체에 일정 기간을 더하거나 빼는데 사용 구현체 Period , Duration 시간의 단위와 필드 - 단독 사용 X, 날짜 시간 조회나 조작에 사용 TemporalUnit 인터페이스 - 시간의 단위 날짜와 시간을 측정하는 단위 구현체(Enum): ChronoUnit 시간: NANOS, MICROS, MILLIS, SECONDS, MINUTES, HOURS 날짜: DAYS, WEEKS, MONTHS, YEARS, DECADES, CENTURIES, MILLENNIA 기타: ERAS, FOREVER 주요 메서드 between(Temporal, Temporal) 두 Temporal 객체 사이의 시간을 현재 ChronoUnit 단위로 측정하여 반환 e.g. LocalTime lt1 = LocalTime.of(1, 10, 0); LocalTime lt2 = LocalTime.of(1, 20, 0); long secondsBetween = ChronoUnit.SECONDS.between(lt1, lt2); long minutesBetween = ChronoUnit.MINUTES.between(lt1, lt2); getDuration() 현재 ChronoUnit의 기간을 Duration 객체로 반환 e.g. ChronoUnit.HOURS.getDuration().getSeconds() //3600 ChronoUnit.DAYS.getDuration().getSeconds() //86400 TemporalField 인터페이스 - 시간의 각 필드 날짜와 시간의 특정 부분을 나타냄 (연도, 월, 일, 시간, 분) 예를 들어, 일(day)은 31보다 클 수 없는 것처럼 범위가 생김 구현체(Enum): ChronoField 연도: ERA, YEAR_OF_ERA, YEAR, EPOCH_DAY 월 MONTH_OF_YEAR: 월 (1월 = 1) 주 및 일 DAY_OF_MONTH: 월의 일 (1일 = 1) DAY_OF_WEEK: 요일 (월요일 = 1) DAY_OF_YEAR: 연의 일 (1월 1일 = 1) 시간 HOUR_OF_DAY: 시간 (0-23) HOUR_OF_AMPM: 오전/오후 시간 (0-11) CLOCK_HOUR_OF_DAY: 시계 시간 (1-24) CLOCK_HOUR_OF_AMPM: 오전/오후 시계 시간 (1-12) MINUTE_OF_HOUR: 분 (0-59) SECOND_OF_MINUTE: 초 (0-59) MILLI_OF_SECOND: 초의 밀리초 (0-999) MICRO_OF_SECOND: 초의 마이크로초 (0-999,999) NANO_OF_SECOND: 초의 나노초 (0-999,999,999) 기타 AMPM_OF_DAY: 하루의 AM/PM 부분 주요 메서드 range() 필드 값의 유효 범위를 ValueRange 객체로 반환 (최소값과 최대값을 제공) e.g. ChronoField.MONTH_OF_YEAR.range() //1 - 12 ChronoField.DAY_OF_MONTH.range() //1 - 28/31 Temporal - 특정 시점의 시간 기본 날짜 시간 표현 (LocalXxx) 특정 지역의 날짜와 시간만 고려할 때 사용 (타임존 적용 X, 시간대 고려 X) 국내 서비스만 고려할 때 권장 종류 LocalDate: 날짜만 표현 (년, 월, 일) 예) 2013-11-21 LocalTime: 시간만 표현 (시, 분, 초) 예) 08:20:30.213 밀리초, 나노초 단위도 포함 가능 LocalDateTime: LocalDate + LocalTime 예) 2013-11-21T08:20:30.213 클래스 내부에 LocalDate와 LocalTime을 필드로 가지고 있음 public class LocalDateTime { private final LocalDate date; private final LocalTime time; ... } 주요 메서드 공통 메서드 생성 now(): 현재 시간 기준으로 생성 of(...): 특정 날짜를 기준으로 생성 계산 dt.plusXxx(): 특정 날짜 시간 단위를 더함 e.g. plusYears(1), plusDays(10), plusSeconds(30) LocalDatetime 날짜와 시간 분리 dt.toLocalDate(): 주어진 LocalDateTime에서 날짜만 반환 dt.toLocalTime(): 주어진 LocalDateTime에서 시간만 반환 날짜와 시간 합체 of(...): 날짜와 시간을 묶어서 LocalDateTime으로 만들기 e.g. LocalDateTime.of(localDate, localTime) 비교 dt.isBefore(): 현재 날짜시간이 지정 날짜시간보다 이전이라면 true 를 반환 dt.isAfter(): 현재 날짜시간이 지정 날짜시간보다 이후라면 true 를 반환 dt.isEqual(): 현재 날짜시간과 지정 날짜시간 시간적으로 동일하면 true 를 반환 isEqual() 객체가 다르고 타임존이 달라도 시간적으로 같으면 true e.g. 서울의 9시와 UTC의 0시는 시간적으로 동일 equals() 객체 타입, 타임존 등등 내부 데이터의 모든 구성요소가 같아야 true e.g. 서울의 9시와 UTC의 0시는 타임존이 다르므로 false 시간대 적용 날짜 시간 표현 (ZonedDateTime, OffsetDateTime) 글로벌 서비스 개발 시에만 사용 (그러지 않으면 거의 사용 X) 용어 타임존(Time Zone) 오프셋과 일광 절약 시간제에 대한 정보 담김 -> 타임존을 알면 일광 절약 시간제를 알 수 있음 예) Asia/Seoul 오프셋(Offset) UTC로 부터의 시간대 차이 예) +9:00 종류 ZoneId 자바가 제공하는 타임존 클래스 내부에 오프셋과 일광 절약 시간제 정보 포함 ZonedDateTime 시간대를 표현하는 타임존이 포함 (LocalDateTime + ZoneId) 일광 절약 시간제 적용 실제 사용 날짜와 시간 정보 표현에 적합 (비행기 시간, 회의 시간, 일상 시간 표현…) 예) 2013-11-21T08:20:30.213+9:00[Asia/Seoul] 클래스 내부에 LocalDatetime, ZoneId, ZoneOffset을 필드로 가지고 있음 public class ZonedDateTime { private final LocalDateTime dateTime; private final ZoneOffset offset; private final ZoneId zone; ... } OffsetDateTime 타임존은 없고, 고정된 오프셋만 포함 (LocalDateTime + ZoneOffset) 일광 절약 시간제 적용 X 시간대 변환 없이 로그를 기록하고 처리할 때 적합 로그는 순차적으로 쌓여야 함, 썸머타임 적용으로 1시간 당겨지는 상황 있으면 안됨 예) 2013-11-21T08:20:30.213+9:00 클래스 내부에 LocalDatetime, ZoneOffset을 필드로 가지고 있음 public class OffsetDateTime { private final LocalDateTime dateTime; private final ZoneOffset offset; ... } 주요 메서드 공통 메서드 생성 now(): 현재 시간 기준으로 생성 (ZoneId는 현재 시스템을 따름) of(...): 특정 날짜를 기준으로 생성 ZonedDatetime of(...) 사용법 단순 생성 ZonedDateTime zdt = ZonedDateTime.of(2030, 1, 1, 13, 30, 50, 0, ZoneId.of("Asia/Seoul")); LocalDatetime + ZoneId로 생성하기 LocalDateTime ldt = LocalDateTime.of(2030, 1, 1, 13, 30, 50); ZonedDateTime zdt = ZonedDateTime.of(ldt, ZoneId.of("Asia/Seoul")); 타임존 변경하기 zdt.withZoneSameInstant(): 입력한 타임존으로 변경 e.g. zdt.withZoneSameInstant(ZoneId.of("UTC")) OffsetDatetime of(...) 사용법 LocalDatetime + ZoneOffset로 생성하기 LocalDateTime ldt = LocalDateTime.of(2030, 1, 1, 13, 30, 50); OffsetDateTime odt = OffsetDateTime.of(ldt, ZoneOffset.of("+01:00")); 이외 ZoneId getAvailableZoneIds(): 이용 가능한 모든 ZoneId 반환 systemDefault(): 시스템이 사용하는 기본 ZoneId 반환 of(...): 타임존을 직접 제공해서 ZoneId로 변환 e.g. ZoneId.of("Asia/Seoul") 기계 중심의 시간 (Instant) UTC를 기준으로 하는 시간의 한 지점 1970년 1월 1일 0시 0분 0초(UTC)를 기준으로 경과한 시간으로 계산 (초 데이터) 클래스 내부에 초 데이터를 필드로 가짐 (나노초 정밀도) public class Instant { private final long seconds; private final int nanos; ... } 일반적으로 LocalDateTime , ZonedDateTime를 사용하고 Instant는 특별한 경우에 사용 기준점이 명확하나(UTC), 사람이 읽기 어렵고 초 단위 간단한 연산만 가능 사용 예 로그 기록, 트랜잭션 타임스탬프, 서버 간 시간 동기화 등 전 세계적으로 일관된 시점 표현 시 지속 시간 계산 등 시간대 변화 없는 순수한 시간 흐름만을 다룰 때 DB에 날짜 시간 저장하거나 다른 시스템과 날짜 시간 정보를 교환할 때 주요 메서드 생성 now() UTC를 기준 현재 시간의 Instant 를 생성 from() 다른 타입의 날짜와 시간을 기준으로 Instant 를 생성 LocalDateTime 사용 불가 (Instant 는 UTC 기준이어서 시간대 정보가 필요) e.g. ZonedDateTime zdt = ZonedDateTime.now(); Instant from = Instant.from(zdt); ofEpochSecond() 에포크 시간을 기준으로 Instant 를 생성 ofEpochSecond(0) -> 에포크 시간인 1970년 1월 1일 0시 0분 0초로 생성 ofEpochSecond(30) -> 1970/1/1/0/0/30 계산 plusSeconds() : 초, 밀리초, 나노초 정도만 더하는 간단한 메서드 조회 getEpochSecond() : UTC 1970년 1월 1일 0시 0분 0초를 기준으로 흐른 초를 반환 Epoch 시간 Epoch time(에포크 시간) 또는 Unix timestamp는 컴퓨터 시스템에서 시간을 나타내는 방법 중 하나이다. 1970년 1월 1일 00:00:00 UTC부터 현재까지 경과된 시간을 초 단위로 표현한 것이다. 즉, 시간대에 영향을 받지 않는 절대적인 시간 표현 방식이다. Instant는 Epoch 시간을 다루는 클래스이다. TemporalAmount - 시간의 간격 (기간, 시간의 양, amount of time) 년, 월, 일 단위 표현 (Period) 클래스 내부에 년, 월, 일을 필드로 가짐 public class Period { private final int years; private final int months; private final int days; } 주요 메서드 생성 of() : 특정 기간을 지정해서 Period 를 생성 of(년, 월, 일) ofDays() ofMonths() ofYears() 계산 더하기 특정 날짜 인스턴스의 plus() 메서드를 사용해 기간을 더할 수 있음 e.g. LocalDate currentDate = LocalDate.of(2030, 1, 1); Period period = Period.ofDays(10); LocalDate plusDate = currentDate.plus(period); between(): 기간 차이 구하기 (Period 반환) LocalDate startDate = LocalDate.of(2023, 1, 1); LocalDate endDate = LocalDate.of(2023, 4, 2); Period between = Period.between(startDate, endDate); //Period 반환 조회 getYears(), getMonths(), getDays() 시, 분, 초(나노초) 단위 표현 (Duration) 클래스 내부에 초 데이터만 필드로 가짐 내부에서 초를 기반으로 시, 분, 초를 계산해서 사용 public class Duration { private final long seconds; private final int nanos; } 주요 메서드 생성 of() : 특정 시간을 지정해서 Duration 를 생성 of(지정) ofSeconds() ofMinutes() ofHours() 계산 더하기 특정 시간 인스턴스의 plus() 메서드를 사용해 시간을 더할 수 있음 e.g. LocalTime lt = LocalTime.of(1, 0); Duration duration = Duration.ofMinutes(30); LocalTime plusTime = lt.plus(duration); between(): 시간 차이 구하기 (Duration 반환) LocalTime start = LocalTime.of(9, 0); LocalTime end = LocalTime.of(10, 0); Duration between = Duration.between(start, end); //Duration 반환 조회 get은 바로 가져오는 느낌, to는 계산을 하는 느낌 (Duration은 내부에 초 데이터만 보유) toHours(), toMinutes() getSeconds(), getNano() 일반적인 x시간 x분을 출력할 때는 toHoursPart() + toMinutesPart() 조합 사용 toHoursPart(), toMinutesPart(), toSecondsPart() 날짜와 시간 조회 및 조작 일관성 있는 시간 조회 및 조작 기능 제공 (인터페이스 설계가 잘되어 있음) 불변 객체이므로 메서드 체이닝 가능 기본 규칙 조회 방법 편의 메서드 사용 (가독성을 위해 권장) 자주 사용하는 조회 필드는 간단한 편의 메서드 제공 getYear(), getMonthValue(), getDayOfMonth(), getHour(), getMinute(), getSecond(), getDayOfWeek() TemporalAccessor.get(TemporalField field) ChronoField 인수로 전달해, 날짜 시간 객체에서 원하는 단위로 조회 가능 get(ChronoField.YEAR), get(ChronoField.MONTH_OF_YEAR), get(ChronoField.DAY_OF_MONTH), get(ChronoField.HOUR_OF_DAY), get(ChronoField.MINUTE_OF_HOUR), get(ChronoField.SECOND_OF_MINUTE), get(ChronoField.DAY_OF_WEEK) 편의 메서드에 없는 경우 사용 조작 방법 편의 메서드 사용 자주 사용하는 메서드는 간단한 편의 메서드 제공 plus -> plusXxx, minus -> minusXxx Temporal plus(TemporalAmount amount) Period, Duration 인수로 전달해 조작 가능 Temporal plus(long amountToAdd, TemporalUnit unit) 시간의 양과 ChronoUnit 인수로 전달해, 특정 시점의 시간을 조작 가능 isSupported() - TemporalAccessor & Temporal 인터페이스 현재 타입에서 특정 시간 단위나 필드를 사용할 수 있는지 확인 e.g. LocalDate에는 시, 분, 초 단위 관련 조회 및 조작을 할 수 없음 LocalDate now = LocalDate.now(); boolean supported = now.isSupported(ChronoField.SECOND_OF_MINUTE);//false if (supported) { int minute = now.get(ChronoField.SECOND_OF_MINUTE); } 기간 차이 구하기 남은 기간 Period, Duration의 between() e.g. Period period = Period.between(startDate, endDate); 년: period.getYears() / 월: period.getMonths() / 일: period.getDays() 디데이 ChronoUnit의 between(Temporal, Temporal) e.g. long daysBetween = ChronoUnit.DAYS.between(startDate, endDate); with() 복잡한 날짜 계산에 적합 날짜와 시간의 특정 필드 값만 변경하는 것이 가능 방법 편의 메서드 자주 사용하는 메서드는 간단한 편의 메서드 제공 dt.with(ChronoField.YEAR, 2020) -> dt.withYear(2020) TemporalAdjusters 사용 TemporalAdjuster 인터페이스의 구현체 묶음 (자바가 만들어 둠) 더욱 복잡한 날짜 계산 가능 e.g dt.with(TemporalAdjusters.next(DayOfWeek.FRIDAY)) 다음주 금요일 구하기 dt.with(TemporalAdjusters.lastInMonth(DayOfWeek.SUNDAY)) 이번 달의 마지막 일요일 구하기 Temporal with(TemporalField field, long newValue) 단순한 날짜만 변경 가능 e.g. dt.with(ChronoField.YEAR, 2020) 날짜와 시간 문자열 파싱과 포멧팅 포멧팅과 파싱 포멧팅: Date -> String 파싱: String -> Date DateTimeFormatter 날짜와 시간 포멧팅 및 파싱에 사용 포멧팅: ofPattern() LocalDate date = LocalDate.of(2024, 12, 31); DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy년 MM월 dd 일"); String formattedDate = date.format(formatter); //2024년 12월 31일 파싱: 특정 날짜 객체의 parse() LocalDate date = LocalDate.of(2024, 12, 31); String input = "2030년 01월 01일"; DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy년 MM월 dd 일"); LocalDate parsedDate = LocalDate.parse(input, formatter); 자주 쓰이는 패턴 y: 연대의 연도 M: 연중 월 d: 월의 일수 H: 24시간제 시(0-23) m: 분 s: 초 패턴 예시 “yyyy년 MM월 dd 일” “yyyy-MM-dd HH:mm:ss” ISO 8601 날짜와 시간의 표준 출력. Reference 김영한의 실전 자바 - 중급 1편

Java-Ecosystem · 2024-08-06

자바 lang 패키지

Java-Ecosystem · 2024-08-01

자바 객체 지향 설계

클래스가 필요한 이유 String[] studentNames = {"학생1", "학생3", "학생4", "학생5"}; int[] studentAges = {15, 17, 10, 16}; int[] studentGrades = {90, 100, 80, 50}; 학생이라는 개념을 다룰 때, 배열과 반복문으로 데이터를 처리해야 하므로 데이터 변경 시 실수할 가능성이 높다. 따라서 사람이 관리하기 좋은 코드를 만들기 위해 학생이라는 개념을 하나의 클래스로 묶어야 한다. 클래스 특징 클래스를 통해 마음껏 사용자 정의 타입을 만들 수 있다. (설계도) 클래스에 정의한 변수들 = 멤버 변수(Member variable) = 필드(Field) 실제 메모리에 만들어진 실체를 객체 혹은 인스턴스라 한다. 클래스 타입 변수는 객체를 생성하면 해당 객체의 참조값을 담는다. System.out.println(student); // 출력값 // (패키지 + 클래스 정보 @ 16진수 참조값) class1.Student@7a81197d 클래스 & 인스턴스 & 객체 클래스 객체 생성을 위한 ‘틀’ 또는 ‘설계도’ 객체가 가져야 할 속성(변수)과 기능(메서드)를 정의한다. 인스턴스 클래스로부터 생성된 객체 인스턴스 = 객체 어떤 클래스에 속해 있는지 강조 (관계에 초점) 객체 클래스의 속성과 기능을 가진 실체 세상 모든 사물을 단순하게 추상화해보면 속성과 기능 2가지만 남는다. 변수의 값 초기화 멤버 변수: 자동 초기화 인스턴스 생성시 자동 초기화 (new로 만드는 객체들의 멤버 변수들은 모두 자동 초기화된다.) int = 0, boolean = fasle, 참조형 = null 직접 초기화 지정 가능 지역 변수: 수동 초기화 null 참조형 변수에서 아직 가리키는 대상이 없다면 null을 넣어둘 수 있다. Data data = null; 아무도 참조하지 않는 인스턴스 (feat. GC) 참조형 변수에 null을 할당하면 해당 참조 데이터가 메모리에 남아 있다가 GC(Garbage Collector)에 의해 제거된다. 메소드가 종료되어 지역변수가 사라질 때, 지역변수가 참조하고 있던 인스턴스 역시 메모리에 남아 있다가 GC에 의해 제거된다. NullPointerException null에 .을 찍을 때 발생하는 에러이므로 디버깅시 유의하자. this 인스턴스 자신의 참조값을 가리킨다. 생성자에서 지역변수 이름이 겹친다면 this를 통해 멤버변수에 접근할 수 있다. this는 생략이 가능하다. 과거에는 명시적으로 보이지 않아 멤버 변수 접근시 항상 this를 사용하는 코딩 스타일이 존재했다. 그러나 최근엔 IDE의 발달 덕분에 멤버변수와 지역변수 구분이 잘되기 때문에, 꼭 필요한 경우에만 사용하고 생략하는게 권장된다. 변수 탐색 변수를 찾을 때 가까운 지역변수(매개변수 포함)를 먼저 찾고 없으면 그 다음으로 멤버변수를 찾는다. 멤버변수도 없으면 오류가 발생한다. 생성자 규칙 생성자의 이름은 클래스 이름과 같아야 한다. 반환타입이 없으므로 비워둬야 한다. 나머지는 메서드와 동일 인스턴스 생성 후 즉시 호출된다. new 키워드 이후 ()는 생성자 호출을 의미한다. 생성자 덕분에 자동 초기화로 인한 더미 데이터 생성을 방지하여 초기화를 강제할 수 있다. 기본 생성자 public class MemberInit { // 기본 생성자 public MemberInit() { } } 매개 변수가 없는 생성자 따로 정의한 생성자가 없는 경우 자바 컴파일러가 매개변수와 코드가 없는 기본생성자를 자동으로 만들어 준다. 생성자 오버로딩 생성자도 메서드 오버로딩처럼 여러 생성자 제공 가능 public class MemberConstruct { String name; int age; int grade; //추가 MemberConstruct(String name, int age) { this.name = name; this.age = age; this.grade = 50; } MemberConstruct(String name, int age, int grade) { this.name = name; this.age = age; this.grade = grade; } } this() 생성자 내부에서 자신의 생성자를 호출할 수 있다. (중복 제거를 위해) 단, this()는 생성자 코드 첫줄에만 작성할 수 있다. (아니면 컴파일 오류 발생) public class MemberConstruct { String name; int age; int grade; MemberConstruct(String name, int age) { this(name, age, 50); //변경 } MemberConstruct(String name, int age, int grade) { this.name = name; this.age = age; this.grade = grade; } } 절차 지향 프로그래밍 VS 객체 지향 프로그래밍 절차 지향 프로그래밍 프로그램의 흐름을 순차적으로 따르며 처리하는 방식 데이터와 기능이 분리되어 있다. 데이터와 기능의 분리는 유지보수 관점에서 관리 포인트가 2곳으로 늘어난다. 객체 지향 프로그래밍 객체들 간의 상호작용을 중심으로 프로그래밍하는 방식 (실제 세계의 사물이나 사건을 단순하게 추상화) 속성과 기능(메서드)이 객체 안에 함께 포함되어 있다. (캡슐화) 장점 객체 사용자의 입장에서 코드가 보다 친숙하고 가독성이 높다. 유연하고 변경이 용이하다. (OCP 원칙을 지키는 확장 가능한 설계) 실세계를 역할(인터페이스)과 구현(구현한 클래스 혹은 객체)으로 구분 (다형성) 클라이언트 코드를 변경하지 않고 서버의 구현 기능을 변경할 수 있다. (= 클라이언트는 인터페이스만 알면 내부 구조를 몰라도 되고 내부 구조를 변경해도 영향을 받지 않는다.) 한계 인터페이스가 변하면 클라이언트, 서버 모두 큰 변경이 발생한다. 따라서 인터페이스를 안정적으로 잘 설계하는 것이 중요하다. 캡슐화(Encapsulation) 속성과 기능을 하나로 묶어서 꼭 필요한 기능만 메서드를 통해 외부에 제공하고 나머지는 모두 내부로 숨기는 것 속성과 기능 묶기 + 접근 제어자를 통해 실현 좋은 캡슐화 속성은 반드시 숨기자. 객체의 데이터는 객체가 제공하는 기능인 메서드를 통해서 접근해야 한다. 데이터를 외부에 열어두면 클래스 내 데이터를 다루는 로직을 무시하고 데이터를 변경할 수 있음 꼭 필요한 기능만 노출하자. 클래스 내부에서만 사용하는 기능들은 모두 감추는 것 좋다. 사용하는 개발자 입장에서 필요한 기능만 정리되어 복잡도가 낮아진다. 음악 플레이어 예제 메소드 추출 팁 자신이 가진 데이터로 계산한다면, 일반적으로 자기자신이 메서드로 계산하는게 좋다. 나중에 수정이 생기거나 변경이 생길 때 본인만 바꾸면 되므로 관리가 편하다. 접근 제어자 해당 클래스 외부에서 특정 필드나 메서드에 접근하는 것을 허용하거나 제한할 수 있다. 필드, 메서드, 생성자에 사용된다. 지역변수는 스코프 내에서만 사용하므로 접근제어자를 사용하는 의미가 없고 사용할 수도 없다. 클래스에는 일부만 사용가능하다. (public, default) public 클래스는 반드시 파일명과 이름이 같아야 한다. 하나의 자바 파일에 public 클래스는 하나만, default 클래스는 무한정 만들 수 있다. 종류 private: 모든 외부 호출을 막는다. default(package-private): 같은 패키지안에서 호출은 허용한다. protected: default + 다른 패키지여도 상속 관계의 호출은 허용한다. public: 모든 외부 호출을 허용한다. 상속(Inheritance) extends 기존 부모 클래스의 필드와 메서드를 새로운 자식 클래스에서 재사용하는 것 중복을 줄이고 편리하게 확장할 수 있음 단일 상속만 할 수 있다. (다중 상속은 불가능) 만일, 두 부모를 상속받았는데 둘 다 move()라는 메서드를 가지고 있다면 어떤 메서드를 실행해야할지 애매하다. (다이아몬드 문제) 클래스 계층구조가 매우 복잡해질 수 있다. 메서드 오버라이딩 상속 받은 기능을 자식이 재정의하는 것 멤버변수는 오버라이딩되지 않는다. @Override 메모리 구조 상속관계 객체 생성 시 그 내부에 부모와 자식이 모두 생성된다. (하나의 참조값에 두 클래스 정보가 공존) 상속관계 호출시 대원칙 (3개) 상속관계 객체 호출 시, 호출자의 타입을 기준으로 먼저 찾는다. 현재 타입에서 기능을 찾지 못하면 상위 부모 타입으로 기능을 찾아서 실행한다. (끝까지 올라가도 없으면 컴파일 오류 발생) 자식 클래스에 오버라이딩된 메서드가 있다면 항상 우선하여 호출된다. Car와 ElectricCar 예제 super 상속관계에서 부모와 자식의 필드 이름과 메서드 이름이 같은 경우, 부모를 참조하고 싶을 때 super를 통해 부모 클래스로 접근한다. 생성자 상속관계를 사용하면 자식 클래스의 생성자와 부모 클래스의 생성자를 반드시 호출해야 한다. 상속 시 생성자 첫 줄에 super()를 사용해 부모 클래스 생성자를 호출해야 한다. 예외로 첫 줄에 this()(=나말고 다른 생성자를 호출해줘)를 사용할 수 있다. 그러나 자식 생성자 내에서 언젠간 super()가 호출되어야 한다. 부모 클래스의 생성자가 기본생성자라면 super()를 생략할 수 있다. 결과적으로 상속관계 생성자 호출은 부모에서 자식 순으로 실행된다. 다형성(Polymorphism) 다른 타입의 객체를 하나인 것처럼 처리해 주는 것 (아래 두가지 특성 덕분에 실현됨) (= 한 객체가 여러 타입의 객체로 취급될 수 있는 것) 다형성의 본질은 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다는 것 다형적 참조 부모는 자식을 품을 수 있다. (부모 타입의 변수가 다양한 자식 인스턴스를 참조할 수 있다.) Parent poly = new Child() = 업캐스팅 (업캐스팅은 생략이 가능하고 권장된다.) 업캐스팅은 메모리상에 인스턴스가 항상 존재하므로 안전하다. 반면에, 자식은 부모를 품을 수 없다. Child child = poly // 컴파일 에러 만약 부모 클래스에서 자식 클래스의 메서드를 호출하고 싶다면 다운캐스팅 해야한다. Child child = (Child) poly ((Child) poly).childMehtod() (일시적 다운 캐스팅도 가능) 다만, 다운캐스팅은 자식 타입이 메모리상에 존재하지 않을 경우 ClassCastException 런타임 에러를 발생시키므로 매우 주의가 필요하다. 다운 캐스팅 시 instance of를 사용하면 안전하다. 오른쪽에 있는 타입에 왼쪽에 있는 인스턴스 타입이 들어갈 수 있으면 true, 아니면 false new Parent() instanceof Parent // true new Child() instanceof Parent // true new Parent() instanceof Child // false 자바 16부터는 instanceof와 동시에 변수 선언도 가능하다. if (parent instanceof Child child) {...} 다형적 참조 덕분에 자식 인스턴스들을 함수의 부모 타입 매개변수로 참조하거나, 배열의 타입을 부모 타입으로 가져가 자식 인스턴스들을 참조할 수 있다. (중복 제거 및 반복 가능) 메서드 오버라이딩 오버라이딩된 메서드는 항상 우선권을 가진다. 자식에서도 오버라이딩하고 손자에서도 오버라이딩했다면, 손자의 오버라이딩 메서드가 우선권을 가진다. 만일 메서드 오버라이딩이 없다면 항상 부모 타입의 메서드를 호출했을 것이다. 다형성 덕분에 IoC, OCP, DIP, 전략 패턴 등이 가능해짐 다형성이 매우 중요하다. OCP 원칙 좋은 객체 지향 설계 원칙 중 하나 Open for extension, Closed for modification (확장에는 열려있고 변경에는 닫혀 있다) 기존의 코드 수정 없이 새로운 기능을 추가할 수 있다는 의미 다형성을 보완하는 추상 클래스 추상 클래스는 다형성만으로 생기는 두 가지 문제를 해결한다. 부모 클래스를 인스턴스로 생성할 수 있는 문제 (추상적인 개념이 실제로 존재하는 것은 이상함) 부모 클래스를 상속 받는 자식 클래스가 메서드 오버라이딩을 하지 않을 가능성 (개발자의 실수) 추상 클래스 부모 클래스는 제공하지만 실제 생성되면 안되는 클래스 추상적인 개념을 제공하며 부모 클래스 역할로서 상속 목적으로 사용 인스턴스를 생성할 수 없음 (제약 1) abstract class AbstractAnimal {...} 추상 메서드 자식 클래스가 반드시 오버라이딩해야 하는 메서드 (제약 2) 메서드 바디가 없음 추상 메서드가 하나라도 있는 클래스는 추상 클래스로 선언해야 한다. public abstract void sound() 인터페이스 - 순수 추상 클래스를 지원 인터페이스 등장 배경 추상 클래스는 여전히 자신의 메서드를 가질 수 있다. 반면에, 순수 추상 클래스는 추상 클래스를 실행 로직이 전혀 없는 추상 메서드로만 구성한 것을 의미한다. 이는 다형성을 위한 규격, 마치 USB 인터페이스 같은 느낌을 준다. 자바는 이러한 순수 추상 클래스를 편리하게 사용할 수 있도록 인터페이스를 지원한다. 특징 interface 키워드, 구현시 implements 키워드 사용 인터페이스의 메서드는 모두 public abstract이다. (직접 쓸 수도 있지만 생략 권장) 인터페이스의 멤버 변수는 public static final이다. (마찬가지로 생략 권장) 구현이라는 용어 사용 상속은 부모의 기능을 물려 받는 것이지만, 인터페이스는 모든 메서드가 추상 메서드이므로 물려받을 기능이 없고 오히려 자식이 오버라이딩해서 메서드를 구현해야 한다. 다만, 자바 입장에서는 상속이나 구현이나 동일하게 동작한다. 클래스 & 추상 클래스 & 인터페이스는 코드와 메모리 구조상 모두 동일하다. 다중 구현을 지원 유용한 이유 제약 인터페이스의 메서드를 반드시 구현하라는 규약을 준다. 순수 추상 클래스를 지향해도 추상 클래스는 다른 개발자가 미래에 메서드를 추가할 수 있기 때문에, 인터페이스는 이를 예방한다. 다중 구현 클래스의 상속이 하나의 부모만 지정할 수 있는 것과 달리, 인터페이스는 여러 부모를 둘 수 있다. 인터페이스는 자신이 구현을 가지지 않고, 자식이 메서드를 구현한다. 또한 어차피 오버라이딩으로 인해 자식의 메서드가 호출된다. 따라서, 다이아몬드 문제가 발생하지 않는다. 실무적 장단점 인터페이스는 기획이나 사용 기술이 구체화되지 않았을 때, 구현을 미룰 수 있다. (장점) 어떤 DB를 사용할지 미정이라면, 인터페이스만 구현 후 메모리 레포지토리를 사용 할인 정책이 미정이라면, 인터페이스만 구현 후 0원 할인으로 미리 개발 가능 인터페이스는 추상화라는 비용을 발생시킨다. (단점) 개발자가 코드를 읽을 때 인터페이스를 항상 본 후 구현체를 보게 되어 읽는 시간이 증가한다. 대부분 모든 곳에 인터페이스를 먼저 구현하는 것이 이상적이지만, 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용하고 향후 꼭 필요할 때 리팩토링해서 인터페이스를 도입하는 것도 좋다. 의존 관련 용어 정리 A -> B (UML) = A가 B를 안다. = A가 B를 의존한다. = A가 B를 상속받았다. (A가 자식이고 B가 부모다) = A가 B를 사용한다. 좋은 객체 지향 설계의 5가지 원칙 (SOLID) 클린 코드 저자 Robert Martin(로버트 마틴)은 좋은 객체 지향 설계의 5가지 원칙을 제시한다. 단일 책임 원칙(SRP, Single responsibility principle) 한 클래스는 하나의 책임만 가져야 한다. 책임의 추상적인 표현이지만, 변경을 기준으로 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것 개방-폐쇄 원칙(OCP, Open/closed principle) 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 다형성을 활용해 기존 코드는 변경하지 않고 새로운 기능들을 추가할 수 있다. 리스코프 치환 원칙(LSP, Liskov substitution principle) 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 다형성의 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것 다형성에 신뢰성을 부여하고 지원하는 원칙 예시 자동차 인터페이스의 엑셀은 앞으로 가야하는 기능인데, 뒤로 가게 구현하면 LSP 원칙 위반 느리게 가더라도 앞으로 가야한다. 인터페이스 분리 원칙(ISP, Interface segregation principle) 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 인터페이스가 명확해지고 대체 가능성이 높아진다. 예시 자동차 인터페이스 -> 운전 인터페이스 & 정비 인터페이스로 분리 사용자 클라이언트 -> 운전자 클라이언트 & 정비사 클라이언트로 분리 정비 인터페이스가 변해도 운전자 클라이언트에 영향을 주지 않음 의존 관계 역전 원칙(DIP, Dependency inversion principle) 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. 즉, 클라이언트 코드가 구현 클래스에 의존하지 말고 인터페이스에 의존하라는 의미 다만, 다형성만으로는 OCP, DIP 원칙을 지킬 수 없다. OCP, DIP를 지키려고 하다보면 결국 스프링 프레임워크를 만들게 된다. Reference 김영한의 실전 자바 - 기본편 스프링 핵심 원리 - 기본편

Java-Ecosystem · 2024-02-06

자바 메모리 구조와 변수, 메서드 종류

자바 메모리 구조 메서드 영역 프로그램을 실행하는데 필요한 공통 데이터를 관리 프로그램의 모든 영역에서 공유됨 구성 클래스 정보: 클래스 실행 코드 (바이트 코드) - 필드, 메서드, 생성자 코드 등 static 영역: static 변수, 메서드, 클래스들을 보관 (프로그램 시작부터 끝까지 메모리 할당) 런타임 상수 풀: 프로그램을 최적화하기 위해 공통 리터럴 상수를 보관 스택 영역 실제 프로그램이 실행되는 영역 실행 스택을 생성하고 메서드가 호출될 때마다 스택에 스택 프레임을 쌓는다. 메서드가 종료되면 스택프레임을 제거한다. 지역변수, 중간 연산 결과, 메서드 호출 정보 등이 스택 프레임에 포함된다. 처음 자바를 실행하면 main()을 실행하기 위해 실행 스택에 main() 스택 프레임을 하나 생성한다. 힙 영역 인스턴스가 생성되는 영역 (new 명령어를 사용하면 여기를 사용) 가비지 컬렉션이 이루어지는 영역이며, 더 이상 참조되지 않는 객체는 GC에 의해 제거된다. 메서드 코드의 위치 객체가 생성될 때, 인스턴스 내부 변수 값은 각각 힙 영역에 할당되어 독립적으로 존재하지만, 메서드는 새로운 메모리 할당없이 공통된 코드를 공유한다. 따라서, 인스턴스 메서드를 호출하면 실제로는 메서드 영역에 있는 코드를 힙 영역으로 불러와서 수행한다. 단, static 메서드는 메서드 영역의 클래스 정보 코드를 사용하겠지만, 실행도 메서드 영역의 클래스 정보에서 한다. 멤버 변수의 종류 인스턴스 변수 (static이 붙지 않음) 각각의 인스턴스에 독립적으로 소속되어 있는 변수 static 변수 (static이 붙음) 클래스 자체에 소속되어 공용으로 함께 사용할 수 있는 변수 static 변수 = 정적 변수 = 클래스 변수 메서드 영역 (static 영역)에서 관리 클래스명 + . 으로 접근 (자신의 클래스에 있는 정적 변수라면 클래스명 생략 가능) 처음 자바가 로딩될 때 하나만 생성 일반적으로 자바 프로그램이 실행되고 JVM이 처음 뜰 때, 클래스 정보를 메소드 영역에 모두 불러 들이고, static이 붙은 변수들은 메모리(static 영역)에 할당해버린다. 이런 static 변수들은 이 때 딱 하나 만들어지고 Java가 끝날 때까지 계속 쓸 수 있다. 변수의 생명주기 지역변수(매개변수 포함): 스택 영역의 스택 프레임에 존재 (메서드 종료 시 소멸) 인스턴스 변수: 힙 영역에 존재 (GC 발동 시 소멸) 클래스 변수: 메서드 영역의 static 영역에 존재 (JVM 종료 시 소멸) 지역변수 < 인스턴스 변수 < 클래스 변수 지역 변수가 제일 짧고, 클래스 변수가 제일 길다. static이 정적인 이유 힙 영역에 생성되는 인스턴스 변수는 런타임에서 동적으로 생성되고 제거되지만, static 변수는 프로그램 시작 시점에 만들어지고 프로그램 종료 시점에 제거되므로 상대적으로 매우 정적이다. 멤버 메서드의 종류 인스턴스 메서드 (static이 붙지 않음) 인스턴스에 소속되어 인스턴스를 생성해야 사용할 수 있는 메서드 static 메서드 (static이 붙음) 클래스에 소속되어 클래스에 바로 접근해 사용할 수 있는 메서드 static 메서드 = 정적 메서드 = 클래스 메서드 인스턴스 변수를 필요로 하지 않는 단순 기능만 제공하는 경우 사용 (유틸리티성 메서드) static 메서드는 static만 사용할 수 있다.(정적변수나 정적 메서드) main()가 대표적 정적 메서드 (main()이 같은 클래스에서 호출하는 메서드도 정적 메서드) 자주 호출해야 한다면 static import를 통해 클래스 명을 생략하고 메서드를 호출할 수 있다. final 변수에 final 키워드가 붙으면 더는 값을 변경할 수 없다. 특정 변수의 값을 할당한 이후 변경하지 않아야 한다면 사용하자. (고객 id 같은 부분) 의미 있는 경우 static final 필드(클래스 멤버 변수)를 필드 초기화 하는 것 (메모리 중복 없음) 상수도 static final을 지정한다. 생성자를 이용해서 final 필드(인스턴스 멤버 변수)를 초기화 하는 것 의미 없는 경우 final 필드(인스턴스 멤버 변수)를 필드 초기화 하는 것 (인스턴스마다 값이 중복되어 메모리 낭비) 클래스 final 상속의 끝을 의미, final로 선언된 클래스는 상속할 수 없다. 메서드 final 오버라이딩의 끝을 의미, final로 선언된 메서드는 오버라이드 될 수 없다. Reference 김영한의 실전 자바 - 기본편

Java-Ecosystem · 2024-02-06

IntelliJ 단축키 정리

자동완성 계열 iter For Each Syntax sout println soutv println + 원하는 변수 soutm 현재 클래스와 메소드 이름을 출력한다. 리팩토링 계열 command + shift + T 클래스 지정하면 그에 대한 테스트 틀 생성 command + shift + 위/아래 위/아래 메서드와 위치 변경 (메서드에 커서 선택 후 진행) command + shift + 8 Column Selection Mode (여러 라인 동시 수정 가능) command + n 파일 혹은 코드 생성 command + option + N Inline variable로 리팩토링 command + option + V 변수 추출 및 추천 (Introduce variable) command + option + M 메소드 추출 및 추천 command + option + shift + L 파일 코드 재정렬 option + Enter Context에 따른 가능 액션 종류를 보여줌 (create method, create class 등) 자동 import, static import(Add on-demand static import) 지원 option + option + 위/아래 Multi-line select option + shift + click Specific line select ctrl + T 리팩토링 ctrl + O 오버라이드 shift + F6 클래스, 변수, 파라미터 이름을 일괄적으로 변경 유틸 계열 command + B 코드가 사용된 모든 곳들을 추적 command + option + B 해당 인터페이스의 모든 구현체들 추적 command + P 파라미터 정보 제공 command + E 과거 행동 이력 및 이전 파일 이동 command + O Navigate shift X 2 Search (Navigate과 유사) ctrl + R 바로 이전 것 실행 ctrl + shift + R 클래스 레벨 실행 option + ↑ 범위 블록 설정 F2 오류가 발생한 곳으로 커서 이동 command + 숫자 0 Commit 1 프로젝트 디렉토리 영역 혹은 코드 작업 영역 선택 4 Run window 5 Debug window 6 Problems 9 Git log command + F_number F12 해당 클래스의 멤버 변수, 메서드, 상속 클래스 등의 전체 정보 보기

Java-Ecosystem · 2024-02-05

자바 주요 syntax 정리

Java-Ecosystem · 2024-01-28

Java 기본 특징

자바 표준 스펙 자바는 표준 스펙이 존재하고 여러 회사가 자신에 입맞에 맞게 이를 구현한다. 자바 표준 스펙 자바의 설계도 문서 자바 커뮤니티 프로세스(JCP)를 통해 관리 구현 자바 표준 스펙에 맞춰 여러 회사가 각자에 최적화된 자바 프로그램을 개발 오라클 Open JDK, Adoptium Eclipse Temurin, Amazon Corretto etc… 오라클 Open JDK 사용하다가 Amazon Corretto 사용해도 대부분 큰 문제 없음 각 회사들은 다양한 OS(Mac, Windows, 리눅스)에 맞는 자바도 함께 제공 컴파일과 실행 소스코드(Source code) 개발자가 .java 확장자의 자바 소스코드를 작성한다. 컴파일(Compile) 단계 자바가 제공하는 javac 를 사용해, .java -> .class 파일 생성 command: javac Hello.java 즉, 자바 컴파일러가 소스코드를 바이트 코드로 변환 자바 가상 머신에서 더 빠르게 실행될 수 있게 최적화하고 syntax error 검출 실행(Runtime) 단계 java 프로그램을 사용해 자바를 띄우고 바이트코드인 .class 파일을 실행하면, JVM(실제 자바 프로그램 = 자바 가상 머신)이 띄워지면서 바이트코드를 읽고 프로그램을 실행한다. command: java Hello (Hello.class 의 .class 확장자를 빼고 입력) 운영체제 독립성 일반적인 프로그램은 다른 운영체제에서 실행할 수 없다. Windows 프로그램은 Windows OS가 사용하는 명령어들로 구성되어 있어서, 다른 OS와 호환되지 않음. 반면에, 자바 프로그램은 자바가 설치된 모든 OS에서 실행 가능 (호환성) 각 OS에 맞게 설치된 자바는 해당 OS의 명령어들로 컴파일된 .class 바이트코드를 실행 덕분에 개발할 때와 서버 실행 시 환경에 맞춰 다른 자바를 사용할 수 있다. 개발: Mac, Windows 서버: AWS Linux (Amazon Corretto 자바 설치) Reference 김영한의 자바 입문 - 코드로 시작하는 자바 첫걸음

Java-Ecosystem · 2024-01-28

Lucian Log

Contact

Java