만약 해당 비즈니스에서 정보의 삽입, 수정이 일어날 때마다 즉시 사용자에게 정보를 보여줘야 한다면,
그때마다 Entity를 반환하는 것이 좋을 수도 있습니다.
코드로 예시를 들어보겠습니다.
// Create가 id만 반환하는 경우
class OrderService {
...
public Order createOrder(int price) {
long id = this.orderDao.create(price);
OrderEntity = this.orderDao.findById(id);
... // Order 생성
return order;
}
public Order createFreeOrder() {
long id = this.orderDao.create(0);
OrderEntity = this.orderDao.findById(id);
... // Order 생성
return order;
}
}
위처럼 Service에서 DAO의 Create, Update를 호출하는 메서드의 대부분이 Entity를 필요로 한다면,
굳이 DAO의 메서드를 2번 호출하기보다 create() 메서드가 OrderEntity를 반환하는 것이 나을 수 있습니다.
// Create가 Entity를 반환하는 경우
class OrderService {
...
public Order createOrder(int price) {
OrderEntity = this.orderDao.create(price);
... // Order 생성
return order;
}
public Order createFreeOrder() {
OrderEntity = this.orderDao.create(0);
... // Order 생성
return order;
}
}
(보수 받는 개발자 경력이 없는지라, 가정이 많이 부족할 수 있습니다.)
그런데 CREATE 또는 UPDATE한 정보를 다시 반환하는 것이, 비용이 많이 드는 일일 수도 있습니다.
아래에 의사코드로 예시를 들겠습니다.
class OrderDao {
...
public List<OrderEntity> updateIfPriceOverThousand(Data data) {
database.update("UPDATE order SET price data = data WHERE price > 1000");
List<OrderEntity> orderEntities = database.query("SELECT * FROM order WHERE price > 1000");
return orderEntities;
}
}
위의 코드에서는, DAO에서 Update 후 Entity의 List를 반환합니다.
그런데, price가 1,000 이상인 데이터가 수백만 건이라면,
게다가 해당 정보가 반드시 필요한 것이 아니라면,
필요하지 않은 경우 SELECT를 실행하지 않는 것만으로 서버 리소스가 크게 감소할 수 있을 것입니다.
서버에서는 요청에 대한 반환만 전달하고, 클라이언트가 화면을 렌더링하는 CSR(Client-Side Rendering) 방식에서는, Controller가 기능(또는 도메인) 기준으로 분리되는 것이 일반적입니다.
그런데 서버에서 요청에 대한 수행 뿐만 아니라, 데이터를 렌더링한 화면을 반환하는 SSR(Server-Side Rendering) 방식에서, Controller는 어떻게 분리되어야 할지 고민이 되었습니다.
화면 단위로 구분해야 하는 것이 맞을지, 기능(또는 도메인 / 이하 도메인)단위로 구분해야 하는 것이 맞을지, 고민의 대한 개인적인 결론을 공유드려봅니다.
먼저, 각각의 방식에 대한 예시와 특징을 살펴보고, 마지막으로 각각을 비교하면서 나름의 결론을 내려보겠습니다.
화면 단위로 구분하는 예시
현재 웹 사이트가 domain.com/ 과 domain.com/admin의 2가지 화면을 가지고 있다고 가정하겠습니다. 아래는 Spring 프레임워크로 구현된 Controller의 의사코드입니다.
// domain.com/ 에서 사용되는 기능을 모아둔 Controller
@Controller
public class HomeController {
@GetMapping
public String productList(final Model model) {
List<Product> products = productDao.findAll();
model.addAttribute("products", products);
return "index";
}
}
// domain.com/admin 에서 사용되는 기능을 모아둔 Controller
@RequestMapping("/admin")
@Controller
public class AdminController {
@PostMapping("/products")
public void saveProduct(@RequestBody Request request) {
// (프로덕트 저장 로직)
// 이후 Javascript 파일에서 이전 뷰를 reload함
}
@GetMapping
public String getAllProducts(final Model model) {
List<Product> products = productService.findAll();
model.addAttribute("products", products); // 상품 정보 렌더링 로직
return "admin";
}
...
}
화면에 필요한 기능들이 모아져 있습니다.
도메인 단위로 구분하는 예시
// Product 관련 기능을 모아둔 Controller
@RequestMapping("/products")
@Controller
public class ProductController {
@PostMapping
public void saveProduct(@RequestBody Request request) {
// (프로덕트 저장 로직)
// 이후 Javascript 파일에서 이전 뷰를 reload함
}
...
}
이 경우, 아래와 같이 뷰를 반환하는 Controller가 별도로 존재해야 합니다. (아니면 기능 단위로 뷰를 분리할 수도 있겠으나 개인적으로는 구조가 직관적이지 않다고 생각합니다.)
// View를 반환하는 Controller
@Controller
public class ViewController {
@GetMapping
public String getHomeView() {
// (렌더링 로직)
return "index";
}
@GetMapping("/admin")
public void getAdminView() {
// (렌더링 로직)
return "admin";
}
}
두 가지 방식 비교
Controller의 구조가 화면에 의존하느냐, 도메인에 의존하느냐, 두 가지 관점에서 고려해보겠습니다.
1. 화면과 도메인 중 어느 것이 자주 바뀔까
일반적으로는 화면이 더 자주 바뀔 것입니다. 사용자에게 보여지고, 사용자와 직접 Interaction하는 화면은 사용자의 편의를 직접적으로 고려하고 반영해야 할 일이 많을 것입니다.
하지만 도메인의 변경은 자주 일어나서는 안 되는 일입니다. OCP(Open-Close Principle / 개방-폐쇄 원칙)에 의하면, 객체지향적 설계를 위해 도메인 구조는 변경에는 닫혀 있고, 확장에만 열려 있어야 합니다.
따라서 구조의 변경이 자주 일어날 것으로 예상되는 화면보다는, 도메인을 기준으로 Controller 구조를 설계하는 것이 맞다고 생각합니다. 변경 가능성이 적어 안정적인 구조를 위해서 그렇습니다.
2. Controller는 Service에 의존한다.
Service는 아마 기능 단위로 분리되어 있을 것입니다. (도메인 주도 개발의 관점에서 유즈케이스를 고려할 수 있으나, 이 또한 기능 중심의 분리입니다.) 만약 Controller가 화면의 구조에 맞게 설계된다면, 의존하는 Service가 많아질 수 있습니다.
예를 들면, ProductService, UserService, OrderService가 존재할 때, 도메인 기준으로 설계된 ProductController는 ProductService에만 의존하겠지만, (물론 의존성이 추가될 수 있습니다.) 화면 기준으로 설계된 AdminController는 ProductService, UserService, OrderService를 모두 의존할 수 있습니다. Admin 화면에서 상품, 유저, 주문 정보에 모두 접근할 수 있기 때문입니다. 따라서 도메인 기준으로 설계된 Controller의 의존 관계가 화면 기준으로 설계된 Controller보다 간결할 가능성이 높습니다.
위의 두 가지 이유를 종합하여, 화면 기준이 아닌 도메인(기능) 기준으로 Controller를 설계해야 한다고 결론을 내렸습니다.
물론 정답이 있는 문제는 아니라고 생각합니다. (진리) 사용자가 접근할 URL이 너무나도 중요해서 절대 확장하지 않고 2가지 링크에 대응되는 화면만 사용한다면, 화면이 도메인보다 안정적인 구조일 수도 있습니다. 설계에 따라서는 도메인 중심으로 나눈 Controller도 Service에 대해 복잡한 의존 관계를 지닐 수 있습니다.
그렇기에 무작정 설계를 하기 보다는, 지금의 설계가 추후의 비즈니스적 문제에 어떤 영향을 미칠 것인지를 고민하는 것이 중요하다고 생각합니다.
@Transactional 애너테이션은 메서드(혹은 클래스, 인터페이스 등)를 트랜잭션 단위로 만듭니다.
여기서 트랜잭션이란, 데이터베이스에서 수행하는 작업의 단위로, 아래와 같은 4가지 특성을 가집니다.
원자성 : 하나의 작업 단위이다. (모두 수행되던가, 전혀 수행되지 않던가)
일관성 : 작업 처리 결과에 일관성이 있다. (트랜잭션 진행되는 동안에 발생하는 DB 변경은 무시한다.)
독립성 : 둘 이상의 트랜잭션이 동시에 실행될 때, 다른 트랜잭션의 연산에 끼어들지 않는다.
지속성 : 트랜잭션이 성공적으로 완료되면, 결과는 영구적으로 반영되어야 한다.
본 아티클에서는 간단하게 원자성을 기준으로 @Transactional 애너테이션을 사용해보겠습니다.
그리고 @Transactional의 적용 범위(하위 메서드, 상위 메서드)에 대해, Spring 내부의 동작 원리를 통해 간단하게 알아보겠습니다.
트랜잭션이 아닌 경우
아래의 간단한 예시 코드를 먼저 이해해야 합니다.
(Java의 문법과 Spring의 라이브러리, 그리고 약간의 의사코드를 포함하여 작성되었습니다.)
// Dao를 사용하는 Service
public class Service {
privata final Dao dao;
public saveResult(int userId) {
this.dao.saveNameById("name", userId);
this.dao.saveAgeById(40, userId);
}
}
// Service가 사용하는 Dao
public class Dao {
public void saveNameById(String name, int userId) {
// DB에서 id가 userId인 user에 입력 받은 name을 저장하는 의사코드
this.database.executeQuery("UPDATE user SET name = ? WHERE id = ?", name);
}
public void saveAgeById(int age, int userId) {
// DB에서 id가 userId인 user에 입력 받은 age를 저장하는 의사코드
this.database.executeQuery("UPDATE user SET age = ? WHERE id = ?", age);
}
}
Service의 saveResult()는 Dao의 saveNameById()과 saveAgeById()라는 2개의 메서드를 호출합니다.
그를 통해 2개의 SQL문이 실행되고, DB에는 2번의 변경이 일어납니다.
이때, 아래와 같이 age를 저장하던 도중 예외가 발생한다고 가정하겠습니다.
public void saveAge(int age) {
throw new RuntimeException("저장 실패");
this.database.executeQuery("UPDATE user SET age = ? WHERE id = 1", age) // 입력 받은 age를 DB에 저장ㅇ하는 의사코드
}
이런 상황에서 Service의 save() 메서드가 호출된다면,
DB에서 해당 user의 name까지만 저장되고, age는 저장되지 않을 것입니다.
예외가 발생한다면 대개의 경우,
name만 저장되는 상황보다는 name과 age가 모두 저장되지 않는 상황이 바람직할 것입니다.
@Transactional 애너테이션으로 그것을 구현해보겠습니다.
트랜잭션을 사용하는 경우
public class Service {
privata final Dao dao;
@Transactional
public saveResult(int userId) {
this.dao.saveNameById("name", userId);
this.dao.saveAgeById(40, userId);
}
}
하나의 단위로 묶이기 원하는 메서드나 @Transactional 애너테이션을 붙입니다.
그럼 해당 메서드가 호출되어 수행이 완료되기 까지 발생하는 DB와의 모든 상호작용이 하나의 단위가 됩니다.
위에서 작성한 코드의 예를 들면, name와 age를 저장하는 작업이 하나로 묶여서,
모두 성공하면 반영(commit)되고, 하나라도 실패하거나 중간에 문제가 발생하면 회수(rollback)됩니다.
name과 age를 저장하는 Dao의 메서드 각각을 트랜잭션 단위로 만들고 싶다면,
아래와 같이 사용할 수 있습니다.
public class Dao {
@Transactional
public void saveNameById(String name, int userId) {
// DB에서 id가 userId인 user에 입력 받은 name을 저장하는 의사코드
this.database.executeQuery("UPDATE user SET name = ? WHERE id = ?", name);
}
@Transactional
public void saveAgeById(int age, int userId) {
// DB에서 id가 userId인 user에 입력 받은 age를 저장하는 의사코드
this.database.executeQuery("UPDATE user SET age = ? WHERE id = ?", age);
}
}
클래스나 인터페이스의 모든 메서드에 @Transactional을 붙여야 한다면,
아래와 같이 클래스나 인터페이스 상단에 1번 붙이는 것으로 대체할 수 있습니다.
@Transactional
public class Dao {
public void saveNameById(String name, int userId) {
// DB에서 id가 userId인 user에 입력 받은 name을 저장하는 의사코드
this.database.executeQuery("UPDATE user SET name = ? WHERE id = ?", name);
}
public void saveAgeById(int age, int userId) {
// DB에서 id가 userId인 user에 입력 받은 age를 저장하는 의사코드
this.database.executeQuery("UPDATE user SET age = ? WHERE id = ?", age);
}
}
스프링 공식 문서에서는, 인터페이스에 주석을 추가하기보다, 구체적인 클래스나 메서드에 주석을 추가할 것을 권장합니다.
예상대로 동작하지 않을 수 있기 때문인데요, 자세한 사항은 공식 문서에서 설명하고 있습니다.
@Transactional의 적용 범위
@Transactional의 사용 시, 예상대로 동작하지 않을 수 있는 사례 한 가지를 소개하고자 합니다.
그것은 바로 내부 호출입니다.
public class Service {
privata final Dao dao;
public saveResult(int userId) {
this.saveResultByDao(userId); // Dao를 사용하는 로직을 새로운 메서드로 분리
}
@Transactional
public saveResultByDao(int userId) {
this.dao.saveNameById("name", userId);
this.dao.saveAgeById(40, userId);
}
}
(상기 코드는 상위의 Controller가 Service의 saveResult() 메서드를 호출한다고 가정하겠습니다.)
위의 코드는, saveResult() 메서드 내부에서 Dao를 사용하여 DB를 수정하는 로직을 분리한 코드입니다.
name과 age를 저장하는 행위가 하나의 트랜잭션으로 묶일 것 같지만, 그렇지 않습니다.
내부에서 호출하는 함수의 @Transational 애너테이션이 무시되기 때문입니다.
@Transactional은 프록시 모드에서 작동하고, 프록시를 통해 들어오는 외부 메서드 호출만 가로채기 때문입니다. 이를 정확하게 이해하려면 프록시 패턴을 사용하는 스프링 AOP를 이해해야 합니다. 본 아티클에서는 이정도로만 다루겠습니다.
(설정을 통해 모드를 변경하면, 내부 호출도 @Transactional을 적용할 수 있다고 합니다. 자세한 내용은 공식 문서를 참고해주세요.)
정리하자면, @Transactional은 프록시를 통해 들어오는 외부 메서드 호출만 가로채기 때문에 내부에서 호출되는 메서드에 추가된 @Transactional은 무시됩니다.
Java 1.5부터 지원된 자동 언박싱 프로세스(Auto-unboxing process) 덕분인데요,
간단한 코드 예시로 알아보겠습니다.
public class Customer {
private long id;
private String firstName, lastName;
public Customer(long id, String firstName, String lastName) {
this.id = id;
this.firstName = firstName;
this.lastName = lastName;
}
}
위의 코드는, 예시코드에서 사용할 Customer 클래스입니다.
// primitive 타입 사용
long number = 1;
String firstName = "first";
String lastName = "last";
new Customer(number, firstName, lastName); // 생성 성공
// Wrapper 타입 사용
Long wrapperedNumber = new Long(1);
String firstName = "first";
String lastName = "last";
new Customer(wrapperedNumber, firstName, lastName); // 생성 성공
long 타입을 인자로 받는 Customer의 생성자에 Long 타입을 전달해도 생성에 성공합니다.
(반대의 경우에도 성공합니다.)
이렇게 필요한 경우에 long에서 Long으로, 혹은 Long에서 long으로 boxing 또는 unboxing하는 기능이 자바 내부적으로 지원됩니다.
Boxing, Unboxing 실행 시간
하지만 boxing, unboxing에 드는 리소스를 무시할 수 없습니다.
아래에서는 테스트 코드를 통해,
Primitive 타입만 사용했을 때
Boxing만 추가되었을 때
Unboxing만 추가되었을 때
Boxing / Unboxing이 모두 추가되었을 때
4가지 케이스에 대한 실행 시간을 측정해보겠습니다.
@Test
void 래퍼_클래스와_기본값_생성자에_인자로_전달_후_연산시간_비교() {
String firstName = "first";
String lastName = "last";
long startTime;
long endTime;
// Primitive 타입만 사용
startTime = System.nanoTime();
for (int i = 0; i < 100_000; i++) {
long primitiveNumber = 1;
new Customer(primitiveNumber, firstName, lastName);
}
endTime = System.nanoTime();
System.out.println("Primitive 타입만 사용 : " + (endTime - startTime) + "ns");
// Unboxing만
Long wrapperNumber = new Long(1); // 시간 측정 전에 Boxing한 객체 생성
startTime = System.nanoTime();
for (int i = 0; i < 100_000; i++) {
new Customer(wrapperNumber, firstName, lastName); // 생성자 내부에서 Auto unboxing
}
endTime = System.nanoTime();
System.out.println("Unboxing만 : " + (endTime - startTime) + "ns");
// Boxing만
startTime = System.nanoTime();
for (int i = 0; i < 100_000; i++) {
Long wrapperNumberInner = new Long(1); // Boxing
new Customer(1, firstName, lastName); // Boxing한 값 사용하지 않고 Primitive 타입 전달
}
endTime = System.nanoTime();
System.out.println("Boxing만 : " + (endTime - startTime) + "ns");
// Boxing + Unboxing
startTime = System.nanoTime();
for (int i = 0; i < 100_000; i++) {
Long wrapperNumberInner = new Long(1); // Boxing
new Customer(wrapperNumberInner, firstName, lastName); // 생성자 내부에서 Auto unboxing
}
endTime = System.nanoTime();
System.out.println("래퍼 클래스로 생성 : " + (endTime - startTime) + "ns");
}
// 출력 :
// Primitive 타입만 사용 : 2721250ns
// Unboxing만 : 3207125ns
// Boxing만 : 4144833ns
// 래퍼 클래스로 생성 : 5515459ns
Auto unboxing, 그리고 Boxing을 통한 Wrapper 클래스 생성 모두 비용이 증가함을 알 수 있습니다.
생성 횟수에 비해 많이 차이나는 수준은 아니지만, 불필요한 Boxing과 Unboxing을 지양할 필요는 있을 것 같습니다.
실제 사용할 때 파라미터를 구체적인 타입으로 바꾸는 기능입니다. (Java 5에서 지원 시작)
(여기서 제네릭은 기능을 나타내는 단어라는 것에 유의해야 합니다.)
컬렉션(리스트, 맵 등), 스트림, Optional 등의 내부 구현에서도 쓰이고,
활용도가 높은 만큼 꼭 이해해야 하는 자바의 기능 중 하나입니다.
다음과 같은 이점이 있습니다.
다양한 타입을 사용하는 클래스(인터페이스)를 만들 수 있다. (타입 변수의 다형성 지원)
코드가 유연해집니다.
불필요한 타입 변환을 제거할 수 있습니다. → 성능 개선
컴파일 시 강한 타입 체크를 할 수 있습니다. → 런타임 에러 방지
제네릭 이전에는 다양한 타입이 필요할 경우 Object로 선언하고, 강제 타입 변환(Casting)을 했었습니다.
이를 생각하면 제네릭의 이점이 더 확연하게 보일 것입니다.
// 제네릭을 사용하지 않은 예
class Box {
private final String content;
public String getContent;
}
위의 코드에서 Box의 내용물(content)에는 String만 들어갈 수 있습니다.
하지만 Box에 Integer나 Date 같은 것도 담고 싶다면, 하나의 타입마다 Box를 새로 만들어야 합니다.
class IntegerBox {
private final Integer content;
...
}
class DateBox {
...
}
제네릭을 사용하면, 타입을 인스턴스 생성 시에 결정할 수 있습니다.
class Box<T> {
private final T content;
public T getContent {
return this.content;
}
}
Box<String> boxOfString = new Box<String>(); // 좌변과 우변이 모두 String이면 -> 우변의 String 생략 가능
Box<Integer> boxOfInteger = new Box<Integer>();
위에서는 class 단위에서 사용하는 타입에 제네릭을 사용했습니다.
더 작은 단위로 메서드 내부에서 사용하는 타입에도 제네릭을 사용할 수 있습니다.
우선 간단한 용례만 보고, 밑에서 자세히 설명하겠습니다.
public <T> T returnAsItIs(T value) {
T newValue = value; // T라는 타입을 사용할 수 있다.
return value;
}
여기서 세 가지 용어를 설명하겠습니다.
제네릭 타입
우선 위의 코드 중, Box라는 class 내부에서 사용할 타입에 제네릭(기능)을 사용했습니다.
이렇게 제네릭(기능)을 사용하여 결정되지 않은 타입을 파라미터로 가지는 클래스와 인터페이스를 제네릭 타입이라고 합니다.
위의 예시에서는 Box가 제네릭 타입입니다.
제네릭 메서드
위의 returnAsItIs() 메서드는 결정되지 않은 타입을 파라미터로 가지고, 메서드 내부에서 사용합니다.
이런 메서드를 제네릭 메서드라고 합니다.
타입 파라미터
제네릭 타입, 제네릭 메서드에서 가지고 있는 타입(위에서는 T)을 타입 파라미터라고 합니다.
제네릭 타입을 생성할 때(Box를 생성할 때 new Box<String>()), 제네릭 메서드를 호출할 때
타입 파라미터에 정해진 타입을 지정해서 전달해야 합니다.
제네틱 타입과 제네릭 메서드
이번에는 위에서 설명한 제네릭 타입와 제네릭 메서드를 좀 더 상세하게 알아보겠습니다.
제네릭 타입의 사용
public class Box<A, B, ...> { ... }
public interface Box<A, B, ...> { ... }
위처럼 결정되지 않은 타입을 파라미터(A, B, …)로 가지는 클래스와 인터페이스를 제네릭 타입이라고 합니다.
제네릭 타입을 사용하려면, 각각의 타입 파라미터에 구체적인 타입을 지정해야 합니다. (그렇지 않으면 암묵적으로 Object가 사용됩니다.)
public class Box<K, V> {
K key;
V Content;
public Box(K key, V content) {
this.key = key;
this.content = content;
}
public V getContentByKey(K key) {
if (key.equals(this.key)) {
return content;
}
return null;
}
Box<String, Integer> box1 = new Box<String, Integer>("key1", 1);
Box<String, Integer> box2 = new Box<>("key2", 2); // 좌변과 우변에 지정하는 타입 파라미터가 같으면 생략 가능
box1.getContentByKey("key1") // 1 반환
box2.getContentByKey("key3") // null 반환
위와 같이 인스턴스 생성시에 지정한 K(String), V(Integer) 타입을, 제네릭 타입 내부에서 자유롭게 사용할 수 있습니다.
제네릭 메서드의 사용
public <T> Box<T> boxing(T content) {
return new Box<T>(content);
}
public <A, B> void printTwoArgument(A a, B b) {
System.out.println(a);
System.out.println(b);
}
위처럼 결정되지 않은 타입을 파라미터(A, B, …)로 가지는 메서드를 제네릭 메서드라고 합니다.
boxing() 메서드를 호출해보겠습니다.
Box<String> boxOfString = this.<String>boxing("hi"); // 타입 파라미터 전달
위의 코드처럼, 제네릭 메서드를 호출 당하는 인스턴스와에 세부 타입을 지정해서 넘겨주어야 합니다.
public class Box<T> {
T content;
public Box(T content) {
this.content = content;
}
public <T> T getInputAsItIs(T value) {
return value;
}
}
위의 코드에서, boxOfString은 제네릭 타입 Box에 String을 타입 파라미터 T로 전달했습니다.
그런데 Box 내부의 메서드 getInputAsItIs() 에서 타입 파라미터 T를 재정의합니다.
Box<String> boxOfString = new Box<>("hi");
System.out.println(boxOfString.content.getClass().getSimpleName()); // 출력 : String
System.out.println(boxOfString.getInputAsItIs(1).getClass().getsimpleName()); // 출력 : Integer
이런 경우, 위의 코드 출력에서 알 수 있듯이
메서드 내부 블록에서는 새롭게 정의한 T를 사용하고,
그 밖에서는 Box 인스턴스 생성 시 전달 받은 타입을 사용합니다.
제한된 타입 파라미터
위에서 사용한 제네릭은 타입 파라미터에 모든 타입이 들어올 수 있습니다.
하지만 내부에서 덧셈 후 결과를 반환해야 한다면, 타입을 Number 클래스의 하위 클래스들로 제한할 필요가 있습니다.
그럴 경우, 제한된 타입 파라미터를 사용할 수 있습니다.
public class NumberBox<T extends Number> {
T number;
public NumberBox(T number) {
this.number = number;
}
}
위의 NumberBox 클래스는 타입 파라미터로 Number를 상속받은 클래스만 전달할 수 있습니다.
new NumberBox<Integer>(1); // -> 생성 성공
new NumberBox(1); // -> T에 Integer 전달
new NumberBox<String>("hi"); // 컴파일 에러 발생(Type parameter 'java.lang.String' is not within its bound; should extend 'java.lang.Number')
이처럼 NumberBox의 타입 파라미터에는 Number를 상속받은 클래스만 들어갈 수 있습니다.
public class IntegerBox<T super Integer> {
T integer;
...
}
위와 같이 super 키워드를 사용하면, Integer 클래스의 상위 클래스들만 들어갈 수 있습니다.
new IntegerBox<Integer>(1); // 생성 성공
new IntegerBox<Number>(1); // 생성 성공
new IntegerBox<String>("hi"); // 컴파일 에러 발생
제한된 타입 파라미터는, 타입 파라미터입니다.
따라서 타입 파라미터에만 사용될 수 있습니다.
class Box<T extends Number> { ... } // 사용 가능
public <T extends String> void printValue(T str) { ... } // 사용 가능
타입 파라미터가 아닌 곳에는 사용할 수 없습니다.
public <T> T extends String void printValue(T str) { ... } // 사용 불가능
public <T> void printValue(T extends String str) { ... } // 사용 불가능
와일드카드 타입 파라미터
제네릭 타입을 인자, 반환 타입, 변수의 타입 선언 용도로 사용할 때,
타입 파라미터로 와일드카드(?)를 사용할 수 있습니다.
의미는 다음과 같습니다.
? : 모든 클래스 사용 가능(? extends Object 와 동일)
? extends A : A를 상속 받은 모든 타입 사용 가능
? super B : B의 모든 상위 타입 사용 가능
위와 같은 상속 구조를 가정하고, 와일드카드에 대해서 상세하게 알아보겠습니다.
public void register(Box<? extends Student> box) { // Student, HighStudent, MiddleStudent 만 가능
System.out.println(box.getContent());
}
Box<Student> boxOfStudent = new Box<>(new Student());
Box<? extends Student> boxOfHighStudent = new Box<>(new HighStudent());
Box<Worker> boxOfWorker = new Box<>(new Worker());
register(boxOfStudent); // 성공
register(boxOfHighStudent); // 성공
register(boxOfWorker); // 컴파일 에러
위의 코드를 통해, 제네릭 타입의 타입 파라미터 범위를 제한하기 위해 와일드카드를 사용할 수 있음을 알 수 있습니다.
하지만 제네릭 타입이 아닌 일반 타입에는 와일드카드를 쓸 수 없습니다.
public void register(? extends Student student) { ... } // 불가능
? extends Number number = 1; // 불가능
제네릭의 변성(공변, 반공변)
변성이란,
타입을 타입 매개변수로서 타입 생성자에 넣었을 때 계층 관계가 유지되는지를 결정하는 성질입니다. (
public List<Object> produce(List<Object> values) {
return new List.of(values);
}
List<String> strings = List.of("hi", "bye");
produce(strings);
위와 같이 코드를 짜는 것이, 다형성을 구현하는 객체지향 프로그래밍의 핵심 중 하나입니다만..
제네릭 타입은 위의 코드 실행이 불가능합니다.
하지만, 와일드카드 타입 파라미터를 사용한다면 가능하게 만들 수는 있습니다.
제네릭 공변으로 만들기
ArrayList<? extends Animal> animals = new ArrayList<Cat>();
위와 같이 extends를 사용하면 Cat-Animal의 관계를 ArrayList 타입 적용 후에도 공변으로 만들 수 있습니다.
public List<Object> produce(List<? extends Object> values) { ... } // 사실 ? extends Object는 그냥 ?와 동일합니다.
List<String> strings = List.of("hi", "bye");
produce(strings);
위에서 불가능했던 타입 다형성의 구현이 가능해졌습니다.
제네릭 반공변으로 만들기
ArrayList<? super Cat> cats = new ArrayList<Animal>();
위와 같이 super 키워드를 사용하면 Cat-Animal의 관계를 ArrayList 타입 적용 후에 반공변으로 만들 수 있습니다.
class IntegerFactory {
private final List<Integer> numbers;
public IntegerFactory() {
this.numbers = new ArrayList<>();
this.numbers.add(1);
}
public void consume(List<? super Integer> values) {
values.add(this.numbers.get(0));
}
}
IntegerFactory integerFactory = new IntegerFactory();
List<Number> values = new ArrayList<>();
integerFactory.consume(values); // values를 consume 함수에 보내 1을 받아온다.
System.out.println(values); // 출력 : [1]
consume() 메서드의 인자로 List<Number>를 보낼 수 있게 되었습니다.
제네릭 PECS
PECS는 Producer-Extends / Consumer-Super 의 약자입니다.
눈치채셨을 수도 있는데, 위의 공변, 반공변 예시 코드에서 produce, consume 이라는 메서드명을 사용했습니다.
외부에서 온 데이터(매개변수)를 가지고 생산(Produce)에 사용하면 <? extends T> 를 사용하고,
외부에서 온 데이터(매개변수)를 가지고 소비(Consumer)에 사용하면 <? super T>를 사용하라는 원칙입니다.
이는 조슈아 블로흐의 이펙티브 자바에서 소개된 공식입니다.
잘만 이해하면 제네릭의 공변, 반공변성 설정을 쉽게 하도록 도와줍니다. 그런데,
이해하기가 쉽지 않네요.. 개인적으로 직관적인 공식은 아닌 것 같습니다.
생산, 소비의 기준이 ‘외부에서 온 데이터를 가지고’인데,
이는 Producer-Extends / Consumer-Super 라는 표현에 들어 있지 않습니다.
독립적인 정보로 외워야 합니다.
각설하고, 위에서 예시로 들었던 코드보다
조금 더 상세한 예시로 PECS를 설명해보겠습니다.
class CustomList<T> {
Object[] elements = new Object[10]
int pointer = 0;
// Prodece - Extends : 공변성 부여
public void produce(List<? extends T> values) {
for (T element : values) {
elements[index++] = element;
}
}
// Consume - Super : 반공변성 부여
public void consume(List<? super T> values) {
for (Object element : this.elements) {
values.add((T)element);
}
}
}
