자바
제네릭 - 규칙 26 가능하면 제네릭 자료형으로 만들 것
클래스를 제네릭 자료형으로 제네릭화 해서 사용하면 많은 이점이 생긴다. 제네릭화 하는 과정의 첫 번째는 선언부에 형인자를 추가하는 것이다. 1public class Stackcs 하지만 형인자를 추가하다 보면, 배열에 E 자료형을 추가하려 할 때 문제가 발생한다. (25 규칙 확인) 이를 해결하기 위한 방법은 다음과 같다. 1. Object 배열을 만든 다음 제네릭 자료형으로 캐스팅 하는 것이다. => 하지만 이것은 다음과 같은 오류를 발생시킨다. => 만약 개발자 판단으로 형 안전성이 입증된다고 판단되는 경우 경고를 없애 주어야 한다. (규칙 24) 2. Object 배열로 사용하고 원소를 꺼내서 사용할 때 E로 캐스팅하여 사용한다. => 형안전성에 대한 개발자 판단이 완료되고 나면 @SuppressW..
제네릭 - 규칙 25 배열 대신 리스트를 써라
배열과 제네릭 자료형(List)의 차이 배열은 convariant 제네릭 자료형은 invariant 자료형이다. 차이 1. covariant - Sub[] 이 Super 의 하위자료형이라면 Sub[] 은 Super[]의 서브 타입이다. invariant Type1 Type2 List List 의 서브타입도 슈퍼타입도 아니다. 그렇기 때문에 List은 List의 서브타입 또는 슈퍼타입도 될 수 없다. 이런 이유로 제네릭 쪽이 배열보다 취약한 것 같지만 다음과 같은 문제를 보면 오히려 문제가 발생하는 부분은 배열이다. 12345678// 실행 중에 문제를 일으킴 (배열)Object[] objectArray = new Long[1];objectArray[0] = "babo ya";=> 컴파일시 문제는 없지만 ..
제네릭 - 규칙 24 무점검 경고를 제거하라
제네릭을 사용하다보면 다양한 원인으로 인해 컴파일러 경고 메시지를 보게된다. 이런 무점검 경고 가운데 상당수는 쉽게 없앨 수 있다. 예를 들면 다음과 같은 경우가 있다. 123456Set example = new HashSet(); // warning : unchecked conversion // 해결 방법Set example = new HashSet();cs 이런 예와 같은 무점검 경고는 가능하다면 없애야 typesafe(형안전성)을 보장할 수 있어 ClassCastException 발생을 방지할 수 있다. 형 안전성이 확실한 코드를 계속 warning 상태로 놔두게 되면 진짜 중요한 메시지를 놓칠 수 있기 때문에 만약 제거가 어려운 경고 메시지는 형 안전성이 확실하다고 생각될 경우에만 @Supress..
제네릭 - 규칙 23 새 코드에는 무인자 제네릭 자료형을 사용하지 마라
1. 용어 정리 - List와 같은 형식은 제네릭 클래스와 인터페이스로서 제네릭 자료형이라고 한다. - 제네릭 자료형은 raw Type인 무인자 자료형을 같는다. List의 raw type은 List이다. - raw type을 통해 사용하면 추후에 element를 사용할 시 캐스팅을 잘 해주어야 한다. 그렇기에 형 안정성 확보를 위해 컬렉션에 담길 객체의 자료형이 무엇인지 알려준다. 2. raw type vs generic type 1234567891011121314151617181920212223// 문제 1 (캐스팅 오류)List a = new ArrayList();a.add(generic); for (Iterator i = a.iterator(); i.hasNext();) { (Dv) i.next(..
클래스와 인터페이스 - 규칙22 멤버 클래스는 가능하면 static으로 선언하라.
중첩 클래스 (nested class)는 다른 클래스안에 선언된 클래스이다. 이런 중첩 클래스는 4가지 종류로 구성되어있다. 1. static member class 2. non-static member class 3. anonymous class 4. local class. 2 ~ 4번 클래스는 내부 클래스(inner class)이다. 상황별 중첩 클래스 사용 그럼 위에 출력한 4가지의 중첩 클래스의 적절한 사용 시기를 알아보자. 1. 정적 멤버 클래스 (static member class) - 정적 멤버 클래스는 바깥 클래스의 모든 멤버에 접근할 수 있다. (private 멤버 변수도 접근 가능) - 다른 정적 멤버와 동일하게 접근 권한 규칙을 따른다. - private static member cl..
클래스와 인터페이스 - 규칙 21 전략을 표현하고 싶을 때는 함수 객체를 사용하라.
호출 대상에 대해 어떠한 작업을 수행하는 것을 전략 패턴이라고 한다. 12345class StringCompare { public int compare (String s1, String s2) { return s1.length() - s2.length(); }}Colored by Color Scriptercs 두 개의 문자열을 받아서 비교하는 클래스를 사용할 수 있는 전략 패턴이다. 비교가 필요할 경우 매번 StringCompare 클래스를 생성하지 말고, 싱글톤 패턴을 정의하여 가져다가 사용하면 더욱 편리하다. 하지만 이 StringCompare 클래스의 경우 객체를 메서드에 전달하기 위해서는 인자의 자료형이 String이어야 한다. 따라서 Compareator 인터페이스를 정의 하여 이를 String..
클래스와 인터페이스 - 규칙 19 인터페이스는 자료형을 정의할 때만 사용하라.
인터페이스를 구현하는 클래스를 만들경우, 그 인터페이스는 해당 클래스의 객체를 참조할 수 있는 자료형 역할을 하게 된다. 상수 인터페이스 => 메서드가 없고 static final 필드만 있어, 상수 이름 앞에 클래스 이름을 붙이는 번거로움을 피하기 위해서이다. 123public interface PhysicalConstants { static final double AVOGADROS_NUMBER = 6.02312312323;}Colored by Color Scriptercs 이런 상수 인터페이스 패턴은 인터페이스를 잘못 사용한 것이다. => 인터페이스는 사용자에게 이러한 기능을 구현한 클래스라는 명세를 알려주는거와 같은데 상수 인터페이스는 기능 명세를 제공하는 것이 아니라 상수값을 사용하기 위한 것으로..
클래스와 인터페이스 - 규칙 18 추상 클래스 대신 인터페이스를 사용하라.
자바는 다중 상속이 되지 않기 때문에, 추상 클래스 보다 인터페이스를 사용하는 것이 좋다. 믹스인 인터페이스는 믹스인을 정의하는 데 이상적이다. => 믹스인은 클래스가 주 자료형 이외에 추가로 구현할 수 있는 자료형으로 어떤 선택적 기능을 제공한다는 사실을 선언하기 위해 쓰인다. => 예를 들면, Comparable은 어떤 클래스가 자기 객체를 다른 객체와의 비교 결과에 따른 순서를 갖는다고 선언할 때 쓰는 인터페이스이다. 이런 믹스인 기능을 추상클래스에 할 수 없다. => 클래스가 가질 수 있는 상위 클래스는 하나 이기 때문에 좋은 방법이 아니다. 인터페이스는 여러 속성을 합쳐서 새로운 속성을 만들 수 있다. => singer와 SongWriter 속성을 합쳐서 새로운 인터페이스를 만들 수 있다. 12..
클래스와 인터페이스 - 규칙 17 계승을 위한 설계와 문서를 갖추거나, 그럴 수 없다면 계승을 금지하라.
16번에서 정의한 것처럼 계승 (이하 상속)을 받을 경우 문제를 야기할 수 있다. 그렇기에 이를 예방하기 위해서 문서를 잘 갖추고 있어야 하는데 문서를 갖춘다는 것은 어떤 의미일까? 이는 재정의 가능 메서드를 내부적으로 어떻게 사용하는지(self-use)반드시 남기라는 것이다. -> 어떤 재정의 가능 메서드를 어떤 순서로 호출하는지, 그리고 호출결과가 추후 어떤 영향을 미치는지 문서로 남기라는 의미이다. 여러 문제를 야기할 수 있기에, 계승에 맞도록 설계하고 문서화하지 않은 클래스에 대한 하위 클래스는 만들지 않아야 한다. 출처 : 조슈아 블로크, 『 Effective Java 2/E』, 이병준 옮김, 인사이트(2014.9.1), 규칙17 인용.
클래스와 인터페이스 - 규칙 16 계승하는 대신 구성하라.
상속은 코드를 재사용 할 수 있도록 돕는 강력한 도구이지만, 항상 최선이라 할 수 없다. 제대로 구현하지 못한 경우 문제를 유발할 가능성이 크기 때문이다. 그리고 같은 패키지 내부에 존재하는 클래스를 상속받아야한다. 상속은 일반적으로 캡슐화 원칙을 위반한다. 그 이유는 상위클래스의 일부 개념이 변경될 경우, 하위클래스는 그대로 영향을 받을 수 밖에 없기 때문이다. 이를 예방하기 위해서는 문서를 제대로 구현해 놓아야 한다. 문제가 야기될 수 있는 상황은 다음과 같다. 1. 기존의 재정의 하여 사용하였을 경우. -> 문제가 될 수 있는 상황을 예를 들면, HashSet을 상속하고 add관련 메서드를 재정의하여 객체를 추가한 횟수를 확인하는 로직을 추가하는 로직을 만들어보자 1234567891011121314..