210303_B책_직접 만들지 말고 자바 AIP 사용하기

오늘은 2.8 <직접 만들지 말고 자바 AIP 사용하기> 를 진행한다.
프로그래밍 초창기에는 전부 스스로 만들어야했고, 이제는 아니다.
언어 훈련으로는 더할 나위 없지만 시간이 많이 걸리고 오류가 발생하기 쉬웠다.

API에 있는 기능을 다시 구현하지 않고 재사용해야한다.
=>(나도 그러고 싶지만 모르는 API가 많다.. 구현하는 것도 연습이 되지만 자바 개발페이지를 자주 봐야겠다.)

예제 코드를 보며 API의 편리한 사용을 보자면,

class Inventory {
 private List<Supply> supplies = new ArrayList<>();
 
 int getQuantity(Supply supply) {
  if (supply == null) {
   throw new NullPointerException("supply must not be null");
  }
  
  int quantity = 0;
  for (Supply supply : supplies) {
   if (supply.equals(supplyInStock)) {
    quantity++;
   }
  }
  return quantity;
  
 }
}

위 코드는 getQuantity()의 조건문을 통해 인력 매개변수의 null값을 확인하고,
재고 내의 supply의 quantity(수량)을 반환한다.
코드는 좋다.
null값을 확인하며 for each문을 통해 수량을 반환하니깐.
하지만 이 코드가 API를 거친다면?

class Inventory {
 private List<Supply> supplies = new ArrayList<>();
 
 int getQuantity(Supply supply) {
  Objects.requireNonNull(supply, "supply must not be null");
  
  return Collections.frequency(supplies, supply);
 }
}

이렇게 두줄로 커버하니 훠얼씬 짧아졌다.

유틸리티 클래스인 Collections는 Collection 내 객체 출현 횟수를 세는 frequency() 메서드를 제공한다.
Objects 유틸리티 클래스의 requireNonNull() 메서드도 사용했다.
이 메서드는 객체가 null이면 메세지와 함께 NullPointerException을 던진다.
=>(이런 null값을 체크하고 메세지 던지는 것을 업무에서는 try catch를 활용해서 사용했는데, 이 방법도 있구나.. 교체했을 때의 이점이 크다면 교체해도 되지 않을까?)

2개의 메서드로 12줄을 커버했다.
API를 알면 일반적으로 코드의 문제를 훨씬 더 간단히 해결할 수 있다.
API 만큼 중요한 것은 API가 전 세계적으로 광범위한 테스트를 거친다는 사실이며,
직접 작성한 코드보다 버그를 일으킬 확률이 매우 적다.
API에 정통하면 진정한 자바 전문가로 거듭날 수 있다.

오늘의 코멘트: 문제는 자바 API를 많이 모른다는 점이다. 앞으로 구현이 필요한 부분에 무턱대고 구현하기보다 API를 한번 찾아보는 것도 괜찮은 생각이다.