มีเหตุผลที่ดีที่จะทำให้ฟังก์ชั่นที่บริสุทธิ์ไม่ใช่แบบสาธารณะหรือไม่?

ฉันมีการอภิปรายเล็กน้อยเกิดขึ้นกับเพื่อนร่วมงาน มีเหตุผลที่ดีที่จะซ่อน / ห่อหุ้มฟังก์ชั่นที่บริสุทธิ์หรือไม่?

โดย "pure" ฉันหมายถึงคำจำกัดความของวิกิพีเดีย :

• ส่งคืนผลลัพธ์เดียวกันจากอินพุตเดียวกันเสมอ (เพื่อประโยชน์ในการสนทนาFoo Create(){ return new Foo(); }นี้ถือว่าไม่บริสุทธิ์หากFooไม่มีความหมายตามตัวอักษร)
• ห้ามใช้สถานะที่ไม่แน่นอน (ยกเว้นตัวแปรโลคัล) หรือ I / O
• ไม่ก่อให้เกิดผลข้างเคียง

ฟังก์ชั่นที่บริสุทธิ์อาจยังคงเป็นรายละเอียดการใช้งาน แม้ว่าฟังก์ชั่นอาจไม่ก่อให้เกิดอันตราย (จากมุมมองของการไม่ทำลายค่าคงที่ / สัญญาที่สำคัญ) โดยการเปิดเผยทั้งผู้เขียนและผู้ใช้ของคลาส / โมดูล / แพ็กเกจนั้นสูญเสีย ผู้เขียนเสียเพราะตอนนี้เขาไม่สามารถลบมันได้แม้ว่าการเปลี่ยนแปลงการใช้งานและฟังก์ชั่นจะไม่มีประโยชน์กับเขาอีกต่อไป ผู้ใช้สูญเสียเนื่องจากต้องกรองและละเว้นฟังก์ชันพิเศษที่ไม่เกี่ยวข้องกับการใช้ API เพื่อทำความเข้าใจ

คำถามย้อนหลัง

คุณไม่ได้หาเหตุผลที่จะทำให้ฟังก์ชั่นที่ไม่ใช่แบบสาธารณะ มันเป็นความคิดที่ไม่ถูกต้องที่จะเริ่มต้นด้วย (ในความคิดของฉัน) เหตุผลควรไปในทางอื่น

กล่าวอีกนัยหนึ่ง - อย่าถามว่า "ทำไมฉันถึงทำให้เป็นส่วนตัว?" ถาม: "ทำไมฉันถึงต้องเปิดเผยสู่สาธารณะ"

เมื่อมีข้อสงสัยอย่าเปิดเผย มันเป็นเหมือนมีดโกนของ Ockham - อย่ามีสิทธิ์ทวีคูณเกินความจำเป็น

แก้ไข:การตอบโต้การโต้เถียงที่นำเสนอโดย @Telastyn ในความคิดเห็น (เพื่อหลีกเลี่ยงการอภิปรายเพิ่มเติมที่นั่น):

ฉันเคยได้ยินเรื่องนี้เมื่อเวลาผ่านไปและแม้กระทั่งดำเนินการในบางเวลา แต่จากประสบการณ์ของฉันสิ่งต่าง ๆ มีแนวโน้มที่จะเป็นส่วนตัวเกินไป

ใช่มันเป็นความเจ็บปวดในบางครั้งถ้าคลาสเปิดสำหรับการสืบทอด แต่คุณไม่สามารถแทนที่วิธีส่วนตัวบางอย่าง (ซึ่งมีพฤติกรรมที่คุณต้องการแก้ไข)

แต่protectedจะพอเพียง - และก็ยังไม่เป็นสาธารณะ

มันนำไปสู่การทำสำเนารหัสจำนวนมากและค่าใช้จ่ายในการเข้าถึง "สิ่งที่ไม่ควรเป็นสาธารณะ" แต่ยังสามารถเข้าถึงได้ทางอ้อมอย่างไรก็ตาม

ถ้ามันกลายเป็นปัญหาคุณก็แค่เปิดเผยสู่สาธารณะ! มีความจำเป็นที่ฉันพูดถึง :)

ประเด็นของฉันคือคุณไม่ควรทำในกรณี (YAGNI และทั้งหมด)

โปรดทราบว่าการทำให้ฟังก์ชั่นส่วนตัวเป็นสาธารณะนั้นง่ายกว่าการดึงมันกลับไปสู่ความเป็นส่วนตัว หลังมีแนวโน้มที่จะทำลายรหัสที่มีอยู่

ฉันไม่คิดว่าการตัดสินใจซ่อน / ห่อหุ้มฟังก์ชั่นควรขึ้นอยู่กับความบริสุทธิ์ของมัน เพียงเพราะฟังก์ชั่นนั้นบริสุทธิ์ไม่ได้หมายความว่าภายนอกจำเป็นต้องรู้เกี่ยวกับมัน น่าสนใจพอแม้ว่าถ้าฟังก์ชั่นนั้นบริสุทธิ์และตั้งใจให้เป็นสาธารณะบางทีมันอาจไม่จำเป็นต้องเป็นอินสแตนซ์ที่เป็นสมาชิกของอินเทอร์เฟซเลยบางทีมันอาจจะเหมาะกว่าสำหรับสแตติก แต่ทั้งหมดนี้ขึ้นอยู่กับเจตนาของสัญญาและในกรณีนี้การจัดกลุ่มแบบลอจิคัลของฟังก์ชันไม่ใช่ความบริสุทธิ์ของฟังก์ชัน

เรียนควรเป็นไปตามหลักการ Single รับผิดชอบ ในขณะที่ชั้นเรียนอาจต้องเรียกใช้ฟังก์ชันการทำงานอื่นเพื่อให้บรรลุเป้าหมาย แต่ควรเปิดเผยฟังก์ชั่นที่เป็นส่วนหนึ่งของความรับผิดชอบเดียวเท่านั้น

นี่เป็นเพียงตัวอย่างหนึ่งของกรณีที่การมองเห็นอาจทำให้เกิดปัญหาได้

พิจารณาคลาสที่วิดเจ็ต frobnicates อาจเป็นส่วนหนึ่งของรหัส frobnication มันต้องการฟังก์ชั่นยูทิลิตี้บางอย่างที่แยกสตริง: บางทีมันอาจจำเป็นต้องเปลี่ยนชื่อวิดเจ็ตในทางที่ฟังก์ชั่นสตริงมาตรฐานไม่สนับสนุน

เนื่องจากนี่คือฟังก์ชั่นแท้ (สตริงเข้ามาเปลี่ยนมันอย่างใดกลับสตริงใหม่) มันอาจจะเป็นสาธารณะหรือส่วนตัวโดยไม่มีผล หรือมันได้หรือไม่

ถ้าคุณทำให้มันเป็นแบบสาธารณะตอนนี้ชั้นเรียนของคุณมีความรับผิดชอบสองอย่าง: เครื่องมือการเหยียดหยามและการเปลี่ยนสาย สิ่งนี้ละเมิด SRP และอาจทำให้เกิดปัญหาได้หากคลาสอื่น ๆ พึ่งพาฟังก์ชั่น เนื่องจากนี่เป็นสิ่งที่คุณคิดว่าใช้ภายในห้องเรียนเท่านั้นบางทีคุณอาจเปลี่ยนอินเทอร์เฟซหรือการมองเห็น ตอนนี้คลาสในส่วนอื่น ๆ ของระบบจะใช้งานไม่ได้

โดยการรักษาฟังก์ชั่นส่วนตัวไม่มีใครเคยมีโอกาสที่จะพึ่งพารหัสที่ไม่ได้เป็นส่วนหนึ่งของความรับผิดชอบเดียวของชั้นเรียน