ไหนดีกว่า: กลุ่ม getters หรือ 1 เมธอดที่มีพารามิเตอร์สตริงการเลือก?

โดเมนความรู้ของเราเกี่ยวข้องกับคนที่เดินข้ามแผ่นบันทึกความกดดันด้วยเท้าเปล่า เราทำการจดจำรูปภาพซึ่งส่งผลให้วัตถุของคลาส 'เท้า' หากเท้ามนุษย์ถูกจดจำในข้อมูลเซ็นเซอร์

มีการคำนวณหลายอย่างที่ต้องดำเนินการกับข้อมูลของเท้า

ตอนนี้ API ตัวไหนจะดีกว่า:

class Foot : public RecognizedObject  { 
  MaxPressureFrame getMaxPressureFrame();
  FootAxis getFootAxis();
  AnatomicalZones getAnatomicalZones();

  // + similar getters for other calculations

  // ...
}

หรือ:

class Foot : public RecognizedObject {
  virtual CalculationBase getCalculation(QString aName);

  // ...
}

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

คำแนะนำใด ๆ?

โปรบางตัวสำหรับวิธีแรกอาจเป็น:

• KISS - ทุกอย่างเป็นรูปธรรมมาก API แต่การใช้งานเช่นกัน
• ค่าส่งคืนที่พิมพ์อย่างมาก
• การสืบทอดจากคลาสนี้เป็นสิ่งที่พิสูจน์ได้ ไม่มีสิ่งใดสามารถแทนที่ได้ถูกเพิ่มเข้ามาเท่านั้น
• API ปิดมากไม่มีอะไรเข้าไปไม่มีสิ่งใดถูกแทนที่ได้ดังนั้นจึงน้อยผิดไป

แย้งบางส่วนของ:

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

โปรบางตัวสำหรับแนวทางที่สอง:

• ยืดหยุ่นมากขึ้น
• api มีโอกาสน้อยที่จะเปลี่ยนแปลง (สมมติว่าเราได้นามธรรมถูกต้องถ้าไม่การเปลี่ยนแปลงจะมีค่าใช้จ่ายมากขึ้น)

แย้งบางส่วนของ:

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

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

• จำนวนผู้ได้รับจะเพิ่มขึ้นตามการคำนวณใหม่ทุกครั้งที่เราประดิษฐ์ได้รับเพิ่มในรายการ

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

• API มีแนวโน้มที่จะเปลี่ยนแปลงมากขึ้นและหากมีการแนะนำให้ใช้การเปลี่ยนแปลงแบบแบ่งย่อยเราจำเป็นต้องมี API รุ่นใหม่คือ Foot2

จริง แต่จริง ๆ แล้วเป็นโปรขนาดใหญ่;) คุณสามารถกำหนดอินเทอร์เฟซสำหรับ API บางส่วนและจากนั้นคุณไม่จำเป็นต้องคอมไพล์คลาสที่ต้องพึ่งพาซึ่งไม่ได้รับผลกระทบจาก APIs ที่ใหม่กว่า (ดังนั้นไม่จำเป็นต้องใช้ Foot2) ที่ช่วยให้ decoupling ที่ดีกว่าการพึ่งพาตอนนี้เป็นส่วนต่อประสานและไม่ใช่การนำไปใช้ นอกจากนี้หากอินเทอร์เฟซที่มีอยู่มีการเปลี่ยนแปลงคุณจะมีข้อผิดพลาดในการคอมไพล์ในคลาสที่ขึ้นต่อกันซึ่งยอดเยี่ยมในการป้องกันโค้ดเก่า

• ในกรณีที่นำคลาสกลับมาใช้ใหม่ในโครงการอื่นเราอาจไม่ต้องการการคำนวณทุกครั้ง

ฉันไม่เห็นว่าการใช้สายเวทหรือ enums จะช่วยได้อย่างไรถ้าฉันเข้าใจอย่างถูกต้องคุณอาจรวมรหัสในคลาส Foot หรือคุณแบ่งมันเป็นคลาสย่อย ๆ สองสามตัว

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

class Foot : public RecognizedObject {
public:
    // Rather low-level API to access all characteristics that might be needed by a calculation
};

class MaxPressureFrame {
public:
    MaxPressureFrame(const Foot& aFoot); // Performs the calculation based on the information in aFoot
    //API for accessing the results of the calculation
};

// Similar classes for other calculations

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