반응형 Java/Effective Java 3E61 [이펙티브자바 3판] ITEM25. 톱레벨 클래스는 한 파일에 하나만 담으라 이번장의 핵심은... 소스 파일 하나에는 반드시 톱 레벨 클래스 (혹은 톱 레벨 인터페이스)를 하나만 담자 이 규칙만 따른다면 컴파일러가 한 클래스에 정의를 여러 개 만들어내는 일은 사라진다 소스 파일을 어떤 순서로 컴파일하든 바이너리 파일이나 프로그램의 동작이 달라지는 일은 결코 일어나지 않을 것이다 소스 파일에 하나의 톱레벨 클래스를 여러 개 선언하더라도 상관없지만, 아무런 득이 없고 심각한 위험을 감수해야 한다 한 클래스를 여러 가지로 정의할 수 있으며, 그 중 어느것을 사용할지는 어느 소스 파일을 먼저 컴파일하냐에 따라 달리지기 떄문이다 예) Utensil 클래스와 Dessert 클래스가 Utensil.java라는 한 파일에 정의되어 있다고 해보자 // Utensil.java 에 2개의 클래스가 .. 2020. 10. 5. [이펙티브자바 3판] ITEM24. 멤버 클래스는 되도록 static으로 만들라 이번장의 핵심은... 중첩 클래스에는 네 가지가 있으며, 각각의 쓰임이 다르다 메서드 밖에서도 사용해야 하거나 메서드 안에 정의하기엔 너무 길다면 멤버 클래스로 만든다 멤버 클래스의 인스턴스 각각이 바깥 인스턴스를 참조한다면 비정적으로, 그렇지 않다면 정적으로 만들자 중첩 클래스가 한 메서드 안에서만 쓰이면 그 인스턴스를 생성하는 지점을 단 한 곳이고 해당 타입으로 쓰기에 적합한 클래스나 인터페이스가 이미 있다면 익명 클래스로 만들고, 그렇지 않다면 지역 클래스로 만들자 중첩 클래스? 중첩 클래스란 다른 클래스 안에 정의된 클래스를 말한다 자신을 감싼 바깥 클래스에서만 쓰여야 하며, 그 외에 쓰임새가 있다면 톱 레벨 클래스로 만들어야 한다 종류 1. 정적 멤버 클래스 2. (비정적) 멤버 클래스 3. 익.. 2020. 10. 4. [이펙티브자바 3판] ITEM23. 태그 달린 클래스보다는 클래스 계층 구조를 활용하라 이번장의 핵심은... 태그 달린 클래스를 써야 하는 상황은 거의 없다 새로운 클래스를 작성하는 데 태그 필드가 등장한다면 태그를 없애고 계층 구조를 대체하는 방법을 생각해보자 기존 클래스가 태그 필드를 사용하고 있다면 계층 구조로 리팩터링하는 걸 고민해보자 태그 달린 클래스? 태그 달린 클래스가 뭔지 예제를 보자 // 태그 달린 클래스 - 클래스 계층 구조보다 훨씬 나쁘다! class Figure { enum Shape {RECTANGLE, CIRCLE}; // 태그 필드 - 현재 모양을 나타낸다 final Shape shape; // 사각형일 때만 쓰임 double length; double width; // 원일 때만 쓰임 double radius; // 원용 생성자 Figure(double radi.. 2020. 9. 30. [이펙티브자바 3판] ITEM22. 인터페이스는 타입을 정의하는 용도로만 사용하라 이번장의 핵심은... 인터페이스는 타입을 정의하는 용도로만 사용하자 상수 공개용 수단으로 사용하지 말자 타입 역할 인터페이스는 자신을 구현한 클래스의 인스턴스를 참조할 수 있는 타입 역할이다 자신의 인스턴스로 무엇을 할 수 있는지 클라이언트에 얘기해주는 것이다 인터페이스는 오직 이 용도로만 사용해야 한다 상수 인터페이스 메서드 없이, 상수를 뜻하는 static final 필드로만 가득 찬 인터페이스를 말한다 이 상수들을 사용하려는 클래스에서는 정규화된 이름을 쓰는 걸 피하고자 그 인터페이스를 구현한다 인터페이스를 잘못 사용한 예를 보자 (상수 인터페이스 안티 패턴) // 상수 인터페이스 안티패턴 - 사용금지! public interface PhysicalConstants { static final dou.. 2020. 9. 28. [이펙티브자바 3판] ITEM21. 인터페이스는 구현하는 쪽을 생각해 설계하라 이번장의 핵심은... 인터페이스를 설계할 때 세심한 주의를 기울여야 한다 디폴트 메서드 자바 8에 와서 기존 인터페이스에 메서드를 추가할 수 있도록 추가되었다 자바 8에서 람다를 활용하기 위해서 핵심 인터페이스들에 다수의 디폴트 메서드가 추가되었다 하지만 생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하기란 어렵다 Collection 인터페이스의 removeIf default boolean removeIf(Predicate 2020. 9. 27. [이펙티브자바 3판] ITEM20. 추상 클래스보다는 인터페이스를 우선하라 이번장의 핵심은... 일반적으로 다중 구현용 타입으로는 인터페이스가 가장 적합하다 복잡한 인터페이스라면 구현하는 수고를 덜어주는 골격 구현을 함께 제공하는 방법을 꼭 고려해보자 골격 구현은 '가능한 한' 인터페이스의 디폴트 메서드로 제공하여 그 인터페이스를 구현한 모든 곳에서 활용하도록 하는 것이 좋다 '가능한 한'의 이유는 인터페이스에 걸려 있는 구현상의 제약 때문에 골격 구현을 추상 클래스로 제공하는 경우가 더 흔하기 때문이다 추상 클래스가 정의한 타입을 구현하는 클래스는 반드시 추상 클래스의 하위 클래스가 되어야 한다 자바는 단일 상속만 지원하니, 추상 클래스 방식은 새로운 타입을 정의하는 데 커다란 제약을 가진다 반면, 인터페이스가 선언한 메서드를 모두 정의하고 그 일반 규약을 잘 지킨 클래스라면.. 2020. 9. 26. [이펙티브자바 3판] ITEM19. 상속을 고려해 설계하고 문서화하라. 그러지 않았으면 상속을 금지하라 이번장의 핵심은... 상속용 클래스를 설계하는 것은 굉장히 어렵다 클래스 내부에서 스스로를 어떻게 사용하는지 문서화해야 하며, 문서화한 것은 그 클래스가 쓰이는 한 반드시 지켜야 한다 다른 이가 효율 좋은 하위 클래스를 만들 수 있도록 일부 메서드를 protected로 제공해야 할 수 있다 그러나 명확한 이유가 없다면 상속을 금지하는 것이 좋을 수 있다 상속을 금지하기 위해서 클래스를 final로 선언하거나, 생성자 모두 private 또는 package-private로 선언해 외부 접근을 제한해라 문서화 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 한다 클래스 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수도 있다 호출되는 메서드가 재정의.. 2020. 9. 23. 이전 1 ··· 3 4 5 6 7 8 9 다음 반응형
