getter 사용

 

getter 쓰지 말라고요?

 

이유 1: 객체의 내부 구조를 외부에서 직접 조작하게 되면 캡슐화, 모듈화가 깨지면서 코드의 안정성이 심각하게 무너진다.

 

이유 2: 객체의 필드가 public이라면, 필드를 private로 하고 getter 메서드를 사용하더라도, 필드를 public으로 공개하는 것과 다를 바가 없는 구조라면 결국 똑같은 문제가 일어난다.

 

 

getter가 그냥  머릿속에서 지우면 되나요?

 

사실상, getter가 문제인 게 아니라, 객체의 구성 요소를 외부에서 조작하게 만드는 설계 구조가 문제를 일으키는 것이다.

 

 

우리는 왜 getter가 필요한지 알아야 한다.

 

 

우리는 보통 클래스 안에 있는 필드 값을 사용하기 위해 getter를 찾는다. 그럼 왜 그 값이 필요한지 의문을 던져야 한다.

 

가져온 값을 활용하여 어떤 일을 하려는 지, 목적이 있어야 한다.

 

 

위 코드는 부끄럽지만 내 2주 차 자동차 미션 일부 코드이다. 뭐가 문제일까?

 

난 Winner를 결정하기 위해서, 자동차 객체 리스트들을 순회하며 가장 멀리 간 자동차를 찾고 있다. 그러기 위해선 자동차 객체의 위치 값이 필요하다. 위치 값을 가져온 다음 maxPosition과 비교한다. 만약에 같다면 Winner인 것이다.

 

여기서 내가 getter가 필요한 이유는 자동차 객체의 위치 값이 maxPostion과 일치하는지 보기 위해서다.

 

목적이 분명해졌다.

 

Tell, Don't Ask

그럼 우리는 라는 방식을 쓸 수 있다. 즉, 물어보지 말고 시키면 된다.

 

자동차! 네가 해!

 

자동차 객체의 위치 값을 가져와서 우리가 비교하는 게 아니라, 자동차한테 시키는 것이다.

 

이 경우, 객체지향적인 코드를 쓰기 위한 중요 개념인 행동, 메시지라는 용어가 등장한다.

 

 

객체는 자율적인 존재라는 점을 명심하라. 객체지향의 세계에서 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다. 자율적인 객체는 스스로 자신의 상태를 책임져야 한다. 외부의 객체가 직접적으로 객체의 상태를 주무를 수 없다면 간접적으로 객체의 상태를 변경하거나 조회할 수 있는 방법이 필요하다.

이 시점에 행동이 무대 위로 등장한다. 행동은 다른 객체로 하여금 간접적으로 객체의 상태를 변경하는 것을 가능하게 한다. 객체는 스스로의 행동에 의해서만 상태가 변경되는 것을 보함으로써 객체의 자율성을 보장한다.

객체지향의 사실과 오해 中

 

자동차 객체에 '위치 값을 비교한다'라는 행동을 요청하는 메시지를 보내라. 그렇다면 자동차 객체에서 메시지를 받고 위치 값을 비교하는 행동을 알아서 실행하도록 하면 된다.

 

    /* 위치 값을 비교한다 */
  public boolean isSamePosition(int position) {
  	return this.position == position;
  }

 

public List<Car> decideWinner(int position) {
	return cars.stream()
    		.filter(car -> car.isSamePosition(position)
        	.toList();
}

 

 

이로써 객체 내부 필드를 사용해 작업하는 부분을 객체의 내부로 이동시켰다. 그랬더니 내부 필드와 외부 객체 사이의 의존성은 약해지고 getter 메서드는 사라지게 되었다.

 

 

유연한 설계로 이어진다

이러한 객체 간의 상호작용을 통해 외부 객체는 객체의 내부 구현에 대한 의존성을 낮출 수 있다. 또한, 필드 값을 가져와 작업하는 코드를 객체의 내부로 이동시키는 것만으로도 객체의 내부 구조와의 의존성을 줄일 수 있다.

 

코드를 리팩터링 하여 객체의 필드와 관련된 작업을 객체 내부에서 수행하도록 설계하면, Getter 메서드의 사용을 최소화하고 객체지향적인 설계를 강화할 수 있다. 이런 설계 방식은 유지보수가 쉽고 확장 가능한 시스템을 만드는데 도움이 된다.

 

 

결론

Getter 메서드는 객체의 필드 값을 가져오는 역할을 하지만, 이를 사용할 때에는 그 목적을 고민해야 한다. 객체 간의 상호작용과 메시지 전달을 통해 객체의 내부 구현에 대한 의존성을 낮추고 유연하고 안정적인 객체지향 설계를 구축하는 것이 중요하다. 필드 값을 가져오고 조작하는 코드를 최소화하여 객체의 자율성을 강화하고 코드의 안정성을 높이는 것이 좋다.