반응형

JAVA/Effective Java

    제네릭 - 규칙 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..

    클래스와 인터페이스 - 규칙 20 태그 달린 클래스 대신 클래스 계층을 사용하라.

    클래스에 상황에 따라서 역할을 변경하는 태그 달린 클래스를 볼 수 있다. 예를 들어, 아래 유형과 같이 탈것을 나타내는 클래스는 어떤 형태로 사용하느냐에 따라서 자동차가 될수도, 자전거가 될 수도 있다. 12345678910111213141516171819202122232425class Vehicle { enum Type { CAR, BICYCLE }; final Type type; public Vehicle (double pedalCount) { this.type = Type.BICYCLE; } public Vehicle (double license, int sheetCount) { this.type = Type.CAR; } // 바퀴수를 반환하는 메서드 public int getWheelCount()..

    클래스와 인터페이스 - 규칙 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..

    클래스와 인터페이스 - 규칙 15 변경 가능성을 최소화하라

    immutable 클래스는 그 객체를 수정할 수 없는 클래스이다. 객체 내부의 정보는 객체가 생성될 때 주어진 것이며, 객체가 살아 있는 동안 그대로 보존된다. 이러한 변경 불가능 클래스를 만드는 이유는 다양하다. - 설계가 쉽다. - 오류 가능성이 적고 안전하다. 생성 규칙 - 객체 상태를 변경하는 메서드를 제공하지 않는다. (setter) - 상속할 수 없도록 진행한다. => 하위 클래스가 객체 상태가 변경된 것처럼 동작할 수 있다. => class에 final을 붙힌다. - 모든 필드를 final로 생성한다. => 이렇게 생성할 경우 생성된 객체에 대한 참조가 동기화(Synchronization)없이 다른 스레드로 전달 되어도 안전하다. - 모든 필드를 private로 선언한다. => 모든 필드를 ..

    클래스와 인터페이스 - 규칙 14 public 클래스 안에는 public 필드를 두지 말고 접근자 메서드를 사용하라

    가끔 아래 기재된 클래스 처럼 클래스 내부에서 사용할 데이터를 처리하기 위해 임시 클래스를 만드는 경우가 있다. 1234class Temp { private String t; private String f;} cs 이런 경우에는 이 클래스를 직접 조작할 수 있기 때문에 캡슐화의 이점이 사라질 수 밖에 없다. 하지만 package-private 클래스나 private 중첩 클래스는 데이터의 필드가 공개되더라도 잘못이라 말할 수 없다. 대신 클래스가 추상화 하려는 내용을 제대로 기술하기만 하면 된다. 기존의 public 클래스가 내부 필드를 외부로 공개하는 것은 바람직하지 않지만, 변경 불가능 필드는 그 심각성이 덜하다. 다음과 같이 내부 변수를 public으로 공개하여도 어떤한 동작도 하지 못하게(immu..

반응형