개요 코드를 재사용하기 위한 일반적인 방법은 상속을 이용한 방법이 있습니다. 하지만 상속을 이용한 방법은 최선의 선택이 아니고 잘못 사용하면 오류가 발생하기 쉽습니다. 이 글에서는 어떻게 상속이 캡슐화를 망가뜨릴 수 있는지 알아보고, 상속을 잘못되게 설계한 예제를 소개합니다. 그리고 상속을 사용하여 코드를 재사용하는대신 컴포지션을 사용하여 코드를 재사용하는 방법에 대해서 소개합니다. 마지막으로 상속을 사용시 주의할 점에 대해서 알아봅니다. 1. 상속이 캡슐화를 망가뜨릴 가능성이 높은 이유는 무엇인가? 메서드 호출과는 달리 상속의 사용은 캡슐화를 망가뜨릴 가능성이 높아지게 됩니다. 상위 클래스가 어떻게 구현하느냐에 따라 하위 클래스의 동작에 이상이 발생시키거나 하위 클래스의 멤버를 노출시킬 수 있습니다. ..

1. 불변 클래스(Immutable Class)란 무엇인가? 불변 클래스란 인스턴스의 내부 값을 수정할 수 없는 클래스입니다. 대표적인 불변 클래스로 String, Integer와 같은 기본 타입의 박싱된 클래스들, BigInteger, BigDecimal과 같은 클래스가 불변 클래스에 해당됩니다. 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 발생할 여지도 적고 훨씬 안전한 클래스입니다. 2. 클래스를 불변으로 만들기 위한 5가지 규칙 클래스를 불변 클래스로 만들려면 다음 다섯 가지 규칙을 따르면 됩니다. 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않습니다 대표적인 예가 Setter 메서드가 존재합니다 클래스를 확장할 수 없도록 합니다 하위 클래스에서 객체의 상태를 변..

1. ResourceLoaderAware 인터페이스는 무엇인가? ResourceLoaderAware 인터페이스는 ResourceLoader 참조가 될 컴포넌트를 식별하는 콜백(callback) 인터페이스입니다. 다음은 ResourceLoaderAware 인터페이스의 정의입니다. public interface ResourceLoaderAware { void setResourceLoader(ResourceLoader resourceLoader); } 한 클래스가 ResourceLoaderAware 인터페이스를 구현하고 ApplicationContext에 배포되면 ApplicationContext에서 ResourceLoaderAware로써 인식됩니다. 그런 다음 ApplicationContext는 setRes..

1. ResourcePatternResolver 인터페이스는 무엇인가? ResourcePatternResolver 인터페이스는 ResourceLoader 인터페이스를 상속받은 확장판 인터페이스입니다. ResourcePatternResolver 인터페이스의 getResources 메서드는 매개변수로 문자열 타입의 위치 패턴(locationPattern)을 입력받아 해당 패턴에 만족하는 자원들을 가져오는 기능입니다. ApplicationContext 인터페이스는 ResourcePatternResolver 인터페이스를 상속받기 때문에 getResources 메서드를 호출하여 여러 자원들을 가져올 수 있습니다. ResourcePatternResolver 인터페이스 정의 public interface Resour..

1. ResourceLoader 인터페이스 ResourceLoader 인터페이스는 Resource 인스턴스를 불러올 수 있는 객체에 의해 구현됩니다. 다음은 ResourceLoader 인터페이스의 정의입니다. public interface ResourceLoader { Resource getResource(String location); ClassLoader getClassLoader(); } 모든 ApplicationContext 인터페이스들은 ResourceLoader 인터페이스를 구현하기 때문에 모든 ApplicationContext는 Resource 인스턴스를 얻기 위해 사용할 수 있습니다. 특정 ApplicationContext에서 특정한 접두어를 가지지 않는 위치 경로를 가지고 getResou..

1. 적절하지 않는 public 클래스 class Point{ public double x; public double y; } 위와 같은 Point 클래스의 x,y 데이터 필드는 접근이 가능하기 때문에 다음과 같은 문제점이 있습니다. 데이터 필드에 직접 접근이 가능하기 때문에 캡슐화의 이점을 갖지 못합니다 외부에 클래스의 멤버를 노출시키지 않을 수 있습니다 API를 수정하지 않고는 내부 표현을 바꿀 수 없습니다 예를 들어 Point 인스턴스의 필드 x를 직접 접근하는 클라이언트가 있다면 Point 클래스의 필드 x를 함부로 바꾸기가 어렵습니다. 필드 x를 변경한다면 그것을 참조하는 클라이언트도 변경되어야 합니다. 불변식을 보장할 수 없으며, 외부에서 필드에 접근할 때 부수 작업을 수행할 수 없습니다 불변..