คลาสสแตติกที่มีเมธอดสแตติกพิจารณาว่าเป็น SOLID หรือไม่

SOLIDรวมถึงการแทนที่ Liskov ซึ่งมีความเห็นว่า "วัตถุในโปรแกรมควรเปลี่ยนได้ด้วยอินสแตนซ์ของชนิดย่อยโดยไม่เปลี่ยนแปลงความถูกต้องของโปรแกรมนั้น"

เนื่องจากคลาสแบบสแตติกที่มีเมธอดแบบสแตติก (บิตเช่นMathคลาส) ไม่มีอินสแตนซ์เลยระบบของฉันจะถือว่าเป็นแบบ SOLID หรือไม่ถ้าฉันมีคลาสแบบสแตติกที่มีวิธีแบบสแตติก

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

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

คุณสามารถพูดได้ว่าคลาสสแตติกมักเป็นไปตาม LSP เนื่องจากคุณไม่สามารถสร้างคลาสย่อยที่จะละเมิดหลักการนั้นได้ คุณสามารถพูดได้ว่าคลาสสแตติกไม่เคยเป็นไปตาม LSP ด้วยเหตุผลเดียวกัน

---

ใน Java คลาสสแตติกจะแตกต่างกันเล็กน้อย คุณไม่สามารถทำเครื่องหมายคลาสระดับบนสุดว่า "คงที่" ดังนั้นหากคุณต้องการสร้างคลาสยูทิลิตี้ที่คล้ายกับคลาสแบบคงที่ของ C # คุณจะต้องประกาศเป็นfinalและซ่อนคอนสตรัคเตอร์ เมื่อคุณทำเช่นนั้นแล้วพวกเขาจะทำงานคล้ายกับ C # - คุณไม่สามารถสร้างอินสแตนซ์หรือซับคลาสเหล่านั้นได้ คุณสามารถประกาศระดับชั้นเป็นstaticแต่ไม่ได้หมายความว่าสิ่งเดียวกันเช่นเดียวกับใน C #: มันก็หมายถึงชั้นบนระดับที่ซ้อนกัน

VB.NET ทำงานในลักษณะเดียวกันกับ C # ในกรณีนี้เท่าที่ฉันรู้

---

คุณไม่ได้พูดถึงว่าคุณสนใจในหลักการอื่น ๆ หรือไม่ แต่ฉันจะรวมไว้เพื่อความสมบูรณ์

Sแหล่งไฟหลักการความรับผิดชอบ : ระดับคงที่ได้อย่างง่ายดายตามหลักการนี้
Oปากกา / หลักการปิด : ตั้งแต่เรียนคงถูกปิดผนึกพวกเขาไม่สามารถที่เคยปฏิบัติตามหลักการนี้ หลักการชดเชย
L iskov : ดังกล่าวข้างต้น
ฉันแยกหลักการ nterface : ใช้ไม่ได้กับคลาสเดียว แต่การแบ่งคลาสแบบคงที่ขนาดใหญ่เป็นคลาสที่เล็กกว่าและมีความเชี่ยวชาญมากกว่าอาจเป็นขั้นตอนต่อไปในการปฏิบัติตามหลักการนี้ หลักการผกผัน
D ependency : คลาสสแตติกไม่สามารถใช้อินเทอร์เฟซได้ดังนั้นคลาสใดก็ตามที่ใช้คลาสนั้นจะขึ้นอยู่กับการใช้งานที่มีอยู่ในขณะนั้น คลาสแบบคงที่จึงละเมิดหลักการนี้

เนื่องจากคลาสสแตติกไม่เป็นไปตามเกณฑ์ทั้ง 5 จึงไม่มีโซลิด

ฉันจะไม่จำแนกคลาสเช่นนี้เป็น object-orientated ดังนั้นฉันจะบอกว่ามันไม่สามารถ (และไม่ควรพยายาม) ตรงตามหลักการของการออกแบบ object-orientated

คลาสเหล่านี้เป็นเพียงวิธีการแก้ปัญหาที่ไม่สามารถให้รหัสนอกคลาสในภาษาเช่น Java และ C # หากเป็นไปได้ควรกำหนดให้เป็นฟังก์ชันแบบสแตนด์อโลนเนื่องจากไม่ได้รับประโยชน์ใด ๆ จากการวางแนววัตถุ

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