Skip to content

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

Open

Description

@ghojeong
No description provided.

Activity

  1. punsoo commented on Mar 2, 2021

    @punsoo
    Member

    p23을 보면

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

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

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

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

  2. ghojeong commented on Mar 8, 2021

    @ghojeong
    MemberAuthor

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

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

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

  3. punsoo commented on Mar 13, 2021

    @punsoo
    Member

    p24에 보면

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

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

  4. ghojeong commented on Mar 13, 2021

    @ghojeong
    MemberAuthor

    p24에 보면

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

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

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

  5. punsoo commented on Mar 13, 2021

    @punsoo
    Member

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

  6. ghojeong commented on Mar 13, 2021

    @ghojeong
    MemberAuthor

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

  7. punsoo commented on Mar 23, 2021

    @punsoo
    Member

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

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

    Should I document my private methods?

  8. ghojeong commented on Mar 23, 2021

    @ghojeong
    MemberAuthor

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

  9. ghojeong commented on Mar 23, 2021

    @ghojeong
    MemberAuthor

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions