เป็นการละเมิดหลักการ Open-Closed หรือไม่ในการอัพเดทค่าคงที่ซึ่งแสดงถึงมูลค่าที่แท้จริงของโลก?

ฉันมีชั้นเรียนที่คำนวณรายได้สุทธิต่อปีของคนงาน มันมีค่าคงที่คิดเป็นร้อยละภาษี แต่วันหนึ่งอัตราภาษีมีการเปลี่ยนแปลงดังนั้นฉันต้องแก้ไขรหัส

การกระทำของการแก้ไขค่าคงที่นี้บ่งบอกถึงการละเมิดหลักการ Open-Closedเนื่องจากมันเป็นหลักว่าชั้นควรจะปิดเพื่อแก้ไข?

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

หาก B, C และ D สามารถใช้หรือนำคลาสที่จัดไว้ให้กลับมาใช้ใหม่สำหรับกรณีการใช้งานที่แตกต่างกันโดยไม่จำเป็นต้องแก้ไขซอร์สโค้ดของไลบรารีดังนั้นคอมโพเนนต์จะตอบสนอง OCP ( ตามหมวดหมู่ของกรณีการใช้งาน ) มีวิธีการที่แตกต่างกันเพื่อให้บรรลุเช่นนี้

• การทำให้คลาสสืบทอดได้ (โดยทั่วไปจะใช้ร่วมกับรูปแบบเมธอดเทมเพลตหรือรูปแบบกลยุทธ์)

• โดยให้ "จุดฉีด" สำหรับการฉีดพึ่งพา

• โดยการจัดเตรียมพารามิเตอร์การกำหนดค่าสำหรับคลาสหรือส่วนประกอบ (ตัวอย่างเช่นโดยมีพารามิเตอร์ตัวสร้าง "อัตราภาษี" ในกรณีของคุณหรือโดยใช้กลไกการกำหนดค่าอื่น ๆ )

• อาจหมายถึงวิธีอื่นขึ้นอยู่กับภาษาการเขียนโปรแกรมหรือระบบนิเวศ

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

อย่างที่คุณเห็นสิ่งนี้ไม่เกี่ยวข้องกับการห้ามการเปลี่ยนแปลงของซอร์สโค้ดโดยผู้ขาย A (เช่นการแก้ไขข้อผิดพลาดการปรับให้เหมาะสมหรือเพิ่มคุณสมบัติใหม่ในลักษณะที่เข้ากันได้แบบย้อนหลัง) ซึ่งค่อนข้างไม่เกี่ยวข้องกับ OCP OCP นั้นเกี่ยวกับวิธีที่ A ออกแบบอินเตอร์เฟสและความละเอียดของส่วนประกอบใน lib ดังนั้นสถานการณ์ reusage ที่แตกต่างกัน (เช่น resuage ด้วยอัตราภาษีที่แตกต่างกัน) ไม่ได้กระตุ้นให้เกิดการเปลี่ยนแปลงโดยอัตโนมัติ

ดังนั้นแม้จะมีสิ่งที่คนอื่นบอกคุณที่นี่คำตอบนั้นชัดเจนว่า"ใช่"มันจะเป็นการละเมิด OCP

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

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

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

ในระยะยาวคุณอาจพบว่าปัญหาภาษีต้องการมากกว่าร้อยละ - ตัวอย่างเช่นวันหนึ่งกฎหมายภาษีมีความซับซ้อนมากขึ้นและต้องใช้หลายเปอร์เซ็นต์และค่าคงที่บางอย่าง (เช่นจำนวนเงินต่ำกว่า $ 10k ที่เก็บภาษีที่ X% ในขณะที่ ภาษีที่เหลืออยู่ที่ Y%)

นี่เป็นการแนะนำโดยใช้รูปแบบกลยุทธ์ที่ชั้นเรียนหลักในคำถามที่นี่ยอมรับวัตถุกลยุทธ์สำหรับการคำนวณภาษี

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

แต่ละกลยุทธ์อาจรู้วิธีแยก / ตีความอาร์กิวเมนต์การกำหนดค่าภายนอกของตัวเองพร้อมกับวิธีคำนวณภาษีจริง

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

ดูการฉีดที่พึ่งพาซึ่งเราจัดการสิ่งเหล่านี้อย่างชัดเจน

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

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

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

เห็นด้วยอย่างยิ่งกับ @Becuzz และฉันแค่ต้องการสรุปสิ่งนี้: OCP เกี่ยวข้องกับการค้นหา abstractions ที่นำมาใช้ใหม่ (ซึ่งมีประโยชน์) ที่ถูกฉีดเข้าไปในชั้นเรียน ดังนั้นพฤติกรรมของคลาสจึงไม่ได้ถูกแก้ไขโดยการเปลี่ยนรหัส แต่เป็นการให้การใช้งานที่แตกต่างกัน สิ่งนี้ทำให้ชัดเจนในหนังสือของ Robert Martin เรื่อง " การพัฒนาซอฟต์แวร์หลักการรูปแบบและวิธีปฏิบัติ " ของAgileให้ตรวจสอบบทที่เกี่ยวข้อง "หลักการเปิด - ปิด" บทย่อย "Abstraction is the Key" มันอธิบายความเข้าใจผิดอื่น ๆ ว่าพฤติกรรมสามารถแก้ไขได้ด้วยการสืบทอดเท่านั้น Bertrand Meyer เป็นผู้เสนอว่าในปี 1988 ในหนังสือของเขา“ การก่อสร้างซอฟต์แวร์เชิงวัตถุ ” ไม่ใช่ Robert Martin

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