สตริง Hardcoding ที่จะไม่มีวันเปลี่ยนแปลง


39

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

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

// Verbs #1 : (model: "chanter")
    terminations = {
        ind_imp: ["ais", "ais", "ait", "ions", "iez", "aient"],
        ind_pre: ["e", "es", "e", "ons", "ez", "ent"],
        ind_fut: ["erai", "eras", "era", "erons", "erez", "eront"],
        participle: ["é", "ant"]
    };

เหล่านี้เป็นคำต่อท้ายผันสำหรับชั้นเรียนที่พบมากที่สุดของคำกริยาในภาษาฝรั่งเศส

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

// "être":
    forms = {
        ind_imp: ["étais", "étais", "était", "étions", "étiez", "étaient"],
        ind_pre: ["suis", "es", "est", "sommes", "êtes", "sont"],
        ind_fut: ["serai", "seras", "sera", "serons", "serez", "seront"],
        participle: ["été", "étant"]
    };

ฉันสามารถใส่สิ่งนี้ลงใน XML หรือแม้กระทั่ง JSON และเลิกทำการ deserialize เมื่อจำเป็นต้องใช้ แต่มีจุดหรือไม่ สตริงเหล่านี้เป็นส่วนหนึ่งของภาษาธรรมชาติซึ่งมีการเปลี่ยนแปลง แต่ในอัตราที่ช้า

ความกังวลของฉันคือการทำสิ่งที่ "ถูกต้อง" และกำจัดแหล่งข้อมูลบางอย่างฉันไม่เพียง แต่ทำให้ปัญหาซับซ้อนซึ่งไม่จำเป็นต้องซับซ้อน แต่ฉันยังติดตามย้อนกลับอย่างสมบูรณ์ในเป้าหมายทั้งหมดของ วิธีอัลกอริทึม: อย่าใช้แหล่งข้อมูล! ใน C #, ฉันสามารถสร้างชั้นใต้namespace Verb.Conjugation(เช่นclass Irregular) บ้านสตริงเหล่านี้ในชนิดนับหรือสิ่งแทนการบรรจุพวกเขาเข้าไปใน XML class IrregularVerbDeserializerและการสร้าง

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

แก้ไข : สำเนาที่ซ้ำกันเสนอให้ถามถึงวิธีการจัดเก็บสแตติกสตริงจำนวนมากในขณะที่คำถามของฉันคือเมื่อใดที่ฉันควรโค้ดฮาร์สตริงสแตติกเหล่านี้เมื่อใด


26
คุณต้องการใช้ซอฟต์แวร์นี้สำหรับภาษาอื่นที่ไม่ใช่ภาษาฝรั่งเศสในอนาคตหรือไม่?

10
วิธีอัลกอริทึมหรือไม่เป็นที่ชัดเจนว่าคุณเพียงแค่ต้อง hardcode สตริง 32 * 20 (และอื่น ๆ เมื่อคุณเพิ่มภาษาอื่น ๆ ) และคำถามจริงเพียงอย่างเดียวคือที่ที่พวกเขา ฉันจะเลือกที่ใดก็ตามที่คุณรู้สึกสะดวกที่สุดกับคุณซึ่งดูเหมือนจะเป็นรหัสในขณะนั้น คุณสามารถสลับได้ในภายหลัง
Ixrec

1
@ChrisCirefice ฟังดูดีที่สุดสำหรับฉัน ไปเลย
Ixrec

2
@Gusdor ฉันไม่ 'คิดว่าคุณอ่านอย่างชัดเจน - ฉันบอกว่ารูปแบบการผันคำกริยาจะไม่เปลี่ยนแปลงหรือไม่บ่อยนักว่าการคอมไพล์ซ้ำทุกๆ 100 ปีหรือมากกว่านั้นก็ดี แน่นอนว่ารหัสจะเปลี่ยน แต่เมื่อมีสายอยู่ในนั้นฉันจะต้องการมันนอกจากว่าฉันจะทำให้พวกเขาจะคงที่ในอีก 100 ปีข้างหน้า
Chris Cirefice

1
+1 ไม่ต้องพูดถึงว่าใน 60-100 ปีค่าใช้จ่ายจะไม่อยู่หรือถูกแทนที่ด้วยรุ่นที่ดีกว่าโดยสิ้นเชิง
HarryCBurn

คำตอบ:


56

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

ดูเหมือนว่าคุณจะตอบคำถามของคุณเอง

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

ฉันจะใช้วิธีที่ง่ายที่สุดในการดำเนินการจนกว่าฉันจะพบเหตุผลที่น่าสนใจที่จะทำให้มันซับซ้อนมากขึ้น


ขอบคุณแดนนี่เป็นสิ่งที่ฉันคิดได้ การเขียน XML schema สำหรับสิ่งนี้มีไฟล์อื่นที่ต้องติดตามและต้องเขียนส่วนต่อประสานเพื่อลบข้อมูลออกดูเหมือนว่า overkill เพราะมีสตริงไม่มากนักและเนื่องจากเป็นภาษาธรรมชาติจึงไม่น่าจะเปลี่ยนไปอย่างมาก ในอีก 100 ปีข้างหน้า โชคดีที่ทุกวันนี้ในภาษาการเขียนโปรแกรมเรามีวิธีที่เป็นนามธรรมในการสรุปข้อมูลดิบนี้หลังอินเทอร์เฟซที่ดูดีตัวอย่างเช่นFrench.Verb.Irregular.Etreซึ่งจะมีข้อมูลจากคำถามของฉัน ฉันคิดว่ามันใช้งานได้ดี;)
Chris Cirefice

3
+1 ที่นี่จากค่ายทับทิมฉันจะเริ่มใช้ฮาร์ดโค้ดและย้ายมันไปตั้งค่าตามความจำเป็น อย่าทำโครงการของคุณมากเกินไปโดยกำหนดสิ่งที่สามารถกำหนดค่าได้ มันทำให้คุณช้าลง
Overbryd

2
หมายเหตุ: บางกลุ่มมีคำจำกัดความที่แตกต่างกันของ "การเข้ารหัส" ดังนั้นโปรดทราบว่าคำนั้นหมายถึงหลายสิ่ง มีรูปแบบการต่อต้านที่ได้รับการยอมรับเป็นอย่างดีซึ่งคุณสามารถกำหนดค่ารหัสฮาร์ทลงในคำสั่งของฟังก์ชันได้แทนที่จะสร้างโครงสร้างข้อมูลตามที่คุณมี ( if (num == 0xFFD8)) ตัวอย่างนั้นควรกลายเป็นสิ่งที่เหมือนif (num == JPEG_MAGIC_NUMBER)ในเกือบทุกกรณีด้วยเหตุผลที่อ่านง่าย ฉันเพิ่งจะชี้ให้เห็นเพราะคำว่า "hardcoding" มักจะทำให้ขนบนคอของผู้คน (เหมือนของฉัน) เพราะความหมายอื่นของคำนี้
Cort Ammon

@CortAmmon JPEG มีจำนวนเวทย์มนตร์มากมาย แน่นอนJPEG_START_OF_IMAGE_MARKER?
253751

@immibis การเลือกชื่อคงที่ของคุณน่าจะดีกว่าของฉัน
Cort Ammon

25

คุณกำลังให้เหตุผลในขอบเขตที่ไม่ถูกต้อง

คุณยังไม่ได้อ่านคำกริยาเพียงคำเดียว คุณได้ hardcoded ภาษาและกฎระเบียบ ในทางกลับกันหมายความว่าแอปพลิเคชันของคุณไม่สามารถใช้กับภาษาอื่นและไม่สามารถขยายด้วยกฎอื่น ๆ ได้

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

  • ในอนาคตอันใกล้นี้จะขยายแอปไปเป็นภาษาอื่นหรือไม่ด้วยความมั่นใจ 100% ถ้าเป็นเช่นนั้นคุณควรส่งออกสิ่งต่าง ๆ ไปยังไฟล์ JSON หรือ XML (สำหรับคำส่วนต่าง ๆ ของคำ ฯลฯ ) และภาษาแบบไดนามิก (สำหรับกฎ) ในขณะนี้แทนที่จะบังคับให้คุณเขียนส่วนสำคัญของแอปของคุณใหม่

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

เพื่อเป็นตัวอย่างให้ตรวจสอบการสะกดของ Microsoft Word คุณคิดว่าฮาร์ดโค้ดมีหลายสิ่ง

หากคุณมีการพัฒนาหน่วยประมวลผลข้อความ, คุณสามารถเริ่มต้นด้วยเครื่องยนต์สะกดคำง่ายๆกับกฎ hardcoded และคำพูด hardcoded if word == "musik": suggestSpelling("music");แม้: อย่างรวดเร็วคุณจะเริ่มย้ายคำจากนั้นควบคุมตัวเองนอกรหัสของคุณ มิฉะนั้น:

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

ในขณะที่คุณเน้นตัวเอง:

กฎน้อยมากจากฝรั่งเศสสามารถนำไปใช้กับญี่ปุ่น

ทันทีที่คุณ hardcode กฎสำหรับภาษาอื่น ๆ จะต้องใช้รหัสมากขึ้นโดยเฉพาะอย่างยิ่งให้ความซับซ้อนของภาษาธรรมชาติ

อีกเรื่องคือวิธีที่คุณแสดงกฎต่าง ๆ เหล่านั้นหากไม่ผ่านรหัส ท้ายที่สุดคุณอาจพบว่าภาษาการเขียนโปรแกรมเป็นเครื่องมือที่ดีที่สุด ในกรณีนี้หากคุณต้องการขยายเครื่องยนต์โดยไม่ต้องคอมไพล์ใหม่ภาษาแบบไดนามิกอาจเป็นทางเลือกที่ดี


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

4
ฉันไม่เห็นด้วย - ฉันไม่คิดว่ามันสมเหตุสมผลที่จะย้ายสิ่งใดนอกรหัสก่อนที่จะเกิดขึ้นตามธรรมชาติผ่านการปรับโครงสร้างใหม่ เริ่มต้นด้วยหนึ่งภาษาเพิ่มภาษาอื่น ๆ - ในบางจุดที่การใช้งานของ ILanguageRule จะแบ่งปันรหัสมากพอที่จะมีประสิทธิภาพมากขึ้นในการใช้งานแบบพารามิเตอร์เดียวกับ XML (หรือไฟล์อื่น ๆ ) แต่ถึงอย่างนั้นคุณอาจจะจบลงด้วยภาษาญี่ปุ่นซึ่งมีโครงสร้างที่แตกต่างอย่างสิ้นเชิง การเริ่มต้นด้วยการผลักดันอินเทอร์เฟซของคุณให้เป็น XML (หรือคล้ายกัน) เป็นการขอร้องให้มีการเปลี่ยนแปลงในอินเทอร์เฟซแทนการใช้งาน
ptyx

2
หมายเหตุ: หากคุณต้องการเพิ่มภาษาอื่น ๆ นั่นไม่ได้หมายความว่าจะเป็นการย้ายภาษาไปยังไฟล์กำหนดค่า! คุณสามารถมีLanguageProcessorคลาสที่มีคลาสย่อยหลายคลาสได้อย่างเท่าเทียมกัน (อย่างมีประสิทธิภาพ "ไฟล์กำหนดค่า" จริง ๆ แล้วเป็นคลาส)
253751

2
@MainMa: ทำไมคุณถึงคิดว่าเป็นปัญหาในการคอมไพล์ซ้ำเมื่อเพิ่มคำ? คุณต้องคอมไพล์อีกครั้งเมื่อทำการเปลี่ยนแปลงรหัสอื่น ๆ และรายการคำอาจเป็นส่วนหนึ่งของรหัสที่มีโอกาสน้อยที่จะเปลี่ยนแปลงตลอดเวลา
JacquesB

3
ฉันสงสัยว่าความยืดหยุ่นในการเขียนรหัสกฎทางไวยากรณ์เฉพาะของแต่ละภาษาในคลาสย่อยนั้นจะสะดวกกว่าในที่สุดเมื่อเทียบกับความสามารถในการโหลดกฎเดียวกันเหล่านั้นจากไฟล์ปรับแต่ง (เพราะคุณจะเขียน ภาษาโปรแกรมของตัวเองเพื่อตีความการกำหนดค่า)
David K

15

ควรแยกสตริงไปยังไฟล์กำหนดค่าหรือฐานข้อมูลเมื่อค่าสามารถเปลี่ยนแปลงได้อย่างอิสระจากตรรกะของโปรแกรม

ตัวอย่างเช่น:

  • แยกข้อความ UI ไปยังไฟล์ทรัพยากร สิ่งนี้จะช่วยให้ผู้ที่ไม่ใช่โปรแกรมเมอร์สามารถแก้ไขและอ่านหลักฐานและช่วยให้สามารถเพิ่มภาษาใหม่ได้โดยการเพิ่มไฟล์ทรัพยากรที่มีการแปลใหม่

  • แยกสตริงการเชื่อมต่อ URL ไปยังบริการภายนอก ฯลฯ ไปยังไฟล์การกำหนดค่า สิ่งนี้ช่วยให้คุณใช้การกำหนดค่าที่แตกต่างกันในสภาพแวดล้อมที่แตกต่างกันและเพื่อเปลี่ยนการกำหนดค่าได้ทันทีเนื่องจากอาจจำเป็นต้องเปลี่ยนด้วยเหตุผลภายนอกแอปพลิเคชันของคุณ

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

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

สตริงอาจฮาร์ดโค้ดเมื่อสตริงที่แท้จริงไม่สามารถเปลี่ยนแปลงได้โดยไม่ต้องเปลี่ยนลอจิกโปรแกรม

ตัวอย่าง:

  • คอมไพเลอร์สำหรับภาษาการเขียนโปรแกรม คำหลักจะไม่ถูกแยกไปยังการกำหนดค่าเนื่องจากแต่ละคำหลักมีความหมายที่เฉพาะเจาะจงซึ่งจะต้องได้รับการสนับสนุนโดยรหัสในคอมไพเลอร์ การเพิ่มคำหลักใหม่จะต้องมีการเปลี่ยนแปลงรหัสเสมอดังนั้นจึงไม่มีค่าในการแยกสตริงไปยังไฟล์กำหนดค่า
  • การใช้โปรโตคอล: เช่น ไคลเอ็นต์ HTTP จะมีสตริง hardcoded เช่น "GET", "content-type" ฯลฯ ที่นี่สตริงเป็นส่วนหนึ่งของข้อกำหนดของโปรโตคอลดังนั้นพวกเขาจึงเป็นส่วนหนึ่งของรหัสที่มีโอกาสน้อยที่สุดที่จะเปลี่ยนแปลง

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

หากคุณเพิ่มภาษาใหม่คุณจะต้องเพิ่มรหัสใหม่เนื่องจากแต่ละภาษามีตรรกะการผันคำเฉพาะ


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


1
ที่จริงแล้วในความเห็นของเมนมาฉันพูดถึงว่าการเขียน DSL สำหรับสิ่งนี้จะไม่มีประโยชน์เพราะภาษาธรรมชาติน้อยมากที่คล้ายกันมากพอที่จะทำให้มันคุ้มค่ากับความพยายาม บางทีฝรั่งเศส / สเปน / อิตาลีอาจใกล้พอสมควรแต่ก็ไม่คุ้มกับความพยายามเป็นพิเศษเพราะปริมาณของกฎมีความคงที่สูงในภาษาใดก็ตาม อีกประเด็นที่คุณพูดถึงความซับซ้อนคือความกังวลที่แน่นอนของฉันและฉันคิดว่าคุณเข้าใจสิ่งที่ฉันถามในคำถามของฉันและให้คำตอบที่ดีกับตัวอย่างดังนั้น +1!
Chris Cirefice

5

ฉันเห็นด้วย 100% กับคำตอบของ Dan Pichelman แต่ฉันต้องการเพิ่มอีกอย่าง คำถามที่คุณควรถามตัวเองที่นี่คือ "ใครจะเป็นผู้รักษา / ขยาย / แก้ไขรายการคำศัพท์" หากเป็นบุคคลที่รักษากฎของภาษาเฉพาะไว้เสมอ (ผู้พัฒนาโดยเฉพาะฉันเดาคุณ) จากนั้นจะไม่มีประโยชน์ในการใช้ไฟล์การกำหนดค่าภายนอกหากสิ่งนี้ทำให้สิ่งที่ซับซ้อนมากขึ้น - คุณจะไม่ได้รับประโยชน์ใด ๆ จาก นี้. จากมุมมองนี้มันจะทำให้รู้สึกยากที่จะ hardcode รายการคำแม้ว่าคุณจะต้องเปลี่ยนเป็นครั้งคราวตราบใดที่มันเพียงพอที่จะส่งรายการใหม่เป็นส่วนหนึ่งของเวอร์ชันใหม่

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


นี่เป็นจุดที่ดี - อย่างไรก็ตามฉันมีโอกาสมากที่ฉันจะเป็นคนเดียวที่รักษารหัสอย่างน้อยในอีกไม่กี่ปีข้างหน้า ส่วนที่ดีเกี่ยวกับเรื่องนี้คือแม้ว่าจะมีการเข้ารหัสสตริงยาก แต่เป็นชุดเล็ก ๆ ของสตริง / กฎที่ไม่น่าจะเปลี่ยนแปลงได้ตลอดเวลาเร็ว ๆ นี้ (เนื่องจากเป็นภาษาธรรมชาติซึ่งไม่ได้พัฒนามากเกินไปต่อปี -ปี). ที่กล่าวว่ากฎการผันเงื่อนไขการยกเลิกคำกริยา ฯลฯ ในทุกโอกาสที่จะเป็นเหมือนกันสำหรับชีวิตของเรา :)
คริส Cirefice

1
@ChrisCirefice ": ตรงประเด็นของฉัน
Doc Brown

2

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

สิ่งนี้จะช่วยให้คุณประหยัดเวลามากขึ้นด้วยการบำรุงรักษารายชื่อ ใน VCS ของคุณคุณสามารถระบุได้อย่างง่ายดายว่าการกระทำได้ทำการเปลี่ยนแปลงอัลกอริทึมหรือเพียงแค่แก้ไขข้อผิดพลาดการผันคำกริยา นอกจากนี้รายการอาจต้องมีการเพิ่มเติมในอนาคตสำหรับกรณีที่คุณไม่ได้พิจารณา โดยเฉพาะจำนวนคำกริยา 32 ตัวที่คุณนับได้นั้นดูเหมือนจะไม่ถูกต้อง ในขณะที่สิ่งเหล่านั้นดูเหมือนจะครอบคลุมสิ่งที่ใช้กันทั่วไปฉันก็พบการอ้างอิงถึง133หรือ350 รายการของพวกเขา


Bergi ฉันวางแผนที่จะแยกข้อมูลจากอัลกอริทึม สิ่งที่คุณทราบเกี่ยวกับความผิดปกติของภาษาฝรั่งเศส - ความหมายของความผิดปกตินั้นเป็นความเข้าใจผิดที่ดีที่สุด สิ่งที่ฉันหมายถึงเมื่อฉันพูดผิดปกติเป็นคำกริยาที่ไม่สามารถ 'คำนวณ' หรือผันจากรูปแบบ infinitive เพียงอย่างเดียว คำกริยาที่ผิดปกติไม่มีรูปแบบเฉพาะเลยและจำเป็นต้องมีการผันคำกริยาที่ระบุไว้อย่างชัดเจน (ภายใต้ภาษาฝรั่งเศส Verb.Conjugation.Irregular` เป็นต้น) เทคนิค, คำกริยา -ir นี้ 'ผิดปกติ' แต่พวกเขาจะมีรูปแบบการผันคง :)
คริส Cirefice

0

ส่วนที่สำคัญคือการแยกความกังวล วิธีการที่คุณประสบความสำเร็จนั้นมีความเกี่ยวข้องน้อยกว่า เช่น Java เป็นเรื่องปกติ

คุณจะต้องเพิ่มภาษาของการเปลี่ยนแปลงกฎ: คุณต้องแก้ไขโค้ดและไฟล์จำนวนเท่าไร?

ตามหลักการแล้วการเพิ่มภาษาใหม่ควรเป็นไปได้ด้วยการเพิ่มไฟล์ 'english.xml' หรือ 'EnglishRules ใหม่ที่ใช้ออบเจ็กต์ ILanguageRules' ไฟล์ข้อความ (JSON / XML) ให้ประโยชน์แก่คุณหากคุณต้องการเปลี่ยนแปลงนอกวงจรชีวิตการสร้างของคุณ แต่ต้องใช้ไวยากรณ์ที่ซับซ้อนการแยกวิเคราะห์และยากที่จะทำการดีบัก ไฟล์โค้ด (Java) ช่วยให้คุณสามารถแสดงกฎที่ซับซ้อนได้ในวิธีที่ง่ายกว่า แต่ต้องการการสร้างใหม่

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.