나는 동료와 약간의 토론이있었습니다. 간단히 말해서 순수한 함수를 숨기거나 캡슐화 할만한 이유가 있습니까?
“순수”란 위키피디아 정의를 의미합니다 .
- 항상 동일한 입력에서 동일한 결과를 반환합니다. (이 의미에서 가치 의미론이
Foo Create(){ return new Foo(); }없다면 이 논의 는 불완전한 것으로 간주됩니다Foo.) - 변경 가능한 상태 (로컬 변수 제외) 또는 I / O를 사용하지 않습니다.
- 부작용을 일으키지 않습니다.
답변
순수한 함수는 여전히 구현 세부 사항이 될 수 있습니다. 이 기능은 (중요한 불변량 / 계약을 깨뜨리지 않는 관점에서) 해를 끼치 지 않을 수 있지만, 해당 클래스 / 모듈 / 패키지의 작성자와 사용자 모두에게 노출되면 손실됩니다. 이제 구현이 변경되어 더 이상 기능이 유용하지 않아도이를 제거 할 수 없기 때문에 작성자가 손실됩니다. 사용자는 API를 이해하기 위해 API 사용과 관련이없는 추가 기능을 조사하고 무시해야하므로 손실됩니다.
답변
문제는 거꾸로입니다.
비공개 기능을 수행 할 이유를 찾지 않습니다. (제 생각에) 시작하는 것은 잘못된 생각입니다. 추론은 다른 방향으로 가야합니다.
다시 말해서 “왜 내가 비공개로 만들어야합니까?”라고 묻지 마십시오. “왜 그것을 공개해야합니까?”
의심스러운 경우 노출시키지 마십시오. 그것은 Ockham의 면도기와 같습니다-필요 이상으로 질식을 번복하지 마십시오.
편집 : @Telastyn이 제기 한 반론에 대한 의견을 제시합니다 (확장 토론을 피하기 위해).
나는 시간이 지남에 따라 꽤 오랫동안 그것을 간첩했지만 내 경험상 사물은 너무 사적인 경향이 있습니다.
예, 클래스가 상속을 위해 열려 있으면 때로는 고통 스럽지만 일부 개인 메서드 (이 동작을 변경하려는)를 재정의 할 수는 없습니다.
그러나 protected충분 – 그리고 여전히 비공개입니다.
그것은 “공개해서는 안되는 것들”에 도달하기 위해 많은 코드 복제 및 오버 헤드를 가져 오지만 어쨌든 간접적으로 액세스됩니다.
문제가된다면 공개하기 만하면됩니다! 내가 이야기 할 필요성이 있습니다 🙂
내 요점은 당신이 경우에 (YAGNI와 모두) 그것을해서는 안된다는 것 입니다.
개인 기능을 공개로 가져 오는 것보다 개인 기능을 공개하는 것이 항상 쉽습니다. 후자는 기존 코드를 손상시킬 수 있습니다.
답변
함수를 숨기거나 캡슐화하려는 결정이 순도에 달려 있다고 생각하지 않습니다. 기능이 순수하다고해서 외부인이이를 알아야한다는 의미는 아닙니다. 흥미롭게도 함수가 순수하고 공개되어야하는 경우 인터페이스의 인스턴스 멤버가 아니어도 정적으로 더 적합 할 수 있습니다. 그러나이 모든 것은 계약의 의도와이 경우 기능의 순수성이 아니라 기능의 논리적 그룹화에 달려 있습니다.
답변
수업은 단일 책임 원칙을 준수해야합니다 . 클래스가 목표를 달성하기 위해 다른 기능을 호출해야 할 수도 있지만, 단일 책임의 일부인 기능 만 노출해야합니다.
다음은 가시성 이 문제를 일으킬 수 있는 사례 중 하나 입니다.
위젯을 약화시키는 클래스를 고려하십시오. 약자 코드의 일부로 문자열을 구문 분석하는 유틸리티 함수가 필요할 수 있습니다. 아마도 표준 문자열 함수가 지원하지 않는 방식으로 위젯 이름을 변환해야합니다.
이것은 순수한 함수 (문자열이 들어오고 어떻게 든 변환하고 새로운 문자열을 반환 함)이므로 결과없이 공개 또는 비공개 일 수 있습니다. 아니면 할 수 있습니까?
frobnicating 위젯 : 당신이 그것을 공개 할 경우, 지금 클래스는 두 가지 책임이있다 및 변형 문자열을. 이것은 SRP를 위반하며 다른 클래스가 함수에 의존하는 경우 문제를 일으킬 수 있습니다. 이것은 클래스 내부에서만 사용되는 것으로 생각되므로 인터페이스 또는 가시성을 변경할 수 있습니다. 이제 시스템의 다른 부분에있는 클래스가 깨졌습니다.
이 함수를 비공개로 유지함으로써 아무도 클래스의 단일 책임에 속하지 않는 코드에 의존 할 수있는 기회가 없습니다.