[Java8 In Action] #12 새로운 날짜와 시간 API [Java8 In Action] #12 새로운 날짜와 시간 API Java8 In Action 내용을 보며 정리한 내용입니다.정리자는 기존에 Java8 을 한차례 rough 하게 공부한 적이 있고, Kotlin 역시 공부한 적이 있습니다.위의 prerequisite 가 있는 상태에서 추가적인 내용만 정리한 내용이므로, 제대로 공부를 하고 싶다면 책을 구매해서 보길 권장합니다! 12.1. LocalDate, LocalTime, Instant, Duration, Period 12.1.1. LocalDate 와 LocalTime 사용 -LocalDate 는 시간을 제외한 날짜를 표현하는 불변 객체.이 녀석은 어떤 시간대 정보도 포함하지 않는다. -정적 팩토리 메소드 of 로 LocalDate 인스턴스를 만들 .. 2019. 1. 1. [Effective Java] 방어 가능한 readObject 메소드를 작성하자 [Effective Java] 방어 가능한 readObject 메소드를 작성하자 - Serializable 하게 만들고 싶은 class 의 물리적 표현과 논리적 표현이 같다고 해도, 무조건 implements Serializable 을 붙이는 것이 능사가 아니다. readObject 는 바이트 스트림 인자 하나만 받는 생성자라고 볼 수 있는데 누군가가 고의적으로 이상한 바이트 스트림을 제공할 경우 문제가 될 수 있다. 따라서 readObject 메소드를 만들고, defaultReadObject() 를 수행 후, 역직렬화되는 객체의 유효성을 검사해야 한다. 만일 유효성 검사에 실패하면, readObject 메소드에서 InvalidObjectException 예외를 발생시켜야 한다. - 위의 방법으로 유효성.. 2017. 3. 24. [Effective Java] 필요하면 방어 복사본을 만들자. [Effective Java] 필요하면 방어 복사본을 만들자. - 자바는 꽤나 안전한 언어이지만, 우리 클래스의 클라이언트가 불변 규칙을 파괴하기 위해 최선을 다할 거라는 가정하에 방어적으로 프로그램을 작성해야 한다. - 가변 객체인 매개 변수는 각각의 방어복사본(defensive copy)을 만들어서 생성자에 전달해야 한다. 그렇지 않으면 예상치 못한 여러 상황이 발생할 수 있다. - 방어복사본은 매개 변수의 유효성 검사에 앞서 만들어야 하며, 유효성 검사는 원본이 아닌 복사본을 대상으로 해야 한다!! ( TOCTOU 공격 ( 검사시간/사용시간) 이슈 ) - clone 은 위험한 복사방법이므로 가급적이면 다른 방법으로 복제하자. final 이 아닌 Class 는 sub class 가 clone 을 상속.. 2017. 1. 10. [Effective Java] 가변성을 최소화 하자. [Effective Java] 가변성을 최소화 하자. -불변 클래스는 자신의 인스턴스가 갖는 값을 변경할 수 없는 클래스. - 불변 클래스는, 가변 클래스에 비해 설계와 구현 및 사용이 더 쉽다. 에러 발생이 적으며 보안이나 사용 측면에서 더 안전하다. - 불변 클래스를 만들 때는 다음 다섯 가지 규칙을 따르자. 1. 객체의 상태를 변경하는 그 어떤 메소드도 제공하지 않는다. 2. 상속을 할 수 없도록 하자. ( class 에 final 을 주어 막을 수 있다. ) 3. 모든 필드를 final 로 지정한다. 4. 모든 필드를 private 으로 지정한다. 5. 가변 컴포넌트의 직접적인 외부 접근을 막자. 생성자와 접근자 메소드 및 readObject 메소드에서 해당 객체의 방어 복사본을 만들어 사용하도록.. 2016. 10. 24. 병렬 프로그램을 위한 어노테이션 병렬 프로그램을 위한 어노테이션 클래스 어노테이션 - @Immutable, @ThreadSafe, @NotThreadSafe. - @Immutable 어노테이션은 해당 클래스가 불변(immutable) 클래스임을 나타낸다. 자동적으로 @ThreadSafe 이기도 하다. - @NotThreadSafe 어노테이션은 해당 클래스가 스레드 안전성을 확보하지 못하고 있다는 의미이다. 스레드 안전성을 확보했다는 어노테이션을 달지 않은 모든 클래스는 당연하게 @NotThreadSafe 이기 때문에 꼭 사용해야만 하는 것은 아니다. 다만 한눈에 알아볼 수 있도록 하려면 @NotThreadSafe 어노테이션을 달아두는 편이 좋다. - 어노테이션은 상대적으로 방해되는 부분이 적으면서 클래스 사용자나 유지보수 담당자 모두에.. 2015. 7. 20. [Effective Java] 생성자의 매개변수가 많을 때는 빌더(builder)를 고려하자. 생성자의 매개변수가 많을 때는 빌더(builder)를 고려하자. - static 팩토리 메소드와 생성자는 공통적 제약이 있다. 선택가능한 매개변수가 많아질 경우 신축성 있게 처리하지 못한다. - 텔레스코핑 생성자(telescoping constructor) 패턴이 대안이 될 수 있으나, 마찬가지로 매개변수 수가 증가하면 무척 번거로워 진다. 가독성도 떨어지고, 유지보수도 어려워진다. ( 갯수를 세고 의미를 파악하는데만도 한세월~ ) - 자바빈즈(Java Beans) 패턴이 두번째 대안이 될 수 있으나, 이 패턴은 심각한 단점을 가지고 있다. 여러 번의 메소드 호출로 나누어져 인스턴스가 완성되기 때문에 객체가 일관된 상태를 유지하지 못할 수 있다. ( multi thread 환경 ) 또한 자바빈즈는 불변 .. 2015. 2. 8. 반응형 이전 1 다음
