มีรูปแบบการจัดการพารามิเตอร์ฟังก์ชันที่ขัดแย้งหรือไม่?

เรามีฟังก์ชัน API ที่แบ่งจำนวนเงินทั้งหมดเป็นจำนวนเงินรายเดือนตามวันที่เริ่มต้นและวันที่สิ้นสุดที่กำหนด

// JavaScript

function convertToMonths(timePeriod) {
  // ... returns the given time period converted to months
}

function getPaymentBreakdown(total, startDate, endDate) {
  const numMonths = convertToMonths(endDate - startDate);

  return {
    numMonths,
    monthlyPayment: total / numMonths,
  };
}

เมื่อเร็ว ๆ นี้ผู้บริโภคสำหรับ API นี้ต้องการระบุช่วงวันที่ด้วยวิธีอื่น: 1) โดยระบุจำนวนเดือนแทนที่จะเป็นวันที่สิ้นสุดหรือ 2) โดยระบุการชำระเงินรายเดือนและการคำนวณวันที่สิ้นสุด เพื่อตอบสนองต่อสิ่งนี้ทีม API ได้เปลี่ยนฟังก์ชั่นดังต่อไปนี้:

// JavaScript

function addMonths(date, numMonths) {
  // ... returns a new date numMonths after date
}

function getPaymentBreakdown(
  total,
  startDate,
  endDate /* optional */,
  numMonths /* optional */,
  monthlyPayment /* optional */,
) {
  let innerNumMonths;

  if (monthlyPayment) {
    innerNumMonths = total / monthlyPayment;
  } else if (numMonths) {
    innerNumMonths = numMonths;
  } else {
    innerNumMonths = convertToMonths(endDate - startDate);
  }

  return {
    numMonths: innerNumMonths,
    monthlyPayment: total / innerNumMonths,
    endDate: addMonths(startDate, innerNumMonths),
  };
}

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

นอกจากนี้ฉันรู้สึกว่ามันเป็นแบบอย่างที่ไม่ดีและเพิ่มความรับผิดชอบให้กับ API ที่ไม่ควรเกี่ยวข้องกับตัวเอง (เช่นการละเมิด SRP) สมมติว่าผู้บริโภคเพิ่มเติมต้องการฟังก์ชั่นเพื่อรองรับกรณีการใช้งานที่มากขึ้นเช่นการคำนวณtotalจากnumMonthsและmonthlyPaymentพารามิเตอร์ ฟังก์ชั่นนี้จะซับซ้อนขึ้นเรื่อย ๆ เมื่อเวลาผ่านไป

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

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

เห็นการใช้งานปรากฏให้ฉันสิ่งที่คุณต้องการจริงๆที่นี่เป็น 3 ฟังก์ชั่นที่แตกต่างกันแทนหนึ่ง:

ฉบับดั้งเดิม:

function getPaymentBreakdown(total, startDate, endDate) 

หนึ่งที่ให้จำนวนเดือนแทนวันที่สิ้นสุด:

function getPaymentBreakdownByNoOfMonths(total, startDate, noOfMonths) 

และอีกหนึ่งรายการที่ให้การชำระเงินรายเดือนและการคำนวณวันที่สิ้นสุด:

function getPaymentBreakdownByMonthlyPayment(total, startDate, monthlyPayment) 

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

โปรดทราบว่าฟังก์ชั่นที่แตกต่างกันไม่ได้หมายความว่าคุณต้องทำซ้ำตรรกะใด ๆ - ภายในถ้าฟังก์ชั่นเหล่านี้ใช้อัลกอริทึมร่วมกันก็ควรได้รับการ refactored เพื่อฟังก์ชั่น "ส่วนตัว"

มีรูปแบบทั่วไปสำหรับจัดการสถานการณ์เช่นนี้หรือไม่

ฉันไม่คิดว่าจะมี "รูปแบบ" (ในแง่ของรูปแบบการออกแบบ GoF) ซึ่งอธิบายการออกแบบ API ที่ดี การใช้ชื่ออธิบายตนเองฟังก์ชั่นที่มีพารามิเตอร์น้อยลงฟังก์ชั่นที่มีพารามิเตอร์ orthogonal (= อิสระ) เป็นเพียงหลักการพื้นฐานของการสร้างรหัสที่อ่านง่ายบำรุงรักษาและพัฒนาได้ ไม่ใช่ทุกความคิดที่ดีในการเขียนโปรแกรมนั้นจำเป็นต้องเป็น "รูปแบบการออกแบบ"

นอกจากนี้ฉันรู้สึกว่ามันเป็นแบบอย่างที่ไม่ดีและเพิ่มความรับผิดชอบให้กับ API ที่ไม่ควรเกี่ยวข้องกับตัวเอง (เช่นการละเมิด SRP) สมมติว่าผู้บริโภคเพิ่มเติมต้องการฟังก์ชั่นเพื่อรองรับกรณีการใช้งานที่มากขึ้นเช่นการคำนวณtotalจากnumMonthsและmonthlyPaymentพารามิเตอร์ ฟังก์ชั่นนี้จะซับซ้อนขึ้นเรื่อย ๆ เมื่อเวลาผ่านไป

คุณพูดถูก

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

วิธีนี้ไม่เหมาะเช่นกันเนื่องจากรหัสผู้โทรจะถูกปนเปื้อนด้วยแผ่นหม้อน้ำที่ไม่เกี่ยวข้อง

อีกวิธีหนึ่งมีรูปแบบทั่วไปสำหรับจัดการสถานการณ์เช่นนี้หรือไม่

DateIntervalแนะนำรูปแบบใหม่เช่น เพิ่มตัวสร้างสิ่งที่เหมาะสม (วันที่เริ่มต้น + วันที่สิ้นสุด, วันที่เริ่มต้น + จำนวนเดือน, อะไรก็ตาม) ใช้สิ่งนี้เป็นประเภทสกุลเงินทั่วไปสำหรับการแสดงช่วงวันที่ / เวลาทั่วทั้งระบบของคุณ

บางครั้งการแสดงออกอย่างคล่องแคล่วช่วยในเรื่องนี้:

let payment1 = forTotalAmount(1234)
                  .breakIntoPayments()
                  .byPeriod(months(2));

let payment2 = forTotalAmount(1234)
                  .breakIntoPayments()
                  .byDateRange(saleStart, saleEnd);

let monthsDue = forTotalAmount(1234)
                  .calculatePeriod()
                  .withPaymentsOf(12.34)
                  .monthly();

ให้เวลาในการออกแบบเพียงพอคุณสามารถสร้าง API ที่เป็นของแข็งซึ่งคล้ายกับภาษาเฉพาะโดเมน

ข้อได้เปรียบที่สำคัญอีกประการหนึ่งคือ IDE ที่มีการเติมข้อความอัตโนมัติทำให้แทบจะไม่เกี่ยวข้องกับการอ่านเอกสาร API เนื่องจากมันใช้งานง่ายเนื่องจากความสามารถในการค้นพบตัวเอง

มีแหล่งข้อมูลอยู่เช่นhttps://nikas.praninskas.com/javascript/2015/04/26/fluent-javascript/หรือhttps://github.com/nikaspran/fluent.jsในหัวข้อนี้

ตัวอย่าง (นำมาจากลิงค์ทรัพยากรแรก):

let insert = (value) => ({into: (array) => ({after: (afterValue) => {
  array.splice(array.indexOf(afterValue) + 1, 0, value);
  return array;
}})});

insert(2).into([1, 3]).after(1); //[1, 2, 3]

ดีในภาษาอื่น ๆ ที่คุณต้องการใช้ชื่อพารามิเตอร์ สิ่งนี้สามารถถูกจำลองใน Javscript:

function getPaymentBreakdown(total, startDate, durationSpec) { ... }

getPaymentBreakdown(100, today, {endDate: whatever});
getPaymentBreakdown(100, today, {noOfMonths: 4});
getPaymentBreakdown(100, today, {monthlyPayment: 20});

นอกจากนี้คุณยังสามารถแบ่งความรับผิดชอบในการระบุจำนวนเดือนและแยกออกจากการทำงานของคุณ:

getPaymentBreakdown(420, numberOfMonths(3))
getPaymentBreakdown(420, dateRage(a, b))
getPaymentBreakdown(420, paymentAmount(350))

และ getpaymentBreakdown จะได้รับวัตถุซึ่งจะให้จำนวนฐานของเดือน

ฟังก์ชั่นการสั่งซื้อที่สูงขึ้นจะส่งคืนเช่นฟังก์ชัน

function numberOfMonths(months) {
  return {months: (total) => months};
}

function dateRange(startDate, endDate) {
  return {months: (total) => convertToMonths(endDate - startDate)}
}

function monthlyPayment(amount) {
  return {months: (total) => total / amount}
}


function getPaymentBreakdown(total, {months}) {
  const numMonths= months(total);
  return {
    numMonths, 
    monthlyPayment: total / numMonths,
    endDate: addMonths(startDate, numMonths)
  };
}

และถ้าคุณกำลังจะทำงานร่วมกับระบบที่มีการเลือกปฏิบัติสหภาพแรงงาน / TimePeriodSpecificationชนิดข้อมูลเกี่ยวกับพีชคณิตคุณสามารถส่งต่อไปในขณะที่การพูด

type TimePeriodSpecification =
    | DateRange of startDate : DateTime * endDate : DateTime
    | MonthCount of startDate : DateTime * monthCount : int
    | MonthlyPayment of startDate : DateTime * monthlyAmount : float

และจากนั้นจะไม่มีปัญหาใด ๆ เกิดขึ้นในกรณีที่คุณไม่สามารถนำไปใช้งานได้จริง