- 자바빈
자바빈(JavaBean)은 원래 비주얼 툴에서 조작 가능한 컴포넌트를 말한다. 자바의 주력 개발 플랫폼이 웹 기반의 엔터프라이즈 방식으로 바뀌면서 비주얼 컴포넌트로서 자바빈은 인기를 잃어갔다. 자바빈의 몇가지 코딩 관례는 JSP 빈, EJB와 같은 표준 기술과 자바빈 스타일의 오브젝트를 사용하는 오픈소스 기술을 통해 이어져 왔다.
자바빈은 두 가지 관례를 따라 만들어진 오브젝트를 가리킨다. 간단히 빈이라고 부르기도 한다.
디폴트 생성자 : 자바빈은 파라미터가 없는 디폴트 생성자를 갖고 있어야 한다. 툴이나 프레임워크에서 리플렉션을 이용해 오브젝트를 생성하기 때문이다.
프로퍼티 : 자바빈이 노출하는 이름을 가진 속성을 프로퍼티라고 한다. 프로퍼티는 set으로 시작하는 수정자 메소드(setter)와 get으로 시작하는 접근자 메소드(getter) 를 이용해 수정 또는 조회할 수 있다.
만들어진 코드의 기능을 검증하고자 할 때에는 사용할 수 있는 가장 간단한 방법인 오브젝트 스스로 자신을 검증하도록 만들어 주는 것이다.
분리
- 관심사 분리 (Separation Of Concerns)
관심이 같은 것끼리는 하나의 객체 안으로 모이게 하고 관심이 다른 것은 가능한 한 따로 떨어져서 서로 영향을 주지 않도록 분리하는 것
(1) 관심사항 확인
(2) 중복코드 메소드 추출
(3) 변경사항에 대한 검증 : 리팩토링 테스트
(4) 상속을 통한 확장
- 슈퍼클래스에 기본적인 로직의 흐름을 만들고, 그 기능의 일부를 추상 메소드나 오버라이딩이 가능한 proteceted 메소드 등으로 만든 뒤 서브클래스에서 이런 메소드를 필요에 맞게 구현해서 사용하도록 하는 방법을 템플릿 메소드 패턴이라고 부름
상위클래스는 메소드의 선언만 하고 실질적 메소드의 구현은 하위클래스에서 담당한다. 또한 하위클래스에서 구체적인 오브젝트 생성 방법을 결정하게 하는 것을 팩토리 메소드 패턴이라고 부른다.
- 템플릿 메소드 패턴
상속을 통해 슈퍼클래스의 기능을 확장할 때 사용하는 가장 대표적인 방법. 변하지 않는 기능은 슈퍼클래스에 만들어두고, 자주 변경되며 확장할 기능은 서브클래스에서 만들도록 한다. 슈퍼클래스에서는 미리 추상 메소드 또는 오버라이드 가능한 메소드를 정의해두고 이를 활용해 코드의 기본 알고리즘을 담고 있는 템플릿 메소드를 만든다.
서브클래스에서는 추상 메소드를 구현하거나, 오버라이드에 할 수 있는 메소드를 오버라이딩하여 기능의 일부를 확장한다.
- 팩토리 메소드 패턴
상속을 통해 기능을 확장하게 하는 패턴이다. 슈퍼클래스 코드에서는 서브클래스에서 구현할 메소드를 호출해서 필요한 타입의 오브젝트를 가져와 사용한다. 이 메소드는 주로 인터페이스 타입으로 오브젝트(Object)를 리턴하므로 서브클래스에서 정확히 어떤 클래스의 오브젝트를 만들어 리턴할지는 슈퍼클래스에서는 알지 못한다.
서브클래스는 다양한 방법으로 오브젝트를 생성하는 메소드를 재정의할 수 있다. 이렇게 서브클래스에서 오브젝트 생성 방법과 클래스를 결정할 수 있도록 미리 정의해둔 메소드를 팩토리 메소드라고 한다. 그리고 이 방식을 통해서 오브젝트 생성 방법을 나머지 로직, 즉 슈퍼 클래스의 기본 코드에서 독립시키는 방법을 팩토리 메소드 패턴이라고 한다.
자바에서는 종종 오브젝트를 생성하는 기능을 가진 메소드를 팩토리 메소드라고 부르기도 한다. 따라서 팩토리 메소드 vs 팩토리 메소드 패턴의 팩토리 메소드와는 구별된다.
확장
추상클래스를 만들고 이를 상속한 서브클래스에서 변화가 필요한 부분을 바꿔서 쓸 수 있게 만든 이유는 바로 이렇게 변화의 성격이 다른 것을 분리해서, 서로 영향을 주지 않은 채로 각각 필요한 시점에 독립적으로 변경할 수 있게 하기 위해서이다.
하지만 추상클래스를 이용시 어느 정보를 가지고 오기 위한 클래스에 대해 너무 많이 알고 있기 때문에 문제가 발생한다. 클래스에 대해 요구하는 정보가 많다는 의미이다.
결과적으로 다중상속을 지원하지 않기 때문에 추상클래스 내부에서 지니고 있는 정보들이 범용적이다.
인터페이스 도입
추상화 작업은 어떤 것들의 공통적인 성격을 뽑아내어 이를 따로 분리해내는 작업이다. 인터페이스는 어떤 일을 하겠다는 기능만 정의해놓은 것이다. 따라서 인터페이스에는 어떻게 구현하겠다는 방법은 나타나 있지 않다.
관계설정 책임의 분리
A 클래스와 A 클래스가 사용할 B의 특정 구현 클래스 사이의 관계를 설정해주어야 한다. 이러한 관심사를 담은 코드를 분리하지 않으면 결코 독립적으로 확장 가능한 클래스가 될 수 없다.
오브젝트 사이의 관계는 런타임 시에 한쪽이 다른 오브젝트의 레퍼런스를 갖고 있는 방식으로 만들어진다. 결국 두 개의 오브젝트가 "사용" 이라는 관계를 맺게 된다.
외부에서 만든 오브젝트를 전달받으려면 메소드 파라미터나 생성자 파라미터를 이용하면 된다. 단지 해당 인터페이스 타입의 오브젝트라면 파라미터로 전달 가능하고, 파라미터로 제공받은 오브젝트는 인터페이스에 정의된 메소드만을 이용한다면 그 오브젝트는 인터페이스에 정의된 메소드만 이용한다면 그 오브젝트가 어떤 클래스로부터 만들어졌는지 신경쓰지 않아도 된다.
원칙과 패턴
- 개방 폐쇄 원칙(OCP : Open - Closed Priciple)
개방 폐쇄 원칙은 깔끔한 설계를 위해 적용 가능한 객체지향 설계 원칙 중의 하나이다. 이 원칙을 간단히 정의하면 클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 함을 말한다.
'Spring > 토비의 스프링' 카테고리의 다른 글
20180417 토비의 스프링 5장 : 서비스 추상화 (0) | 2018.04.17 |
---|---|
20180412 토비의 스프링 4장 : 예외 (0) | 2018.04.12 |
20180404 토비의 스프링 3장 : 템플릿 (0) | 2018.04.04 |
20180328 토비의 스프링 2장 : 테스트 (0) | 2018.03.28 |
20180320 토비의 스프링 1장 : 오브젝트와 의존관계 02 (0) | 2018.03.20 |