ดีกว่าที่จะมี 2 วิธีด้วยความหมายที่ชัดเจนหรือเพียง 1 วิธีใช้คู่?

หากต้องการทำให้อินเทอร์เฟซง่ายขึ้นจะดีกว่าgetBalance()ไหมที่ไม่มีวิธี? การส่งผ่าน0ไปยังcharge(float c);จะให้ผลลัพธ์เดียวกัน:

public class Client {
    private float bal;
    float getBalance() { return bal; }
    float charge(float c) {
        bal -= c;
        return bal;
    }
}

อาจจดบันทึกในjavadoc? หรือเพียงแค่ปล่อยให้ผู้ใช้ระดับชั้นเรียนรู้วิธีการรับยอดคงเหลือ

ดูเหมือนว่าคุณจะแนะนำว่าความซับซ้อนของอินเทอร์เฟซนั้นวัดจากจำนวนองค์ประกอบที่มี (วิธีการในกรณีนี้) หลายคนอาจแย้งว่าต้องจำไว้ว่าchargeวิธีการนี้สามารถใช้เพื่อคืนสมดุลของการClientเพิ่มความซับซ้อนมากกว่าการมีองค์ประกอบพิเศษของgetBalanceวิธีการ การทำให้สิ่งต่าง ๆ ชัดเจนยิ่งขึ้นง่ายขึ้นโดยเฉพาะอย่างยิ่งจนถึงจุดที่ไม่มีความคลุมเครือไม่ว่าองค์ประกอบในอินเทอร์เฟซจะสูงขึ้นเท่าใด

นอกจากนี้การเรียกcharge(0)ละเมิดหลักการที่น่าประหลาดใจน้อยที่สุดหรือที่รู้จักกันในชื่อWTFs ต่อนาที (จาก Clean Code, ภาพด้านล่าง) ทำให้ยากสำหรับสมาชิกใหม่ของทีม พวกเขาเข้าใจว่าการโทรนั้นใช้เพื่อให้เกิดความสมดุล คิดว่าผู้อ่านคนอื่นจะตอบสนองอย่างไร:

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

โดยสรุปฉันเชื่อว่าอินเทอร์เฟซที่ง่ายที่สุดในกรณีนี้คือ:

public class Client {
  private float bal;
  float getBalance() { return bal; }
  void charge(float c) { bal -= c; }
}

IMO การแทนที่getBalance()ด้วยcharge(0)แอปพลิเคชันของคุณไม่ใช่การทำให้เป็นเรื่องง่าย ใช่มันเป็นเส้นที่น้อยกว่า แต่มันทำให้เสียความหมายของcharge()วิธีการซึ่งอาจทำให้ปวดหัวลงเมื่อคุณหรือคนอื่นจำเป็นต้องทบทวนรหัสนี้อีกครั้ง

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

สิ่งสำคัญคือต้องจำไว้ว่ารหัสของคุณควรเป็นเอกสารด้วยตนเอง เมื่อฉันโทรcharge(x)ฉันคาดว่าxจะถูกเรียกเก็บเงิน ข้อมูลเกี่ยวกับความสมดุลเป็นเรื่องรอง ยิ่งไปกว่านั้นฉันอาจไม่รู้ว่าcharge()จะมีการใช้งานอย่างไรเมื่อฉันเรียกใช้และฉันจะไม่ทราบว่าจะนำไปใช้ในวันพรุ่งนี้ได้อย่างไร ตัวอย่างเช่นให้พิจารณาการอัปเดตในอนาคตที่อาจเกิดขึ้นนี้เป็นcharge():

float charge(float c) {
    lockDownUserAccountUntilChargeClears();
    bal -= c;
    Unlock();
    return bal;
}

ทันทีที่ใช้charge()เพื่อให้ได้สมดุลนั้นดูไม่ดีนัก

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

if (c > 0) {
    // make and log charge
}
return bal;

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

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

ฉันรู้ว่ามีคำตอบมากมาย แต่อีกเหตุผลหนึ่งcharge(0)คือการพิมพ์ผิดง่าย ๆcharge(9)จะทำให้ยอดเงินของลูกค้าลดลงทุกครั้งที่คุณต้องการรับยอดเงินของพวกเขา หากคุณมีการทดสอบหน่วยที่ดีคุณอาจสามารถลดความเสี่ยงดังกล่าวได้ แต่ถ้าคุณล้มเหลวในการขยันในทุกการโทรchargeคุณอาจได้รับอุบัติเหตุนี้

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

ในกรณีดังกล่าวการทำให้งานการเขียนแต่ละครั้งง่ายขึ้นมีค่ามากกว่าความชัดเจนของการใช้งานเพราะในอดีตหลีกเลี่ยงข้อผิดพลาดการละเมิดสัญญา กู้คืนโดยฟังก์ชั่นผู้ช่วยหรือวิธี superclass กำหนดในแง่ของgetBalancecharge

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

หากไม่ใช่กรณีนี้ (มีการใช้งานไม่กี่อย่างหรืออย่างใดอย่างหนึ่ง) จากนั้นแยกวิธีการเพื่อความชัดเจนและเพื่อให้สามารถเพิ่มพฤติกรรมที่เกี่ยวข้องกับการเรียกเก็บเงินที่ไม่ใช่ศูนย์charge()ได้อย่างง่ายดาย