프로그래밍/Java

이펙티브 자바 규칙 16 - 계승하는 대신 구성하라

자바를 하는 사람은 상속(계승)을 모를 수가 없죠. 코드의 재사용을 돕는 강력한 도구입니다. 하지만 상속을 적절하게 사용하지 못한 소프트웨어는 깨지기 쉬운데요. 그래서 상속에는 그에 걸맞는 문서가 있는 것이 안전합니다. 이펙티브 자바에서는 먼저 상속의 단점을 나열하고 있습니다. 먼저 메소드와 달리 상속은 캡슐화 원칙을 위반합니다. 상위 클래스를 상속한 하위클래스는 상위클래스에 의존적입니다. 상위 클래스가 수정되면, 하위 클래스의 코드도 필연적으로 수정되어야 하죠. 캡슐화의 조건을 깨뜨리고 있습니다. 예제 코드로 한번 살펴봅시다. package dao; import java.util.Collection; import java.util.HashSet; public class InstrumentedHashSe..

이펙티브 자바 규칙 15 - 변경 가능성을 최소화하라

자바의 클래스는 변경가능한 클래스와 변경 불가능한 클래스로 나눌 수 있습니다. final 선언자가 큰 역할을 하죠. EFJ15에서는 이 변경 불가능한(immutable) 클래스의 이점에 대해 설명하면서, 특별한 이유가 없을 때에는 되도록 변경이 불가능 하도록 설정하라고 권하고 있습니다. 먼저 변경 불가능한 클래스를 만들 때 지켜야할 5규칙입니다. 1. 객체 상태를 변경하는 메소드(Setter 등)를 제공하지 않는다. 2. 계승할 수 없도록 한다.(상속 불가)하위 클래스로 인해 변경될 가능성을 차단합니다. 3. 모든 필드를 final로 선언한다.시스템상으로 강제해 의도를 분명히 합니다. 4. 모든 필드를 private로 선언한다.클라이언트가 객체를 직접 수정하는 일을 막습니다. 5. 변경 컴포넌트에 대한 ..

디자인 패턴 - 프록시 패턴(Proxy pattern)

프록시는 클라이언트나 대상 사이의 대리 또는 접근 방법의 제어를 말하는 오브젝트를 일컫을 때 사용하는 단어입니다. 디자인 패턴 중 프록시 패턴이 있습니다. 디자인 패턴의 프록시는 타켓의 기능을 추가하지 않습니다. Spring을 다루어 보신 분이라면 AOP, intercepter, filter 등을 사용해보셨을 텐데요. 이 기능들의 공통점은 오브젝트에 접근할 때 먼저 처리해야할 점 또는 나중에 처리해야할 점의 설정을 도와준다는 점이죠,타켓에 접근하는 방식을 변경해주는 역할을 합니다. 프록시 패턴이 이와 비슷합니다. 프록시 패턴을 이해하기 위해서는 먼저 리플렉션에 대한 이해가 필요합니다. 리플렉션이란, 오브젝트에 대한 구체적인 클래스 정보 없이도 그 오브젝트가 가진 변수, 메소드 등에 접근할 수 있게 하는 ..

디자인 패턴 - 데코레이터 패턴(Decorator Pattern)

데코레이터 패턴은 목표 객체의 부가적인 속성을 동적으로 표현해주기 위해 사용하는 디자인 패턴입니다. 동적으로 연결된다는 의미는 기능을 부가할 때, 어떤 방법과 순서에 따라서 연결되지 않는다는 것을 의미합니다. 자동차를 만들 때를 한번 생각해보죠. 자동차가 있으면, 네비게이션 달고, 스킨 튜닝하고, 썬루프 달고 하는 걸 순서대로 하지는 않겠죠? 사용자의 요구에 맞추어서 해주겠죠. 코드를 한번 봅시다. public interface Car { public void assemble(); }public class BasicCar implements Car { @Override public void assemble() { System.out.print("Basic Car."); } }public class Car..

이펙티브 자바 규칙 13 - 클래스와 멤버의 접근 권한은 최소화하라

객체 지향의 모듈에서 중요한 특성을 뽑으라면 정보 은닉과 캡슐화가 있을 것입니다. 정보은닉은 모듈사이의 의존성을 낮추어 주어서 개별적으로 개발, 시험, 최적화한다는 특성에 목적을 두고 있습니다. 정보은닉과 캡슐화가 이루어진 모듈은 병렬적으로 개발할 수 있기 때문에 시스템 개발 속도가 올라가고다른 모듈에 영향을 끼칠 걱정 없이 디버깅이 가능합니다. 이 외에도 유지보수의 용이성, 소프트웨어의 재사용 용이 등 여러가지 장점을 누리기 위해 정보은닉을 할 필요가 있습니다. 정보은닉의 핵심적인 원칙은 각 클래스와 멤버는 가능한 한 접근이 불가능 하도록 만들어야 한다는 점입니다. 자바는 네개의 접근 권한을 제공합니다. private 클래스 내부에서만 접근이 가능합니다. package-private 같은 패키지 내에서..

자바 Exception 예외 (throwable, Error, Exception, RuntimeException)

자바의 예외에는 위와 같은 종류로 나누어집니다 크게 Error와 Exception으로 나뉩니다. Error 에러는 시스템에 문제가 생겼을 때 발생합니다. 이는 프로그래머나 사용자가 수정할 수 없는 성격으로서 예로는 OutOfMemoryError, StackOverflowError 등이 있습니다. 이런 에러는 코드로 잡을 수 없는 상황이 많습니다. Exception 익셉션 클래스는 다시 RuntimeException(uncheck 예외)을 상속하는 Exception들과 그 외의 Exception(check 예외)으로 나뉩니다. 자바를 다루다 보면 자주 사용하는 코드들이 파일 인풋 아웃풋, DB 관련 코드일 텐데 이 부분을 구현하다보면 try, catch 로 묶거나 throw를 사용하여 에러를 던지는 경우를..

이펙티브 자바 규칙 12 - Comparable 구현을 고려하라

Comparable은 Comparable 인터페이스에 포함된 유일한 메소드입니다. Object의 equals 메소드와 특성은 비슷하지만, 단순한 동치성 검사 이외에 순서 비교가 가능하며 좀 더 일반적입니다. 먼저 CompareTo의 규약을 살펴봅시다. 본 메소드는 이 객체와 인자로 주어진 객체를 비교한다. 이 객체의 값이 인자로 주어진 객체보다 작으면 음수를, 같으면 0을, 크면 양수를 반환한다. 인자로 전달된 객체의 자료형이 이 객체와 비교 불가능한 자료형인 경우에는 ClassCast Exception 예외를 던진다.아래의 명세에 등장하는 sgn(expression)은 수학에서의 signum 함수를 나타내는 것으로 -1, 0, 1 가운데 한 값을 반환한다. 어떤 값이 반환될지는 expression의 값..

이펙티브 자바 규칙 10 - toString은 항상 재정의하자

Java를 다루어 본 분들이라면 잘 알다시피 toString은 객체를 println printf, 문자열 연결 연산자, assert, 디버거 등의 메소드가 호출했을 때 객체의 정보를 표현하기 위해 자동으로 호출되는 메소드 입니다. 재정의 하지 않는다면 객체를 문자열 관련 메소드로 호출했을 때 PhoneNumber@163b91 과 같이 ' 클래스 이름 + @ + 16진수로 표현된 해시코드 '로 구성된 문자열이 리턴됩니다. 이 toString은 객체를 손쉽게 표현하기 위해 재정의해주는 게 좋습니다. toString의 일반규약에는 이런 구절도 있습니다. "모든 하위 클래스는 이 메소드를 재정의함이 바람직하다." 이펙티브 자바에서는 이 toString을 재정의 할 때 신경써야할 점을 꼽고 있습니다. 1. toS..

디자인 패턴 - 전략 패턴(Strategy pattern) 예시 / 예제

전략 패턴이란 인터페이스를 두고 클래스와 클래스를 느슨하게 연결하여 재사용할 수 있는 코드를 극대화하는 다지안 패턴 중 하나입니다. 자바, C++ 등에서 활용됩니다. 일단 예제코드를 한번 보죠. 나름 모형도 한번 만들어 봤습니다. import java.io.File; import java.util.ArrayList; public class Client { public static void main(String[] args) { CompressionContext ctx = new CompressionContext(); //we could assume context is already set by preferences ctx.setCompressionStrategy(new ZipCompressionStrat..

이펙티브 자바 규칙 9 - equal 메소드를 재정의 할 때 hashCode()도 재정의 하자

Object 클래스의 명세를 보면 hashCode의 일반 규약은 아래와 같습니다. 어플리케이션 실행 중 같은 객체의 hashCode를 여러 번 호출하는 경우, equals가 사용하는 정보들이 변경되지 않았다면, 언제나 동일한 정수가 반환되어야한다. 다만 프로그램이 종료되었다가 다시 실행되어도 같은 값이 나올 필요는 없다.equals(Object) 메소드가 같다고 판정한 두 객체의 hashCode 값은 같아야 한다.equals(Object) 메소드가 다르다고 판정한 두 객체의 hashCode 값은 꼭 다를 필요는 없다. 그러나 서로 다른 hashCode 값이 나오면 해시 테이블의 성능이 향상될 수 있다는 점은 이해하고 있어야 한다. 저번 포스트에서 equals 메소드를 재수정 했습니다. 내부의 중요 필드를..