คำถามติดแท็ก abstract-class

ฉันมีชั้นเรียนพร้อมฟังก์ชั่นเริ่มต้น / แชร์ ฉันใช้abstract classมัน public interface ITypeNameMapper { string Map(TypeDefinition typeDefinition); } public abstract class TypeNameMapper : ITypeNameMapper { public virtual string Map(TypeDefinition typeDefinition) { if (typeDefinition is ClassDefinition classDefinition) { return Map(classDefinition); } ... throw new ArgumentOutOfRangeException(nameof(typeDefinition)); } protected abstract string Map(ClassDefinition classDefinition); } ITypeNameMapperที่คุณสามารถดูฉันยังมีอินเตอร์เฟซ มันเหมาะสมหรือไม่ที่จะกำหนดอินเทอร์เฟซนี้ถ้าฉันมีคลาสนามธรรมTypeNameMapperหรือabstract classเพียงพอหรือไม่? TypeDefinition …

12 c#  interfaces  abstract-class 

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

12 c#  abstract-class 

เมื่อเร็ว ๆ นี้ฉันมีปัญหาเกี่ยวกับการใช้คลาสที่เป็นนามธรรม บางครั้งคลาสนามธรรมจะถูกสร้างขึ้นล่วงหน้าและทำงานเป็นแม่แบบของวิธีการเรียนที่ได้รับจะทำงาน ซึ่งหมายความว่ามากหรือน้อยที่พวกเขามีฟังก์ชั่นระดับสูงบางอย่าง แต่ออกรายละเอียดบางอย่างที่จะดำเนินการโดยชั้นเรียนที่ได้รับ ชั้นนามธรรมกำหนดความต้องการรายละเอียดเหล่านี้โดยการวางวิธีการบางอย่างที่เป็นนามธรรม ในกรณีเช่นนี้คลาสนามธรรมจะทำงานเหมือนกับพิมพ์เขียวคำอธิบายระดับสูงของฟังก์ชันหรือสิ่งที่คุณต้องการเรียกใช้ ไม่สามารถใช้ด้วยตนเองได้ แต่ต้องมีความเชี่ยวชาญในการกำหนดรายละเอียดที่ถูกทิ้งไว้จากการใช้งานระดับสูง บางครั้งมันเกิดขึ้นที่คลาสนามธรรมถูกสร้างขึ้นหลังจากการสร้างคลาส "ที่ได้รับ" บางส่วน (เนื่องจากคลาสแม่ / นามธรรมไม่ได้อยู่ที่นั่นพวกเขายังไม่ได้รับมา แต่คุณรู้ว่าฉันหมายถึงอะไร) ในกรณีเหล่านี้คลาสนามธรรมมักจะใช้เป็นสถานที่ที่คุณสามารถใส่รหัสทั่วไปใด ๆ ที่คลาสที่ได้รับปัจจุบันมี หลังจากทำการสังเกตข้างต้นฉันสงสัยว่าในสองกรณีนี้ควรเป็นกฎ รายละเอียดใด ๆ ที่ควรจะถูกทำให้กระฉับกระเฉงขึ้นไปสู่ชั้นนามธรรมเพียงเพราะพวกเขากำลังเกิดขึ้นเป็นเรื่องธรรมดาในทุกชั้นเรียนที่ได้รับ? ควรใช้รหัสทั่วไปที่ไม่ได้เป็นส่วนหนึ่งของฟังก์ชั่นระดับสูงหรือไม่? รหัสที่อาจไม่มีความหมายสำหรับคลาสนามธรรมควรมีเพียงเพราะมันเกิดขึ้นเป็นเรื่องธรรมดาสำหรับคลาสที่ได้รับ? ขอยกตัวอย่าง: คลาสนามธรรม A มีเมธอด a () และเมธอด abstract aq () เมธอด aq () ทั้งคลาสที่ได้รับ AB และ AC ใช้เมธอด b () ควรย้าย b () ไปที่ …

10 object-oriented  clean-code  abstract-class 

ฉันกำลังเขียนโค้ดด้วยรูปแบบสถานะสำหรับอุปกรณ์ฝังตัว ฉันมีคลาสฐาน / นามธรรมที่เรียกว่าสถานะและจากนั้นแต่ละสถานะแยก (คอนกรีต) แยกชั้นใช้ระดับรัฐนามธรรม ในระดับรัฐฉันมีวิธีนามธรรมหลายอย่าง ถ้าฉันไม่ใช้วิธีนามธรรมในคลาส discrete (คอนกรีต), Visual Studio จะให้ข้อผิดพลาดดังนี้: ... ข้อผิดพลาด 1 'myConcreteState' ไม่ได้ใช้สมาชิกนามธรรมที่สืบทอด 'myAbstractState' ตอนนี้: ฉันกำลังพยายามสร้างคุณสมบัติสตริงสำหรับแต่ละรัฐชื่อ StateName เมื่อใดก็ตามที่ฉันสร้างคลาสคอนกรีตใหม่ฉันต้องกำหนด StateName ฉันต้องการให้ VS ส่งข้อผิดพลาดหากฉันไม่ได้ใช้ มีวิธีง่าย ๆ ในการทำเช่นนี้? ฉันได้ลองในชั้นนามธรรม / ฐาน: public abstract string StateName { get; set; } แต่ฉันไม่จำเป็นต้องใช้วิธีการรับและตั้งค่าในแต่ละรัฐ คำถามที่มีการแก้ไข: ในสถานการณ์ที่เหมาะสมอุดมคติแต่ละระดับของรัฐจะต้องกำหนดให้ StateName กำหนดและสืบทอดมาจากคลาสฐานนามธรรม StateName = "MyState1"; //or …

10 c#  design-patterns  visual-studio  abstract-class 

บ่อยครั้งที่เป็นความคิดที่ดีที่จะมีคลาสฐานนามธรรมเพื่อแยกอินเทอร์เฟซของวัตถุ ปัญหาคือการสร้างการคัดลอก IMHO นั้นค่อนข้างเสียหายโดยค่าเริ่มต้นใน C ++ โดยที่ตัวสร้างสำเนาจะถูกสร้างขึ้นตามค่าเริ่มต้น ดังนั้น gotchas คืออะไรเมื่อคุณมีคลาสฐานนามธรรมและพอยน์เตอร์ดิบในคลาสที่ได้รับ class IAbstract { ~IAbstract() = 0; } class Derived : public IAbstract { char *theProblem; ... } IAbstract *a1 = new Derived(); IAbstract a2 = *a1;//??? และตอนนี้คุณปิดการใช้งานการคัดลอกอย่างหมดจดสำหรับลำดับชั้นทั้งหมดหรือไม่ ประกาศคัดลอกการก่อสร้างเป็นส่วนตัวIAbstractหรือไม่ มีกฎสามข้อในคลาสฐานนามธรรมหรือไม่?

10 c++  abstract-class 

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

9 programming-languages  object-oriented  interfaces  abstract-class