아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라
이펙티브 자바아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라123456789101112131415package com.github.sejoung.codetest.constantinterface;// 코드 22-1 상수 인터페이스 안티패턴 - 사용금지! (1 ...
Read more
아이템 21. 인터페이스를 구현하는 쪽을 생각해 설계하라.
이펙티브 자바아이템 21. 인터페이스를 구현하는 쪽을 생각해 설계하라.java 8 이전에는 인터페이스를 해치지 않고 메서드를 추가할 방법이 없었지만 지금은 default 메소드가 생겼다.그렇다고 해서 모든 위험이 사라진것은 아니다. 생각할수 있느 모든상황에서 불변식을 ...
Read more
Java의 SimpleDateFormat은 thread-safe 하지 않다. multi-threaded 환경에서 조심히 사용하자
Java의 SimpleDateFormat은 thread-safe 하지 않다. multi-threaded 환경에서 조심히 사용하자1234567891011121314151617181920212223242526272829303132333435363738394041424344 ...
Read more
아이템 20. 추상 클래스 보다는 인터페이스를 우선하라
이펙티브 자바아이템 20. 추상 클래스 보다는 인터페이스를 우선하라자바는 단일상속만 되니 추상클래스는 단 하나만 구현할수 있다.인터페이스는 어떠한 상속을 했던간에 인터페이스가 선언한 메소드를 구현하고 있으면 같은 타입으로 인식한다. 그래서 기존 클래스에도 손쉽게 새로운 ...
Read more
아이템 19. 상속을 고려하고 설계하고 문서화 하라 그렇지 않으면 상속을 금지하라
이펙티브 자바아이템 19. 상속을 고려하고 설계하고 문서화 하라 그렇지 않으면 상속을 금지하라상속용 클래스는 재정의 할수 있는 매서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 된다. 이부분은 바로 직전 아이템인 18번에서 나왔듯이 상속을 했지만 내부사용을 상세하게 ...
Read more
아이템 18. 상속보단 컴포지션을 사용하라
이펙티브 자바아이템 18. 상속보단 컴포지션을 사용하라상속은 코드를 재사용하는 강력한 수단이지만 항상 최선은 아니다. 상속의 단점 매서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 1234567891011121314151617181920212223242526272829 ...
Read more
아이템 17. 변경가능성을 최소화하라.
이펙티브 자바아이템 17. 변경가능성을 최소화하라.불변 클래스란 인스턴스의 내부 값을 수정할 수 없는 클래스다.불변 인스턴스에 간직한 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다. 클래스를 불변으로 만들려면 다음 다섯 가지 규칙을 따르면 된다. 객체 ...
Read more
아이템 16. public classes에는 public fields를 사용하지 말고 접근 메소드를 사용해라.
이펙티브 자바아이템 16. public classes에는 public fields를 사용하지 말고 접근 메소드를 사용해라.123456789package com.github.sejoung.codetest.accessor;public class Point { ...
Read more
아이템 15. 클래스와 맴버의 접근권한을 최소화 하라.
이펙티브 자바아이템 15. 클래스와 맴버의 접근권한을 최소화 하라.잘 설계된 컨포넌트와 어설프게 설계된 컨포넌트에 차이점은 내구 구현 정보와 데이터를 얼마나 잘숨겼는지에 따른다.이런것을 은닉화라고 한다. 정보 은닉의 장점 시스템 개발 속도를 높인다. 여러 컴포넌트를 ...
Read more
아이템 14. Comparable을 구현할지 고려하라.
이펙티브 자바아이템 14. Comparable을 구현할지 고려하라.Comparable 인터페이스의 유일무이한 메서드인 CompareTo메서드는 이번장에서 다룬 다른 메소드들과 달리 Object 메소드가 아니다.성격은 두가지만 빼면 Object의 equals와 같다. 다 ...
Read more