[아이템 03] private 생성자나 열거 타입으로 싱글턴임을 보증하라

[ghojeong]

No description provided.

[punsoo]

p23을 보면

그런데 클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다. 타입을 인터페이스로 정의한 다음 그 인터페이스를 구현해서 만든 싱글턴이 아니라면 싱글턴 인스턴스를 가짜(mock) 구현으로 대체할 수 없기 때문이다.

이 부분이 잘 이해가 안되네요

깊이 있는 Singleton
[Design Pattern] 싱글턴 패턴이란

위 링크들을 공부해보았습니다.
클래스로 싱글톤을 생성해서 만든 경우, 클래스 사이에 강한 의존성과 결합이 생기면서 수정 및 단위 테스트를 하기 어렵다고 하는 것 같습니다
그렇다면 인터페이스로 구현한 싱글톤은 왜 테스트하기 쉬운 것일까요??

[ghojeong]

인터페이스로 구현한 싱글톤은 왜 테스트하기 쉬운 것일까요??

이 부분은 "익명 클래스" 라는 키워드에 대해서 학습하시면 좋을 것 같습니다.

싱글턴이 테스트하기 어려운 이유는 mocking 이 어렵기 때문입니다. (가짜 구현으로 대체할 수 없기 때문이다.)
아마 mocking 이 무엇인지 잘몰라서 이해가 어려운듯 한데,
Mock, Stub, Spy 라는 테스트 용어에 대해서 공부해보시면 좋을 것 같습니다.

[punsoo]

p24에 보면

코드 3-1의 public 필드 방식의 큰 장점은 해당 클래스가 싱글턴임이 API에 명백히 드러난다는 것이다. public static 필드가 final이니 절대로 다른 객체를 참조할 수 없다. 두 번째 장점은 바로 간결함이다.
한편, 코드 3-2의 정적 팩터리 방식의 첫 번째 장점은 (마음이 바뀌면) API를 바꾸지 않고도 싱글턴이 아니게 변경할 수 있다는 점이다.

라고 되어있는데, 보통 public 메소드나 public 필드가 API에 드러나는 걸까요?

[ghojeong]

p24에 보면

코드 3-1의 public 필드 방식의 큰 장점은 해당 클래스가 싱글턴임이 API에 명백히 드러난다는 것이다. public static 필드가 final이니 절대로 다른 객체를 참조할 수 없다. 두 번째 장점은 바로 간결함이다.
한편, 코드 3-2의 정적 팩터리 방식의 첫 번째 장점은 (마음이 바뀌면) API를 바꾸지 않고도 싱글턴이 아니게 변경할 수 있다는 점이다.

라고 되어있는데, 보통 public 메소드나 public 필드가 API에 드러나는 걸까요?

public 이면 보통 외부 사용자에게 API 로 제공하겠다는 뜻이겠죠?
제공되는 API 도 아닌데 public 으로 드러난게 있다면 버그를 유발 시킬수 있는 악성 코드일테고요

[punsoo]

반대로 private 필드나 private 메소드는 api에 들어나지 않는건가요??

[ghojeong]

api 문서에서 private 멤버나 메서드에 대해 명세하는 경우를 한번도 보지 못했는데 그런 경우도 있나요?

[punsoo]

api 문서에서 private 멤버나 메서드에 대해 명세하는 경우를 한번도 보지 못했는데 그런 경우도 있나요?

private method도 api에 적기도 하는 거 같더라구요...

Should I document my private methods?

[ghojeong]

고렇군요!
문서화는 언제나 좋은일이죠!

[ghojeong]

근데 만약 저라면 private 에 대한 문서를 작성했더라도, 같은 회사의 유지보수팀이나 개발자 동료에게만 private 에 대한 문서를 제공할겁니다.

회사 외부에는 private 을 공개했다가,
뛰어나고 인생이 무료한 해커에게 내부 로직이 어떻게 구현되어 있는지 들켜서,
신나게 털린 다음에 어떤 놈이 회사 정보 유출했어?!?! 라는 소리를 듣고 불려나가서
시말서를 쓰는 상황이 없었으면 해서요.