Effective Method 주의사항

01. 매개변수가 유효한지 검사하라

매개변수가 유요한지 검사하는 기준

//상황 : 장바구니에 아이템 추가
@RestController
public class ParameterCheckController{
	@Data
    clss AddItemForm{
    	private long itemId;
        private int count;
    }
    
    @PostMapping(valeu = "/{userId}/add")
    public ResonseEntity getBasketInfo(
    		@PathVariable long userId,
            @RequestBody AddItemForm addItemForm){
    	.....        
    }
}


//매개변수 검사하는 위치는 반드시 메서드 시작부분을 권장
public static double calculateUserPoint(
		long userId,
        long carId,
        List<OrderItemInfoVo> orderItemInfoVoList){
        	//유저 등급 조회
            //카드 정보 조회
        }
)

어디서 호출되는지가 중요. 검사 규칙도 TPO가 중요

* 공개된 API일 수록 parameter 검사 기준은 엄격하게 이루어져야 함
* 내부에서 소화될 코드라면 공개된 API만큼은 아닐 지라도, 서비스에 영향이 크게 있거나, 
여러 이슈들로 예측되지 않은 값이 들어올 가능성이 있다면 검사하는 것이 좋음.

02. 메서드 시그니처를 신중히 설계하라

편의 method (ex. Util Class 소속의 method 와 같은) 를 너무 많이 만들지 말자

정말 자주 쓰일 때에만 편의 method를 제공해야 한다.
확신이 생기지 않는다면 private로 쪼개 놓은 후 차후에 다른 class에서의 니즈가 생길 경우 
리팩토링 해도 늦지 않다

Parameter 목록은 짧게

4개 이하 권장. 특히 같은 타입 여러 개는 작성자도 혼란스럽게 한다.

1. 만든 세머드가 너무 장황하였을 확률이 있다.
2. Vo (Value Object) 를 사용한다.

class UserVo{
	private Long id;
    private int age;
    private int footSize;
  	private float weight;
    private float height;
}
...
public static void expandParam(long id, int age, int footSize, 
int weight, int height){
}

03. 다중정의는 신중히 사용하라

Overroding의 위험함을 피하는 방법

매개변수 같은 Overroding은 만들지 않는 것을 추천

만약 만들어야 한다면 차라리 메서드 이름을 다르게 짓는 것을 보수적으로 권장

public List<E> sort(ArrayList<E> arrayList){
	//1번 알고리즘
    return arrayList;
}
public List<E> sort(LinkedList<E> arrayList){
	//2번 알고리즘
    return arrayList;
}
public List<E> sortFromArrayList(ArrayList<E> arrayList){
	//3번 알고리즘
    return arrayList;
}

04. null이 아닌 빈 컬렉션이나 배열을 반환하라

에러 처리가 힘들다. (받는 쪽에서 List의 null 처리를 별도로 해야 한다.)

조금 더 유연하게 생각하자면 empty List or array는 null이 아니다. 단지 내부가 비었을 뿐

Collections.emptyList, Collections.emptyList는 불변 객체로 존재하여 성능 걱정을 안 해도됨

public class Collections{
	public static final list EMPTY_LIST = new Collections.EmptyList();
}

API의 json response는 array? or null?

@GetMapping
public List<String> getNameList(){
	//이름의 리스트가 비었으면
	return Collection.EmptyList();
}
//항상 []를 null 대신 권장하는 편
//리스트가 없는 것이 아닌, 리스트가 비었다고 생각하자
//특정 리스트를 반환해야 하는 Get API의 호출은 정상적으로 이루어졌으나, 그 response가 빈 것일 뿐이다.

05. 옵셔널 반환은 신중히 하라

Optional의 올바른 사용

Optional<Laptop) optionalLaptop = laptopResponsitory.findById(id);
Laptop lpatop = optionalLaptop.orElse(null); //좋지 못함

기본값

값이없을 경우 기본값을 사용하기 위한 용도

//없을 경우 기본값 0을 리턴
public int maxPositiveIntegerValue(List<Integer> integerList){
	return getMaxInteger(integetLisr).orElse(0);
}

private OptionalInt getMaxInteger(List<Integer> integerList){
	retur integerList.stream().mapToInt(Integet::intValue)
    .filter(integer -> integer > 0).max();
}

예외

//JpaRepository의 일부
Optional<T> findById(Id id);

명확히 id 기반으로 찾고, 이 값이 없을 경우 에러라고 가정할 때 원하는 예외를 던지기에 적합

Optional< T> 가 득이 아닌 경우

• Cotainer type(컬렉션, 배열 등..)
• Boxing된 기본 타입 (OptionallInt 같은 것들을 사용)
• 하단의 코드 처럼, Optional을 사용한다면 null을 반환하지 말자(취지와 맞지 않음)

public ItemInfo getIteminfo(){
	return itemInfoRepository.findById(1L).orElse(null);
}