자바 썸네일형 리스트형 Effective Java ( 이펙티브 자바 ) - 아이템 23 태그 달린 클래스보다는 클래스 계층구조를 활용하라 두 가지 이상의 의미를 표현할 수 있으며, 그중 현재 표현하는 의미를 태그 값으로 알려주는 클래스를 본 적이 있을 것이다. 다음 코드는 원과 사각형을 표현할 수 있는 클래스다. class Figure { enum Shape { RECTANGLE, CIRCLE }; // 태그 필드 - 현재 모양을 나타낸다. final Shape shape; // 다음 필드들은 모양이 사각형(RECTANGLE)일 때만 쓰인다. double length; double width; // 다음 필드는 모양이 원일때만 쓰인다. double radius; // 원용 생성자 Figure(dobule radius) { shape = Shape.CIRCLE; this.radius = ra.. 더보기 Effective Java ( 이펙티브 자바 ) - 아이템 22 인터페이스는 타입을 정의하는 용도로만 사용하라 인터페이스는 자신을 구현한 클래스의 인스턴스를 참조할 수 있는 타입 역할을 한다. 달리 말해, 클래스가 어떤 인터페이스를 구현한다는 것은 자신의 인스턴스로 무엇을 할 수 있는지를 클라이언트에 얘기해주는 것이다. 인터페이스는 오직 이 용도로만 사용해야 한다. 이 지침에 맞지 않는 예로 소위 상수 인터페이스라는 것이 있다. 메서드 없이, 상수를 뜻하는 static final 필드로만 가득 찬 인터페이스를 말한다. 그리고 이 상수들을 사용하려는 클래스에서는 정규화된 이름(qualified name)을 쓰는 걸 피하고자 그 인터페이스를 구현하곤 한다. public interface PhysicalConstants { // 아보가드로 수 (1/몰) static fin.. 더보기 Effective Java ( 이펙티브 자바 ) - 아이템 15 클래스와 멤버의 접근 권한을 최소화하라 어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐다. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다. 정보 은닉, 캡슐화라고 한다. 장점은 정말 많다. 대부분은 시스템을 구성하는 컴포넌트들을 서로 독립시켜서 개발, 테스트, 최적화, 적용, 분석, 수정을 개발적으로 할 수 있게 해주는 것과 연관되어 있다. 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다. 시스템 관리 비용을 낮춘다. 더 빨리 파악하여 디버깅 .. 더보기 Effective Java ( 이펙티브 자바 ) - 아이템 12 toString을 항상 재정의하라 Object의 기본 toString 메서드가 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우는 거의 없다. PhoneNuber@adbbd 처럼 단순히 클래스_이름@16진수로_표시한_해시코드 를 반환할 뿐이다. toString 일반 규약에 따르면 '간결하면서 사람이 읽기 쉬운 형태의 유익한 정보' 를 반환해야 한다. 또한 toString의 규약은 "모든 하위 클래스에서 이 메서드를 재정의하라"고 한다. 정말 새겨들어야 할 조언이다! equals, hashCode 규약만큼 대단히 중요하진 않지만, toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 디버깅하기 쉽다. toString 메서드는 객체를 println, printf, 문자열 연결 +, assert .. 더보기 Effective Java ( 이펙티브 자바 ) - 아이템 10 ( equals는 일반 규약을 지켜 재정의하라 ) equals는 일반 규약을 지켜 재정의하라 equals 메서드는 재정의하기 쉬워 보이지만 곳곳에 함정이 도사리고 있어서 자칫하면 끔찍한 결과를 초래한다. 문제를 회피하는 가장 쉬운 길은 아예 재정의하지 않는 것이다. 그냥 두면 그 클래스의 인스턴스는 오직 자기 자신과만 같게 된다. 그러니 다음에서 열거한 상황 중 하나에 해당한다면 재정의하지 않는 것이 최선이다. 각 인스턴스가 본질적으로 고유하다. 값을 표현하는게 아니라 동작하는 개체를 표현하는 클래스가 여기 해당한다. Thread가 좋은 예로, Object의 equals 메서드는 이러한 클래스에 딱 맞게 구현되었다. 인스턴스의 '논리적 동치성(logical equality)을 검사할 일이 없다. 예컨대 java.util.regex.Pattern은 equ.. 더보기 Effective Java (이펙티브 자바)2장 - 객체 생성과 파괴 이 장은 객체의 생성과 파괴를 다룬다. 객체를 만들어야 할 때와 만들지 말아야 할 때를 구분하는 법, 올바른 객체 생성 방법과 불필요한 생성을 피하는 방법, 제때 파괴됨을 보장하고 파괴 전에 수행해야 할 정리 작업을 관리하는 요령을 알아본다. 아이템 1 - 생성자 대신 정적 팩터리 메서드를 고려하라 클라이언트가 클래스의 인스턴스를 얻는 전통적인 수단은 public 생성자다. 하지만 모든 프로그래머가 꼭 알아둬야 할 기법이 하나 더 있다. 클래스는 생성자와 별도로 정적 팩터리 메서드를 제공할 수 있다. 이 방식에는 장점과 단점이 모두 존재한다. 먼저 장점 다섯 가지를 알아보자. 첫 번째, 이름을 가질 수 있다. 생성자에 넘기는 매개변수와 생성자 자체만으로는 반환될 객체의 특성을 제대로 설명하지 못한다. 하.. 더보기 클린 코드 7장 - 오류 처리 오류 처리는 프로그램에 반드시 필요한 요소 중 하나일 뿐이다. 뭔가 잘못될 가능성은 늘 존재한다. 뭔가 잘못되면 바로 잡을 책임은 바로 우리 프로그래머에게 있다. 오류 처리는 중요하다. 하지만 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. 우아하고 고상하게 오류를 처리하는 기법과 고려 사항 몇 가지를 소개한다. 오류 코드보다 예외를 사용하라 예외를 지원하지 않는 언어는 오류를 처리하고 보고하는 방법이 제한적이었다. 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법이 전부였다. 이러한 방법은 호출자 코드가 복잡해진다. 함수를 호출한 즉시 오류를 확인해야 하기 때문이다. 잊어버리기 쉽다. 그래서 오류가 발생하면 예외를 던지는 편이 낫다. 개념(로직)과.. 더보기 이전 1 2 3 4 5 다음