작성
·
51
·
수정됨
0
안녕하세요, 우빈님 강의 정말 잘 듣고 있습니다!
한가지 의문점이 드는 것은 private 메서드는 테스트를 하지 않고 그냐 유지하되, 필요 시에 따로 클래스를 분리하여 객체를 만드신다고 했는데요, 그냥 간편히 private 메서드를 public 메서드로 변환해서 내부 호출하는 방법은 별로 고려되지 않은 것 같은데 따로 이유가 있을까요?
혹시 createNextProductNumber()가 ProductService 클래스의 성격과는 맞지 않아서 분리하는 경우인지, createNextProductNumber()가 결국 다른 곳에서 사용 될 수 있이므로 별도의 파일로 관리하는지 궁금합니다
답변 2
0
안녕하세요, 돈까스는맛있어 님!
private 메서드를 테스트 하지 않는다고 한 적은 없습니다.
private 메서드는 해당 메서드를 사용하고 있는 public 메서드를 통해서 테스트 케이스가 정의되고, 테스팅되어야 한다고 이야기한 것인데요.
또한 private 메서드를 public 메서드로 바꾸는 것은 행위는 간단하나, 객체의 설계 관점에서 보았을 때 좋은 구조가 아닙니다.
private 메서드는 외부에서 그 로직을 알지 못하도록 캡슐화 되어있는 것인데, 이를 외부에 공개함으로써 예기치 못한 정보의 노출과, 사이드이펙트(잘못 사용하거나 하는 등)를 야기할 수 있습니다.
도움이 되셨기를 바랍니다.
감사합니다. 🙂
0
안녕하세요, 인프런 AI 인턴입니다.
돈까스는맛있어 님의 질문에 대해 답변드리겠습니다.
private 메서드를 public으로 변환하는 것은 쉬운 해결책처럼 보일 수 있지만, 일반적으로 권장되지 않는 이유가 있습니다:
캡슐화 원칙: 객체지향 프로그래밍의 기본 원칙 중 하나는 캡슐화입니다. private 메서드는 클래스의 내부 구현을 숨기고, 외부에서 접근 가능한 최소한의 인터페이스만을 제공하는 역할을 합니다. 이를 public으로 바꾸면 클래스의 무결성이 손상될 가능성이 있습니다.
복잡성 증가: 메서드를 public으로 변환함으로써 코드베이스 내에서 불필요한 복잡성이 증가할 수 있습니다. 다른 클래스에서 public 메서드를 호출할 수 있게 되면, 그 메서드의 계약이 변경되거나 기능이 추가되었을 때 영향을 받는 코드가 많아집니다.
테스트 목적과 잘못된 접근: 단지 테스트만을 위해 접근 제어자를 변경하는 것은 좋지 않은 테스트 방법입니다. 대신, 그런 필요성이 있다면 코드 구조를 리팩토링하여 테스트 가능한 작은 단위로 쪼개는 것이 좋습니다.
관련하여 private method 테스트문의 게시글을 참고해보시면 다양한 의견을 볼 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.