final
final : 값의 재할당을 막는다(불변과는 다르다)
(ex. List 의 경우 final 선언을 해도 값이 변할 수 있다)
보통 service 클래스를 주입받아서 사용할 때 final 을 자주 접하였을 텐데, 함수 파라미터 앞에는 왜 final 을 붙이는 걸까?
매개변수의 재할당 금지
매개변수의 재할당을 금지하기 위해서이다
예를 들어보자
int plusMethod1(int x) {
x = x + 10;
return x;
}
int plusMethod2(final int x) { // 매개변수의 재할당 금지
int result = x + 10;
return result;
}
plusMethod1( ) 은 매개변수를 재할당하고있다 (x = x + 1)
plusMethod2( ) 는 final 이 선언되었기 때문에 'x = x + 1' 을 작성 시, 컴파일 에러가 발생한다 (재할당이 금지된다)
이런 간단한 예제의 경우 매개변수의 재할당을 금지하는 것에 대한 장점을 느끼기 힘들 것이다
하지만 매우매우 복잡한 경우를 생각해보자
메서드내에서 다른 객체가 복잡한 행위를 한다던지, 다른 메서드를 호출한다던지 하는 복잡한 경우에서는 매개변수 재할당을 금지하는 것은 가독성을 향상시킨다
매개변수의 재할당이 금지되어있다면 해당 코드를 읽는 사람은 전달받은 파라미터의 값이 변할 것이라는 의심을 덜 해도 된다
(역시나 Collection 같은 경우에는 의심을 하긴 해야한다)
함수의 동작을 추적하기 편리해지며 함수의 동작이 명확해진다
이건 왜 되는건데?
함수의 파라미터에 final 키워드를 붙여주는 것은 엄청난 혁신이라던지 엄청난 이점이라던지 있는 것이 아니다
그냥 '보기 좋으니까' 즉, '유지보수 관점으로 봤을때 있는게 더 나으니까' 이다
final 이 가지는 의미 '재할당을 금지한다' 를 '불변한다' 라고 쓰기에는 교집합이 생각보다 좁다
아까 말했듯이 Collection 같은 경우는 재할당이 안되는 것이지 값이 바뀔수있다고 하였다
아래의 예제또한 같은 논리이다
User MyMethod(final User user) {
user.setName("김관현");
return user;
}
final 을 선언하였음에도 user 의 필드는 바뀔 수 있다
말그대로 User 자체의 '재할당' 만 금지하였기에..
결국 우리가 직접 만든 클래스들에는 적용이 불가능하다
그렇다면 원시값 포장을 해버리는 경우에도 불변하다고 보장을 할 수 없다(물론 Setter 안쓰고 생성자로만 값을 입력받으면 불변이다)
'Java > Java 기본' 카테고리의 다른 글
record 에 대한 나의 생각 (0) | 2024.08.26 |
---|---|
DIP 와 인터페이스 소유권의 역전 (0) | 2024.08.26 |
[간단] id 의 타입을 long 이 아니라 굳이 Long 으로 주는 이유 (0) | 2024.08.19 |
컴파일러와 JVM 을 곁들인 상속의 원리 (동적 바인딩) (1) | 2024.07.24 |
클래스와 다형성, 그리고 오버라이딩 (2) | 2024.07.23 |