페이스 유지하기 + getter 지양하기 (22.09.03 TIL)

 지금 아직 이번 3주차 마지막 과제였던 딜리버리 타이쿤을 작업중인데, 중간에 시행착오를 조금 겪어서 완성 속도가 딜레이 되었다. 어제 저녁 집 가기 전에 동기분들과 얘기를 하다가 getter 안쓰는 법에 대해 본인이 어떻게 해결하셨는지 힌트를 주셔서 그걸 내 작업물에 적용해보려다가..너무 얕게 접근한 탓인지 계속 꼬이고 꼬여서 시간을 많이 썼다. getter 를 쓰지 않는 다른 방법으로는 '객체가 다른 객체에게 메시지를 보내면, 상태 데이터를 가지는 객체가 메시지를 보내서 직접 로직을 처리하도록 구현하면 된다' 고 하긴 하는데, 사실 정확히 잘 이해하지 못했다. 중간에 한 다리를 설치해서 객체가 데이터에 직접적으로 접근하는 것을 막는 안전 장치 느낌인가?  그리고 애초에 getter 를 쓰지 않으면 안되는 이유가 무엇일까?

 정확히 이해가 되지 않아서 구글링을 해보다가 2003년에 Allen Holub 이 작성한 "Why getter and setter methods are evil" 이라는 글을 찾게 되었다. 몇달 전엔 밥먹듯이 쓰던 getter 였는데 2003년부터 getter 사용이 지양되어 왔구나..싶어서 조금 놀랐다. 제목에서부터 나와있듯이 getter 가 '악하다' 라는 단어를 쓸 정도인가! 궁금해져서 얼른 읽어봤다. 내용을 조금 요약해보자면 아래와 같다.

---

 객체지향 시스템의 기본 원칙은 객체가 구현 세부 사항을 노출해서는 안 된다는 것이다. 이렇게 하면 객체를 사용하는 코드를 변경하지 않고 구현을 변경할 수 있다. 객체 지향 시스템에서는 getter 및 setter 함수가 대부분 구현 세부 정보에 대한 액세스를 제공하기 때문에 피해야 한다. 객체의 데이터를 마음대로 접근할 수 있다면 메소드를 통해 만들어진 데이터는 의미가 없게 되는 문제가 생긴다. 또한 객체에서 데이터는 어떤 메소드의 실행 결과를 누적해서 보존하는 경우가 많기 때문에 함부로 누구나 사용할 수 있게 해주면 안된다.

 객체지향 시스템의 기본 원칙 중 하나는 데이터 추상화 이다. 프로그램의 나머지 부분에서 객체가 메시지 처리를 구현하는 방식을 완전히 숨겨야 한다. 이것이 모든 인스턴스 변수가 private 이어야 하는 이유이다. 만약 public 으로 만들면 이 필드 변수를 사용하는 외부 코드가 손상된다. getter/setter 는 이 public 이 위험한 것과 같은 이유로 위험하다.

 예를 들어, getX() 라는 메서드가 약 1,000번 동안 호출이 되었고, 이 호출의 반환 값이 int 라고 가정해보자. 우리는 이 getX()의 반환값을 지역 변수에 저장할 수 있고, 해당 변수 유형은 반환값 유형과 동일하게 int 로 저장될 것이다. 하지만 나중에 getX 의 데이터 값이 long 으로 바뀌는 경우 어떻게 될까? 약 1,000개의 컴파일 에러가 발생할 것이다. 그것을 Int 로 강제 형변환 하여 오류를 해결한다고 해도 컴파일은 정상적으로 실행 되겠지만 반환 값이 잘려나갈 수 있다. 즉 제대로 작동하지 않는 것이다. 이러한 오류를 피하기 위해 1,000개의 코드를 각각 수정해야 할 것이다. 확실히 불필요한 작업들이 생길 수 있다.

출처 :

Why getter and setter methods are evil

---

"Don't ask for the information you need to do the work, ask the object that has the information to do the work for you."

"Why getter and setter methods are evil" - by Allen Holub

 "작업을 수행하는 데에 필요한 정보를 요청하지 말고, 정보가 있는 객체에게 작업을 수행하도록 요청해라."

 이 말이 핵심인 것 같아서 가져왔다. 객체의 데이터에 직접 접근하는 것은 위험하다는 것이다. 내가 이해한 바로 객체지향 프로그래밍의 핵심은 필요한 로직이나 기능을 수행할 수 있는 객체에게 내가 원하는 일을 부탁한다(ask)라는 형태로 이루어진다. 따라서 객체지향에서 객체가 가진 데이터가 필요하다면 객체에 데이터를 알고 싶다고 부탁하는 방식의 프로그래밍이 가장 적합하다. (하지만 부탁하는 방법은..?!)

 어쨌든 이 글을 통해서 getter/setter 를 쓰면 유지보수가 어려워지고 코드에 손상이 쉽게 생길 수 있다는 사실에 대해서는 이해를 했다. 중간 내용까지는 영어로도 간단한 어휘들로만 쓰여져 있어서 오랜만에 영어 공부하는 느낌으로 쉽게 해석할 수 있었다. 하지만 점점 내용이 어려워져서 영어 원문 및 한국어 번역으로 봐도 이해가 가지 않아서, 어떻게 하면 getter 대신 다른 방법을 쓸 수 있는지에 대해서는 이해하지 못했다. 이러한 상태에서 한번 시도해보려는 부작용으로 과제 제출 속도에 지대한 피해를 받았으니 과제는 얼른 마무리해서 일단은 커밋하는 것으로! 나중에 방법은 차차 알려주시겠지 싶다. 아샬님 강의에서도 'getter 는 추천하지 않습니다. 다른 방식이 있습니다! 그건 나중에 알려드리겠습니다." 라고 하셨기 때문에 그냥 트레이너분들을 믿고 천천히 내 페이스에 맞춰서 과제를 진행해야겠다.