“ การหลีกเลี่ยงปัญหาโยโย่” เป็นเหตุผลที่ถูกต้องหรือไม่ที่จะยอมให้

ตามที่ครอบงำจิตใจดั้งเดิมคือเมื่อไม่ได้กลิ่นรหัส? ฉันควรสร้างวัตถุ ZipCode เพื่อแสดงรหัสไปรษณีย์แทนวัตถุ String

อย่างไรก็ตามจากประสบการณ์ของฉันฉันชอบดู

public class Address{
    public String zipCode;
}

แทน

public class Address{
    public ZipCode zipCode;
}

เพราะฉันคิดว่าอันหลังต้องการให้ฉันย้ายไปที่คลาส ZipCode เพื่อทำความเข้าใจกับโปรแกรม

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

ดังนั้นฉันต้องการย้ายวิธีการ ZipCode เป็นคลาสใหม่ตัวอย่างเช่น:

เก่า:

public class ZipCode{
    public boolean validate(String zipCode){
    }
}

ใหม่:

public class ZipCodeHelper{
    public static boolean validate(String zipCode){
    }
}

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

คำถามของฉันคือ "การหลีกเลี่ยงปัญหา yo-yo" (ย้ายระหว่างคำจำกัดความของชั้นเรียน) เหตุผลที่ถูกต้องเพื่อให้ "ครอบงำจิตใจดั้งเดิม"?

สมมติฐานคือคุณไม่จำเป็นต้องใช้ yo-yo กับคลาส ZipCode เพื่อทำความเข้าใจกับคลาส Address หาก ZipCode ได้รับการออกแบบมาอย่างดีควรเห็นได้ชัดว่าทำอะไรได้บ้างโดยการอ่านคลาสที่อยู่

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

ตัวอย่างเช่นฉันแน่ใจว่าคุณไม่ต้องการอ่านซอร์สโค้ดของ String ทุกครั้งที่คุณพบสตริงในโค้ด

การเปลี่ยนชื่อคลาสจาก ZipCode เป็น ZipCodeHelper แนะนำว่าตอนนี้มีสองแนวคิดแยกกัน: รหัสไปรษณีย์และตัวช่วยรหัสไปรษณีย์ ซับซ้อนเป็นสองเท่า และตอนนี้ระบบประเภทไม่สามารถช่วยคุณแยกแยะความแตกต่างระหว่างสตริงที่กำหนดเองและรหัสไปรษณีย์ที่ถูกต้องเนื่องจากมีประเภทเดียวกัน นี่คือที่ "ความหลงใหล" มีความเหมาะสม: คุณแนะนำทางเลือกที่ซับซ้อนและปลอดภัยน้อยลงเพียงเพราะคุณต้องการหลีกเลี่ยงกระดาษห่อหุ้มรอบ ๆ แบบดั้งเดิม

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

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

ถ้าสามารถทำได้:

new ZipCode("totally invalid zip code");

และตัวสร้างสำหรับ ZipCode ไม่:

ZipCodeHelper.validate("totally invalid zip code");

จากนั้นคุณได้แยกไฟล์แคปซูเลชันและเพิ่มการพึ่งพาคลาส ZipCode หากนวกรรมิกไม่เรียกZipCodeHelper.validate(...)คุณจะต้องแยกตรรกะในเกาะของตัวเองโดยไม่บังคับใช้จริง คุณสามารถสร้างรหัสไปรษณีย์ที่ไม่ถูกต้อง

validateวิธีการที่ควรจะเป็นวิธีการที่คงอยู่ในระดับรหัสไปรษณีย์ ตอนนี้ความรู้เกี่ยวกับรหัสไปรษณีย์ที่ "ถูกต้อง" นั้นมาพร้อมกับคลาส ZipCode เนื่องจากตัวอย่างโค้ดของคุณดูเหมือน Java ตัวสร้างของ ZipCode ควรมีข้อยกเว้นหากมีการกำหนดรูปแบบที่ไม่ถูกต้อง:

public class ZipCode {
    private String zipCode;

    public ZipCode(string zipCode) {
        if (!validate(zipCode))
            throw new IllegalFormatException("Invalid zip code");

        this.zipCode = zipCode;
    }

    public static bool validate(String zipCode) {
        // logic to check format
    }

    @Override
    public String toString() {
        return zipCode;
    }
}

คอนสตรัคเตอร์ตรวจสอบรูปแบบและส่งข้อยกเว้นจึงป้องกันไม่ให้สร้างรหัสไปรษณีย์ที่ไม่ถูกต้องและvalidateวิธีการแบบคงที่มีให้รหัสอื่น ๆ เพื่อให้ตรรกะของการตรวจสอบรูปแบบถูกห่อหุ้มในคลาส ZipCode

ไม่มี "yo-yo" ในตัวแปรนี้ของคลาส ZipCode มันเรียกว่าการเขียนโปรแกรมเชิงวัตถุที่เหมาะสม

เราจะไม่สนใจความเป็นสากลที่นี่ซึ่งอาจทำให้คลาสอื่นเรียกว่า ZipCodeFormat หรือ PostalService (เช่น PostalService.isValidPostalCode (... ), PostalService.parsePostalCode (... ) ฯลฯ )

หากคุณต่อสู้กับคำถามนี้มากบางทีภาษาที่คุณใช้ไม่ใช่เครื่องมือที่เหมาะสมสำหรับงาน "ดั้งเดิมที่พิมพ์โดเมน" ประเภทนี้ง่ายต่อการแสดงตัวอย่างเช่น F #

เช่นคุณสามารถเขียน:

type ZipCode = ZipCode of string
type Town = Town of string

type Adress = {
  zipCode: ZipCode
  town: Town
  //etc
}

let adress1 = {
  zipCode = ZipCode "90210"
  town = Town "Beverly Hills"
}

let faultyAdress = {
  zipCode = "12345"  // <-Compiler error
  town = adress1.zipCode // <- Compiler error
}

สิ่งนี้มีประโยชน์มากสำหรับการหลีกเลี่ยงข้อผิดพลาดทั่วไปเช่นการเปรียบเทียบ id ของเอนทิตีต่าง ๆ และเนื่องจากการพิมพ์ดั้งเดิมเหล่านี้มีน้ำหนักเบากว่า C # หรือ Java-class มากคุณจึงจะใช้มันได้จริง

คำตอบนั้นขึ้นอยู่กับสิ่งที่คุณต้องการทำกับรหัสไปรษณีย์ นี่คือความเป็นไปได้สองอย่าง:

(1) ที่อยู่ทั้งหมดรับประกันว่าจะอยู่ในประเทศเดียว ไม่มีข้อยกเว้นเลย (เช่นไม่มีลูกค้าต่างประเทศหรือไม่มีพนักงานที่มีที่อยู่ส่วนตัวในต่างประเทศในขณะที่ทำงานให้กับลูกค้าต่างประเทศ) ประเทศนี้มีรหัสไปรษณีย์และพวกเขาสามารถคาดหวังว่าจะไม่เกิดปัญหาร้ายแรง (เช่นไม่ต้องป้อนข้อมูลแบบฟรี) เช่น "ปัจจุบัน D4B 6N2 แต่การเปลี่ยนแปลงนี้จะเกิดขึ้นทุก 2 สัปดาห์") รหัสไปรษณีย์ไม่ได้ใช้เพื่อการระบุที่อยู่เท่านั้น แต่ยังใช้เพื่อตรวจสอบความถูกต้องของข้อมูลการชำระเงินหรือวัตถุประสงค์อื่น ๆ - ภายใต้สถานการณ์เหล่านี้คลาสรหัสไปรษณีย์เหมาะสมเป็นอย่างยิ่ง

(2) ที่อยู่สามารถอยู่ในเกือบทุกประเทศดังนั้นรูปแบบการกำหนดที่อยู่หลายสิบหรือหลายร้อยแบบโดยมีหรือไม่มีรหัสไปรษณีย์ (และมีข้อยกเว้นแปลก ๆ และกรณีพิเศษหลายพันรายการ) จึงมีความเกี่ยวข้อง รหัส "ZIP" จะถูกถามเพื่อเตือนผู้คนจากประเทศที่ใช้รหัสไปรษณีย์ไม่ให้ลืมเท่านั้น ที่อยู่จะถูกใช้เพื่อที่ว่าถ้าใครบางคนสูญเสียการเข้าถึงบัญชีของพวกเขาและพวกเขาสามารถพิสูจน์ชื่อและที่อยู่ของพวกเขาการเข้าถึงจะถูกกู้คืน - ภายใต้สถานการณ์เหล่านี้คลาสรหัสไปรษณีย์สำหรับประเทศที่เกี่ยวข้องทั้งหมดจะเป็นความพยายามอย่างมาก โชคดีที่พวกเขาไม่ต้องการเลย

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

ฉันไม่เห็นด้วยโดยเฉพาะตัวอย่างรหัสที่คุณโพสต์

แต่ฉันก็สงสัยเช่นกันว่าจริง ๆ แล้วตอบคำถามของคุณหรือไม่

พิจารณาสถานการณ์ต่อไปนี้ (ดึงมาจากโครงการจริงที่ฉันกำลังทำอยู่):

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

ในสถานการณ์นี้การทำอะไรมากไปกว่าการตรวจสอบความถูกต้องของการแทรกด้วยข้อ จำกัด SQL regex (หรือเทียบเท่า ORM ของมัน) น่าจะเกินความจริงของความหลากหลายของ YAGNI

สิ่งที่ZipCodeเป็นนามธรรมสามารถเข้าท่าได้ก็ต่อเมื่อAddressชั้นเรียนของคุณไม่มีTownNameทรัพย์สิน มิฉะนั้นคุณมีสิ่งที่เป็นนามธรรมครึ่งหนึ่ง: รหัสไปรษณีย์เป็นตัวกำหนดเมือง แต่ข้อมูลที่เกี่ยวข้องสองส่วนนี้พบได้ในคลาสที่ต่างกัน มันไม่สมเหตุสมผลเลย

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

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

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

นี่คือวิธีที่คุณรู้ว่าคุณไม่จำเป็นต้องแบ่งย่อยใด ๆ เพิ่มเติม: การทำลายมันลงไปอีกจะทำให้เสียสมาธิจากการตั้งใจทำงานของAddressชั้นเรียน ในทำนองเดียวกันคุณไม่จำเป็นต้องใช้Nameคลาสย่อยในPersonชั้นเรียนเว้นแต่Name(ไม่มีบุคคลที่แนบมา) เป็นแนวคิดที่มีความหมายในโดเมนของคุณ ซึ่งมัน (ปกติ) ไม่ใช่ ชื่อนี้ใช้สำหรับระบุตัวบุคคลโดยปกติแล้วพวกเขาจะไม่มีค่าด้วยตนเอง

จากบทความ:

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

ซอร์สโค้ดถูกอ่านบ่อยกว่าที่เขียน ดังนั้นปัญหาของ yo-yo ที่ต้องสลับไปมาระหว่างหลาย ๆ ไฟล์เป็นเรื่องที่น่ากังวล

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

อย่างไรก็ตาม - ใช่การหลีกเลี่ยงเลเยอร์สิ่งที่เป็นนามธรรมเป็นสิ่งสำคัญ!

abstractions ที่ไม่น่ารำคาญทั้งหมดในระดับหนึ่งมีการรั่วไหล - กฎของ Abstractions ที่รั่วไหล

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

YAGNI (Ya Ain't Gonna Need It) เป็นรูปแบบที่ดีกว่าในการติดตามเพื่อหลีกเลี่ยงรหัส Lasagna (รหัสที่มีเลเยอร์มากเกินไป) - abstractions เช่นประเภทและชั้นเรียนมีไว้เพื่อช่วยเหลือโปรแกรมเมอร์และไม่ควรใช้นอกเสียจากว่าพวกเขาจะความช่วยเหลือ

โดยส่วนตัวฉันมุ่งมั่นที่จะ "บันทึกบรรทัดของรหัส" (และแน่นอนที่เกี่ยวข้องกับ "บันทึกไฟล์ / โมดูล / คลาส" ฯลฯ ) ฉันมั่นใจว่ามีบางคนที่จะนำไปใช้กับฉันฉายาของ "ดั้งเดิมหลง" - ฉันคิดว่ามันสำคัญกว่าที่จะมีรหัสซึ่งเป็นเรื่องง่ายที่จะให้เหตุผลเกี่ยวกับกว่ากังวลเกี่ยวกับฉลากรูปแบบและรูปแบบการต่อต้าน ทางเลือกที่ถูกต้องของเวลาที่จะสร้างฟังก์ชั่นโมดูล / ไฟล์ / คลาสหรือวางฟังก์ชั่นในตำแหน่งทั่วไปเป็นสถานการณ์มาก ฉันตั้งเป้าหมายสำหรับฟังก์ชั่น 3-100 บรรทัดไฟล์ 80-500 บรรทัดและ "1, 2, n" สำหรับรหัสไลบรารีที่นำมาใช้ซ้ำได้ ( SLOC - ไม่รวมความคิดเห็นหรือแผ่นสร้างสำเร็จรูป) โดยทั่วไปฉันต้องการ SLOC ขั้นต่ำเพิ่มเติมอย่างน้อย 1 รายการต่อบรรทัด สำเร็จรูป)

รูปแบบเชิงบวกมากที่สุดได้เกิดขึ้นจากนักพัฒนาทำตรงนั้นเมื่อพวกเขาต้องการพวกเขา การเรียนรู้วิธีการเขียนรหัสที่อ่านได้นั้นสำคัญกว่าการพยายามใช้รูปแบบที่ไม่มีปัญหาเดียวกันเพื่อแก้ไข นักพัฒนาที่ดีสามารถใช้รูปแบบของโรงงานโดยไม่เคยเห็นมาก่อนในกรณีที่ผิดปกติซึ่งเหมาะกับปัญหาของพวกเขา ฉันใช้รูปแบบจากโรงงานรูปแบบผู้สังเกตการณ์และอาจเป็นร้อย ๆ โดยไม่ทราบชื่อของพวกเขา (กล่าวคือมี "รูปแบบการกำหนดตัวแปร" หรือไม่) สำหรับการทดสอบที่สนุกสนาน - ดูว่ามีรูปแบบ GoF จำนวนเท่าใดในภาษา JS - ฉันหยุดนับหลังจากประมาณ 12-15 ปีในปี 2009 รูปแบบ Factory นั้นง่ายเหมือนการส่งคืนวัตถุจากคอนสตรัคเตอร์ JS เช่น - ไม่จำเป็นต้องใช้ WidgetFactory

ดังนั้น - ใช่ , บางครั้งก็ ZipCodeเป็นระดับที่ดี อย่างไรก็ตามไม่ปัญหาโยโย่ไม่เกี่ยวข้องอย่างเคร่งครัด

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

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

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

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