คลาสที่ซ้อนกัน: เครื่องมือที่มีประโยชน์หรือการละเมิดการห่อหุ้มข้อมูลหรือไม่


11

ดังนั้นฉันยังอยู่บนรั้วว่าควรใช้สิ่งเหล่านี้หรือไม่

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

โปรเจ็กต์ Java / Swing ก่อนหน้านี้ฉันใช้คลาสที่ซ้อนกันในระดับหนึ่ง แต่ตอนนี้ฉันได้ย้ายไปยังโปรเจ็กต์อื่นใน C # และฉันหลีกเลี่ยงการใช้งาน

คุณรู้สึกอย่างไรเกี่ยวกับคลาสที่ซ้อนกัน?


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

คำตอบ:


8

ก็เช่นกัน: คลาสที่ซ้อนกันไม่ละเมิดการห่อหุ้มและโดยทั่วไปคุณสมบัติด้านภาษาไม่ได้ละเมิดหลักการเขียนโปรแกรม โปรแกรมเมอร์ละเมิดหลักการเขียนโปรแกรม

สนุกพอมันเป็นคลาสที่ซ้อนกันอ้างเพิ่ม encapsulation :

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

มีความจริงบางอย่างในเรื่องนั้น

โดยปกติ B เป็นผลมาจากการใช้SRPกับ A. B เอง แต่อาจละเมิดหลักการจำนวนมากโดยเฉพาะอย่างยิ่งหากสิ่งที่มันทำคือเล่นรอบกับสมาชิกส่วนตัวของ A: D

ฉันคิดว่าคลาสที่ซ่อนอยู่นั้นมีประโยชน์ แต่มีศักยภาพมากมายสำหรับการใช้งานในทางที่ผิด


5

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

บรรทัดล่างคือทำให้การอ่าน / เขียนรหัสง่ายขึ้นและไม่ค่อยมีกรณีที่คุณจะต้องการคลาสสั่งซื้อของคุณและไม่จำเป็นต้องรู้เกี่ยวกับ OrderItems


1

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

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

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


0

(ใน C #) โดยทั่วไปฉันจะหลีกเลี่ยงพวกเขาแม้ว่ามันจะขึ้นอยู่กับวัตถุประสงค์ของการเรียน

ฉันจะไม่ใช้มันสำหรับคลาสโมเดลโดเมนใด ๆ ซึ่งไม่สมเหตุสมผลสำหรับฉัน

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.