ฟังก์ชันตัวตรวจสอบค่าของฉันต้องส่งคืนทั้งบูลีนและข้อความ

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

หากเป็นรูปแบบที่ถูกต้องจะต้องส่งคืนจริง

หากไม่ใช่รูปแบบที่ถูกต้องจะต้องส่งคืนค่าเท็จและแจ้งให้เราทราบว่ามีอะไรผิดปกติกับมูลค่า

คำถามคือวิธีที่ดีที่สุดในการบรรลุเป้าหมายนี้คืออะไร

นี่คือวิธีแก้ปัญหาบางประการ:

1. ใช้รหัสส่งคืนจำนวนเต็ม / enum เพื่อแสดงความหมาย:

String[] returnCodeLookup = 
[
"Value contains wrong number of characters, should contain 10 characters",
"Value should end with 1", 
"Value should be a multiple of 3"
]

private int valueChecker(String value)
{
    /*check value*/
    return returnCode;
}

rc = checkValue(valueToBeChecked);
if rc == 0
{
    /*continue as normal*/
}
else
{
    print("Invalid value format: ") + returnCodeLookup[rc];
}

ฉันไม่ชอบวิธีแก้ปัญหานี้เพราะมันต้องมีการติดตั้งในส่วนของผู้โทร

2. สร้างคลาส returnCode

Class ReturnCode()
{
    private boolean success;
    private String message;

    public boolean getSuccess()
    {
        return this.success;
    }

    public String getMessage()
    {
        return this.message; 
    }
}

private ReturnCode valueChecker(String value)
{
    /*check value*/
    return returnCode;
}

rc = checkValue(valueToBeChecked);
if rc.getSuccess()
{
    /*continue as normal*/
}
else
{
    print("Invalid value format: ") + rc.getMessage();
}

วิธีนี้เป็นระเบียบเรียบร้อย แต่ดูเหมือนว่า overkill / reinventing ล้อ

3. ใช้ข้อยกเว้น

private boolean valueChecker(String value)
{
    if int(value)%3 != 0 throw InvalidFormatException("Value should be a multiple of 3";
    /*etc*/
    return True;
}

try {
rc = checkValue(valueToBeChecked);
}

catch (InvalidFormatException e)
{
     print e.toString();
}

ฉันถูกล่อลวงให้ใช้โซลูชันนี้ แต่ฉันบอกว่าคุณไม่ควรใช้ข้อยกเว้นสำหรับตรรกะทางธุรกิจ

ใช้วัตถุส่งคืนที่ซับซ้อนมากขึ้นซึ่งสรุปทั้งข้อกังวล ตัวอย่าง:

public interface IValidationResult {
  boolean isSuccess();
  String getMessage();
}

นี่มีข้อดีหลายประการ:

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

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

ไม่มีข้อใดข้างต้นใช้คลาส ValueChecker

ก่อนอื่นให้ส่วนต่อประสานที่ให้ความยืดหยุ่นแก่คุณ:

public interface IValueChecker {
    public boolean checkValue(String value);
    public String getLastMessage();
}

จากนั้นปรับใช้ตัวตรวจสอบค่าให้มากที่สุดเท่าที่คุณต้องการ:

public class MyVeryEspecificValueChecker implements IValueChecker {
    private String lastMessage="";
    @Override
    public boolean checkValue(String value) {
        boolean valid=false;
        // perform check, updates "valid" and "lastMessage"
        return valid;
    }
    @Override
    public String getLastMessage() {
        return lastMessage;
    }
}

ตัวอย่างรหัสลูกค้า:

public class TestValueChecker {
    public static void main(String[] args) {
        String valueToCheck="213123-YUYAS-27163-10";
        IValueChecker vc = new MyVeryEspecificValueChecker();
        vc.checkValue(valueToCheck);
        System.out.println(vc.getLastMessage());
    }
}

มันมีข้อดีที่คุณสามารถมีตัวตรวจสอบค่าที่แตกต่างกันมากมาย

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

interface Action
{
    /**
     * @param Request $request
     * @throws RuntimeException
     * @return Response
     */
    public function act(Request $request);
}

การสร้างโอเปอเรเตอร์สวิตช์ที่ทำหน้าที่เหมือนนิพจน์ไม่เหมือนคำสั่งจะนำไปสู่บริการแอปพลิเคชันที่มีลักษณะดังนี้:

class MyApplicationService implements Action
{
    private $dataStorage;

    public function __construct(UserDataStorage $dataStorage)
    {
        $this->dataStorage = $dataStorage;
    }

    public function act(Request $request)
    {
        return
            (new _SwitchTrue(
                new _Case(
                    new EmailIsInvalid(),
                    new EmailIsInvalidResponse()
                ),
                new _Case(
                    new PasswordIsInvalid(),
                    new PasswordIsInvalidResponse()
                ),
                new _Case(
                    new EmailAlreadyRegistered($this->dataStorage),
                    new EmailAlreadyRegisteredResponse()
                ),
                new _Default(
                    new class implements Action
                    {
                        public function act(Request $request)
                        {
                            // business logic goes here

                            return new UserRegisteredResponse();
                        }
                    }
                )
            ))
                ->act($request)
            ;
    }
}