ไม่ทำให้สมาชิกสาธารณะเสมือนหรือเป็นนามธรรม - จริงเหรอ?

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

ตัวอย่างเช่นเขาถือว่าคลาสเช่นนี้ไม่ได้ออกแบบมาอย่างดี:

public abstract class PublicAbstractOrVirtual
{
  public abstract void Method1(string argument);

  public virtual void Method2(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    // default implementation
  }
}

เขากล่าวว่า

• นักพัฒนาของคลาสที่ได้รับที่ใช้Method1และการแทนที่Method2มีการทำซ้ำการตรวจสอบอาร์กิวเมนต์
• ในกรณีที่ผู้พัฒนาคลาสพื้นฐานตัดสินใจที่จะเพิ่มบางสิ่งรอบ ๆ ส่วนที่กำหนดเองได้Method1หรือMethod2ใหม่กว่าเขาจะไม่สามารถทำได้

เพื่อนร่วมงานของฉันเสนอวิธีการนี้แทน:

public abstract class ProtectedAbstractOrVirtual
{
  public void Method1(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    this.Method1Core(argument);
  }

  public void Method2(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    this.Method2Core(argument);
  }

  protected abstract void Method1Core(string argument);

  protected virtual void Method2Core(string argument)
  {
    // default implementation
  }
}

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

แต่ฉันไม่เห็นว่านี่เป็นแนวทางการออกแบบ แม้แต่ Microsoft ก็ไม่ทำตามมันแค่ดูที่Streamคลาสเพื่อตรวจสอบสิ่งนี้

คุณคิดอย่างไรกับแนวทางนี้ มันสมเหตุสมผลหรือไม่หรือคุณคิดว่ามันซับซ้อนเกินไป API?

คำพูด

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

กำลังผสมสาเหตุและผลกระทบ มันทำให้สมมติฐานที่ว่าทุกวิธีการ overrideable ต้องมีการตรวจสอบอาร์กิวเมนต์ที่ไม่สามารถปรับแต่งได้ แต่มันค่อนข้างเป็นไปในทางตรงกันข้าม:

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

แต่มีจำนวนมากตัวอย่างที่มันทำให้รู้สึกดีที่จะมีวิธีการที่ประชาชนเสมือนเนื่องจากไม่มีคงไม่ใช่การปรับแต่งส่วน: ดูที่วิธีการมาตรฐานเหมือนToStringหรือEqualsหรือGetHashCode- มันจะปรับปรุงการออกแบบของobjectระดับที่จะมีเหล่านี้ไม่ได้เป็นของประชาชนและ เสมือนจริงในเวลาเดียวกัน? ฉันไม่คิดอย่างนั้น

หรือในแง่ของรหัสของคุณเอง: เมื่อรหัสในคลาสฐานสุดท้ายและจงใจมีลักษณะเช่นนี้

 public void Method1(string argument)
 {
    // nothing to validate here, all strings including null allowed
    this.Method1Core(argument);
 }

มีการแยกระหว่างนี้Method1และMethod1Coreสิ่งที่ซับซ้อนเท่านั้นโดยไม่มีเหตุผลชัดเจน

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

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

หลักการตั้งชื่อเพื่อนำไปใช้ (ที่ฉันรู้) คือการสงวนชื่อที่ดีสำหรับส่วนต่อประสานสาธารณะและเพื่อนำหน้าชื่อวิธีการภายในด้วย "ทำ"

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

ใน C ++ สิ่งนี้เรียกว่าnon-virtual interface pattern (NVI) (กาลครั้งหนึ่งนานมานี้เรียกว่าวิธีเทมเพลตซึ่งทำให้สับสน แต่บทความเก่า ๆ บางฉบับมีคำศัพท์นั้น) NVI ได้รับการส่งเสริมโดย Herb Sutter ผู้เขียนเกี่ยวกับเรื่องนี้อย่างน้อยสองสามครั้ง ผมคิดว่าคนแรกคือที่นี่

ถ้าผมจำได้อย่างถูกต้องหลักฐานเป็นที่เรียนมาไม่ควรเปลี่ยนสิ่งที่ชั้นฐานไม่ แต่วิธีการมันไม่ได้

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

ในตัวอย่างง่ายๆสิ่งนี้มักทำให้เดือดร้อนจากการย้ายสาธารณะที่เพิ่งมอบหมายงานทั้งหมดให้กับ ReallyDoTheMove เสมือนส่วนตัวดังนั้นดูเหมือนว่าจะไม่มีค่าใช้จ่ายมากนัก

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

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

ฉันไม่ทราบถึงความแตกต่างระหว่าง C # และ C ++ ที่จะเปลี่ยนมุมมองของการออกแบบคลาสนี้