วิธีทั่วไปในการจัดการการมองเห็นในไลบรารีคืออะไร?

คำถามนี้เกี่ยวกับเวลาที่จะใช้ส่วนตัวและเมื่อใดควรใช้การป้องกันในชั้นเรียนทำให้ฉันคิด (ฉันจะขยายคำถามนี้ไปยังคลาสและวิธีการขั้นสุดท้ายเนื่องจากมีความเกี่ยวข้องฉันกำลังเขียนโปรแกรมใน Java แต่ฉันคิดว่านี่เกี่ยวข้องกับทุกภาษา OOP)

คำตอบที่ได้รับการยอมรับ:

กฎง่ายๆคือทำทุกอย่างให้เป็นส่วนตัวที่สุด

และอีกหนึ่ง:

1. ทำให้คลาสทั้งหมดจบลงเว้นแต่ว่าคุณจะต้องการคลาสย่อยเหล่านั้นในทันที
2. ทำให้วิธีการทั้งหมดเป็นขั้นสุดท้ายเว้นแต่ว่าคุณจะต้อง subclass และแทนที่พวกเขาทันที
3. ทำพารามิเตอร์เมธอดทั้งหมดให้เป็นที่สุดเว้นแต่คุณจำเป็นต้องเปลี่ยนพารามิเตอร์ภายในเนื้อความของเมธอดซึ่งค่อนข้างน่าอึดอัดใจเกือบทุกครั้ง

ค่อนข้างตรงไปตรงมาและชัดเจน แต่ถ้าฉันส่วนใหญ่เขียนไลบรารี่ (Open Source บน GitHub) แทนที่จะเป็นแอพพลิเคชั่น

ฉันสามารถตั้งชื่อห้องสมุดและสถานการณ์มากมายได้ที่ไหน

• ห้องสมุดได้ขยายออกไปอย่างที่นักพัฒนาไม่เคยคิดมาก่อน
• สิ่งนี้จะต้องทำด้วย "class loader magic" และแฮ็กอื่น ๆ เนื่องจากข้อ จำกัด ในการมองเห็น
• ไลบรารี่ถูกนำไปใช้ในวิธีที่พวกเขาไม่ได้สร้างขึ้นมา
• ไม่สามารถใช้ไลบรารีเนื่องจากปัญหาเล็ก ๆ (ข้อผิดพลาดฟังก์ชันการทำงานที่ขาดหายไปพฤติกรรม "ผิด") ที่ไม่สามารถเปลี่ยนแปลงได้เนื่องจากการมองเห็นลดลง
• ปัญหาที่ไม่สามารถแก้ไขได้นำไปสู่การแก้ไขปัญหาขนาดใหญ่ที่น่าเกลียดและบั๊กกี้ซึ่งการแทนที่ฟังก์ชั่นที่เรียบง่าย

และฉันก็เริ่มตั้งชื่อเหล่านี้จนกระทั่งคำถามยาวเกินไปและฉันตัดสินใจที่จะลบออก

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

เนื่องจากไลบรารีโอเพ่นซอร์สขนาดใหญ่ไม่ใช่สิ่งใหม่อะไรคือวิธีที่พบได้บ่อยที่สุดในการจัดการการมองเห็นในโครงการดังกล่าวด้วยภาษาเชิงวัตถุ

ความจริงที่โชคร้ายก็คือว่าห้องสมุดจำนวนมากได้รับการเขียนไม่ได้รับการออกแบบ นี่เป็นเรื่องน่าเศร้าเพราะความคิดก่อนหน้าเล็กน้อยสามารถป้องกันปัญหาได้มากมาย

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

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

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

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

ที่สำคัญเมื่อมีบางสิ่งที่เป็นส่วนหนึ่งของ API สาธารณะคุณจะไม่สามารถนำกลับมาใช้ใหม่ได้ คุณไม่สามารถ refactor ได้โดยไม่ทำลายรหัสต่อเนื่อง การเปิดกว้างก่อนกำหนด จำกัด ไลบรารีไว้ที่การออกแบบที่ไม่ดี ในทางกลับกันการทำให้สิ่งของภายในเป็นส่วนตัว แต่การเพิ่ม hooks ถ้าหากภายหลังจำเป็นต้องใช้มันก็เป็นวิธีที่ปลอดภัยกว่า ขณะที่เป็นวิธีที่มีสติที่จะแก้ไขปัญหาการพัฒนาในระยะยาวของห้องสมุดนี้เป็นที่น่าพอใจสำหรับผู้ใช้ที่ต้องการใช้ห้องสมุดในขณะนี้

แล้วจะเกิดอะไรขึ้นแทน? หากมีความเจ็บปวดอย่างมากกับสถานะปัจจุบันของไลบรารีผู้พัฒนาสามารถรับความรู้ทั้งหมดเกี่ยวกับกรณีการใช้งานจริงที่สะสมอยู่ตามเวลาและเขียนไลบรารีเวอร์ชัน 2 มันจะดีมาก! มันจะแก้ไขข้อบกพร่องเหล่านั้นทั้งหมดด้วยการออกแบบ! มันจะใช้เวลานานกว่าที่คาดไว้ในหลายกรณี และหากเวอร์ชันใหม่แตกต่างจากเวอร์ชันเก่ามากอาจเป็นการยากที่จะกระตุ้นให้ผู้ใช้โยกย้าย จากนั้นคุณจะเหลือรุ่นสองรุ่นที่เข้ากันไม่ได้

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

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

• รายการส่งเมลจะหารือเกี่ยวกับความต้องการของผู้ใช้และวิธีการนำสิ่งต่าง ๆ ไปใช้
• ระบบติดตามปัญหา (ปัญหา JIRA หรือ Git ฯลฯ ) ติดตามข้อบกพร่องและคำขอคุณสมบัติ
• การควบคุมเวอร์ชันจัดการรหัสต้นฉบับ

ในโครงการที่พัฒนาแล้วสิ่งที่คุณจะเห็นคือบางสิ่งที่อยู่ในบรรทัดเหล่านี้:

1. มีคนต้องการทำบางสิ่งกับห้องสมุดซึ่งไม่ได้ออกแบบมาให้ทำตั้งแต่แรก
2. พวกเขาเพิ่มตั๋วในการติดตามปัญหา
3. ทีมอาจหารือเกี่ยวกับปัญหาในรายการส่งเมลหรือในความคิดเห็นและผู้ร้องขอจะได้รับเชิญให้เข้าร่วมการสนทนาเสมอ
4. การเปลี่ยนแปลง API ได้รับการยอมรับและจัดลำดับความสำคัญหรือปฏิเสธด้วยเหตุผลบางประการ

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

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

ฉันจะพูดคำตอบของฉันใหม่เพราะดูเหมือนว่ามันจะเป็นจุดสนใจของคนบางคน

การมองเห็นคุณสมบัติของคลาส / เมธอดไม่เกี่ยวข้องกับความปลอดภัยหรือการเปิดกว้างของแหล่งที่มา

สาเหตุที่การมองเห็นมีอยู่เพราะวัตถุนั้นบอบบางต่อปัญหาเฉพาะ 4 ประการ:

1. เห็นพ้องด้วย

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

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

2. ช่วยป้องกันไม่ให้ผู้ใช้ถ่ายภาพตัวเองในส่วนของการใช้อินเตอร์เฟส / เท้า ในสาระสำคัญมันช่วยให้คุณควบคุมค่าคงที่ของวัตถุ

วัตถุทุกชิ้นมีหลายสิ่งที่จำเป็นต้องเป็นจริงเพื่อให้อยู่ในสภาพที่สอดคล้องกัน น่าเสียดายที่สิ่งเหล่านี้อาศัยอยู่ในพื้นที่ที่ลูกค้ามองเห็นได้เนื่องจากมีราคาแพงในการย้ายแต่ละวัตถุเข้าสู่กระบวนการของตัวเองและพูดคุยผ่านข้อความ ซึ่งหมายความว่ามันง่ายมากสำหรับวัตถุที่จะพังโปรแกรมทั้งหมดหากผู้ใช้มีความหนืดเต็ม

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

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

3. ขอบเขตมลพิษ

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

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

4. ถูกผูกติดอยู่กับการพึ่งพา

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

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