วิธีการเลือกระหว่างบอกไม่ถามและแยกคำสั่ง?

หลักการบอกว่าอย่าถามว่า:

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

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

ตัวอย่างง่ายๆของ "Tell, Don't Ask"คือ

Widget w = ...;
if (w.getParent() != null) {
  Panel parent = w.getParent();
  parent.remove(w);
}

และเวอร์ชัน Tell คือ ...

Widget w = ...;
w.removeFromParent();

แต่ถ้าฉันต้องรู้ผลลัพธ์จากวิธี removeFromParent ปฏิกิริยาแรกของฉันคือเพียงแค่เปลี่ยน removeFromParent เพื่อส่งกลับค่าบูลีนเพื่อระบุว่าพาเรนต์ถูกลบหรือไม่

แต่ฉันเจอรูปแบบการแยกคำสั่งซึ่งบอกว่าไม่ต้องทำ

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

สองคนนี้ขัดแย้งกันจริงๆและฉันจะเลือกระหว่างคนทั้งสองได้อย่างไร ฉันจะไปกับ Pragmatic Programmer หรือ Bertrand Meyer ได้ไหม?

จริงๆแล้วปัญหาตัวอย่างของคุณแสดงให้เห็นถึงการขาดการสลายตัว

ลองเปลี่ยนกันนิดหน่อย:

Book b = ...;
if (b.getShelf() != null) 
    b.getShelf().remove(b);

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

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

หากต้องการกลับมาที่ตัวอย่างหนังสือ - ป้อนบรรณารักษ์:

Librarian l = ...;
Book b = ...;
l.findShelf(b).remove(b);

โปรดเข้าใจว่าเราไม่ได้ถามอีกต่อไปในความรู้สึกของบอกไม่ได้ถาม

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

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

หากคุณต้องการทราบผลลัพธ์คุณต้องทำ นั่นคือความต้องการของคุณ

วลีที่ว่า "วิธีการควรกลับค่า แต่ถ้าพวกเขามีความโปร่งใส referentially และด้วยเหตุนี้มีผลข้างเคียงที่ไม่" เป็นแนวทางที่ดีในการปฏิบัติตาม (โดยเฉพาะอย่างยิ่งถ้าคุณกำลังเขียนโปรแกรมของคุณในการทำงานรูปแบบสำหรับการทำงานพร้อมกันหรือเหตุผลอื่น ๆ ) แต่มันเป็น ไม่แน่นอน

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

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

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

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

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

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

วิธีจัดการกับคุณในภายหลังคือสิ่งที่คุณทำ คุณสามารถสร้างสิ่งที่เป็นนามธรรมด้านบนซึ่งเป็นประเภทวิดเจ็ตที่มีremoveFromParent()แต่คุณควรมีทางเลือกในระดับต่ำเสมอมิฉะนั้นคุณอาจมีสมมติฐานก่อนกำหนด

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

สิ่งที่คุณอธิบายคือ "ข้อยกเว้น" ที่รู้จักกันในหลักการแยกคำสั่ง

ในบทความนี้Martin Fowlerอธิบายว่าเขาจะคุกคามข้อยกเว้นเช่นนี้ได้อย่างไร

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

ในตัวอย่างของคุณฉันจะพิจารณาข้อยกเว้นเดียวกัน

การแยกคำสั่งการค้นหานั้นเข้าใจผิดได้ง่ายอย่างน่าอัศจรรย์

ถ้าฉันบอกคุณในระบบของฉันมีคำสั่งที่ส่งคืนค่าจากแบบสอบถามและคุณพูดว่า "ฮา! คุณกำลังละเมิด!" คุณกำลังกระโดดปืน

ไม่นั่นไม่ใช่สิ่งต้องห้าม

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

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

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

อินเทอร์เฟซที่คล่องแคล่วและ "ละเมิด" ของ iDSL นี้แสดงถึงการตอบโต้ตลอดเวลา มีพลังงานจำนวนมากที่ถูกเพิกเฉยถ้าคุณทำปฏิกิริยามากกว่า

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

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