ฉันต้องประนีประนอม: DRY หรือ Command-Query-Separation

ฉันเพิ่ง refactoring วิธีที่ทั้งคำสั่งและวิธีการสืบค้น

หลังจากแยกมันเป็นวิธีการหนึ่งคำสั่งและวิธีการค้นหาฉันพบว่าขณะนี้มีหลายสถานที่ในรหัสที่ฉันเรียกคำสั่งแล้วรับค่าจากแบบสอบถามซึ่งดูเหมือนว่าเป็นการละเมิดหลักการ DRY

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

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

QueryResult command()
{
   // do command stuff
   return query();
}

ฉันไม่เคยได้ยินเกี่ยวกับ Command-Query-Separation (CQS) มาก่อน แต่ดูเหมือนว่ามันจะเกี่ยวข้องกับ Single Responsibility Principle (SRP) ซึ่งระบุว่าหน้าที่ / คลาสควรมีหน้าที่รับผิดชอบในการทำสิ่งหนึ่งและสิ่งเดียวเท่านั้น .

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

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

ฉันคิดว่าวิธีการห่อหุ้มเป็นทางออกที่ยอมรับอย่างสมบูรณ์และเพื่อแสดงให้เห็นว่าลองยกตัวอย่างของคุณไปอีกขั้นหนึ่ง ถ้าคุณต้องเรียกใช้แบบสอบถาม 2 รายการแทนที่จะเป็น 1 แล้วดำเนินการคำสั่งตามนั้น ดังนั้นโค้ด 2 บรรทัดของคุณจะเป็น 6 หรือ 8 จะเกิดอะไรขึ้นถ้ามีการตรวจสอบ / ตรวจสอบข้อมูลระหว่างหนึ่งกับอีกอันดังนั้นตอนนี้คุณมีรหัส 15 บรรทัด คุณจะคิดสองครั้งเกี่ยวกับการสร้าง wrapper ที่ทำทุกอย่างแทนที่จะโรย 15 บรรทัดในหลายไฟล์หรือไม่?

DRY มีความสำคัญมากกว่าเนื่องจากสามารถแก้ไขความต้องการขั้นพื้นฐานได้มากขึ้น - หลีกเลี่ยงความพยายามซ้ำซ้อนและสิ้นเปลืองอย่างมีประสิทธิภาพ นี่คือสิ่งพื้นฐาน - หนึ่งไม่จำเป็นต้องเป็นโปรแกรมเมอร์ที่จะเข้าใจมัน

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

1. ความจำเป็นในการเรียกใช้โค้ดสำหรับผลลัพธ์นั้นไม่สามารถหลีกเลี่ยงได้เพราะนี่เป็นพื้นฐานสำหรับการเขียนโปรแกรมขนาดใหญ่จากหน่วยเล็ก ๆ

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

3. ความจำเป็นในการทำให้เกิดผลกระทบและสร้างผลลัพธ์ในรหัสเดียวกันนั้นไม่สามารถหลีกเลี่ยงได้เพราะในทางปฏิบัติเราต้องการทั้งเอฟเฟกต์และการประกอบกันไม่ใช่เพียงอย่างเดียวหรืออย่างอื่น

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

สรุปแล้ว "การแก้ปัญหา" เช่นเดียวกับ CQS เพียงเข้ามาออกแบบโปรแกรมตามหลักการที่ดีบนพื้นฐานของความเป็นจริง ไปหา DRY