삽질기록 #1 Git, 접근 제어자

(2022.02.18)

오늘부터 TIL도 블로그에 남겨 보기로 했다. 조금씩!

어제오늘 한 삽질들

1. Git이랑 계속 싸우기

PR이 다 끝나기 전에 브랜치 파서 작업하다가 삽질을 엄청 했다. 가장 큰 문제는 PR이 approve되어서 merge까지 완료된 upstream 저장소를 rebase로 끌어오면, 이전에 PR 보냈던 커밋까지 계속 포함된다는 것. 그래서 처음에는 1) cherry-picking으로 새로운 커밋만 범위를 지정해서 커밋해 봤다. 근데 커밋은 잘 됐는데 PR 보내려고 하면 또 예전 커밋까지 같이 뜬다.

그래서 일단 rebase -i upstream/street62(업스트림 브랜치 이름)로 해결했다. -i 플래그를 붙이면 rebase될 커밋 목록이 vi에 쫙 뜨는데, 거기에서 PR 이전 커밋은 vi 단축키 dd를 눌러서 drop한 다음에 커밋하면 된다.

아직 이전 PR 때의 커밋이 다 따라오는 명확한 이유는 이해하지 못했다. 조금 더 삽질을 해 보면서 배운 내용들을 업데이트해 보겠다!

(나중에 읽어 볼 자료들: 링크1, 링크2)

2. 접근 제어자와 멤버 변수 값 변경 문제

사실 접근 제어자로는 늘 public과 private만 쓰고 있었는데, A라는 클래스의 멤버 변수에 'B 클래스는 접근할 수 있지만 그 외에는 접근하지 못하게 하고 싶다' 같은 상황이 있었다. 그래서 어렴풋하게만 알고 있던 접근 제어자에 대해서 찾아봤다. 그래서 늘 쓰던 private과 public 외에도 default와 protected까지의 정확한 접근 가능 범위에 대해서 정리해 보면 다음과 같다.

• private: 이 접근 제어자가 붙은 메서드/변수는 해당 클래스 내에서만 접근이 가능하다.
• default: 따로 접근 제어자를 명시 안 해주면 default가 된다. 이 경우는 해당 패키지 내에서만 접근이 가능하다.
• protected: 동일 패키지의 클래스 + 해당 클래스를 상속받은 다른 패키지의 클래스에서 접근이 가능하다.
• public: 어떤 클래스에서도 접근할 수 있다.

private -> default -> protected -> public 순으로 접근 가능 범위가 넓어진다고 보면 된다. 이름만 봐서는 default보다 protected가 더 접근 가능 범위가 좁을 것 같은데 아니었다! 그래서 패키지를 나누어 주고 보호가 필요한 멤버 변수를 protected로 지정했다.

이 외에도 멤버 변수로 참조 변수를 사용하면 private이라고 하더라도 getter로 넘겨 주면 주소가 전달되는 거라서 외부에서 값을 바꿀 수 있다는 문제점도 있다. 객체 자체를 깊은 복사 하는 등의 방법도 있는데, 외부에서 변경하지 못하게 할 때는 Collections.unmodifiableList()를 쓸 수 있다. 단 이 메서드는 반환값이 ArrayList가 아니라 List이므로 주의해야 한다.

더 찾아보기

- ArrayList로 변수 선언할 때랑, List로 변수 선언할 때 정확한 차이점. 혼용하다가 안 되면 바꾸고... 조금 주먹구구식으로 사용하고 있는데, 조금 더 명확하게 이해할 필요가 있어 보인다.