23 โหมดการออกแบบบทที่ 17: โหมดคำสั่ง Java
คำจำกัดความ: ห่อหุ้มคำขอลงในวัตถุช่วยให้คุณสามารถกำหนดพารามิเตอร์ไคลเอนต์โดยใช้คำขอที่แตกต่างกันคำขอคิวหรือบันทึกการร้องขอการร้องขอและให้ฟังก์ชั่นการเพิกถอนคำสั่งและฟังก์ชั่นการกู้คืน
ประเภท: รูปแบบพฤติกรรม
แผนภาพชั้นเรียน:
โครงสร้างของโหมดคำสั่ง
ตามชื่อแนะนำโหมดคำสั่งคือการห่อหุ้มคำสั่ง ก่อนอื่นมาดูโครงสร้างพื้นฐานในไดอะแกรมคลาสโหมดคำสั่ง:
คลาสคำสั่ง: เป็นคลาสนามธรรมที่ประกาศคำสั่งที่ต้องดำเนินการ โดยทั่วไปวิธีการดำเนินการจะต้องเผยแพร่ต่อสาธารณะเพื่อดำเนินการคำสั่ง
คลาส Concretecommand: คลาสการใช้งานของคลาสคำสั่งใช้วิธีการที่ประกาศในคลาสนามธรรม
คลาสไคลเอนต์: คลาสการโทรไคลเอนต์สุดท้าย
ฟังก์ชั่นของสามคลาสข้างต้นควรเข้าใจง่ายขึ้น มามุ่งเน้นไปที่คลาส Invoker และคลาส Recevier
คลาส Invoker: ผู้โทรมีหน้าที่เรียกใช้คำสั่ง
คลาสผู้รับ: ผู้รับมีหน้าที่รับผิดชอบในการรับและดำเนินการคำสั่ง
ในการกล่าวอย่างตรงไปตรงมาการห่อหุ้มคำสั่งที่เรียกว่าไม่มีอะไรมากไปกว่าการเขียนชุดการดำเนินการลงในวิธีการแล้วถูกเรียกโดยลูกค้า มันสะท้อนให้เห็นในแผนภาพคลาส ใช้คลาสคอนกรีตคอมมอนและคลาสไคลเอนต์เท่านั้นเพื่อให้การห่อหุ้มคำสั่งเสร็จสมบูรณ์ แม้ว่ามันจะดำเนินต่อไปเพื่อเพิ่มความยืดหยุ่นคลาสคำสั่งสามารถเพิ่มสำหรับสิ่งที่เป็นนามธรรมที่เหมาะสม ฟังก์ชั่นของผู้โทรและตัวรับสัญญาณนี้คืออะไร?
ในความเป็นจริงคุณสามารถคิดจากมุมมองอื่น: หากคุณเพียงแค่ห่อหุ้มการดำเนินการบางอย่างเป็นคำสั่งให้ผู้อื่นโทรหารูปแบบได้อย่างไร ในฐานะที่เป็นแบบจำลองพฤติกรรมโหมดคำสั่งจะต้องมีการมีเพศสัมพันธ์ต่ำก่อน เฉพาะเมื่อระดับการมีเพศสัมพันธ์ต่ำสามารถปรับปรุงความยืดหยุ่นได้ วัตถุประสงค์ของการเพิ่มบทบาทผู้โทรและตัวรับสัญญาณนั้นเป็นสิ่งที่แม่นยำสำหรับเรื่องนี้ รหัสทั่วไปสำหรับโหมดคำสั่งมีดังนี้:
คลาส Invoker {คำสั่งส่วนตัวคำสั่ง; โมฆะสาธารณะ setCommand (คำสั่งคำสั่ง) {this.command = คำสั่ง; } การกระทำของโมฆะสาธารณะ () {this.command.execute (); }} คำสั่งบทคัดย่อคลาส {public abstract void execute (); } class concreteCommand ขยายคำสั่ง {ผู้รับตัวรับสัญญาณส่วนตัว; คอนกรีตสาธารณะ (ตัวรับสัญญาณรับ) {this.receiver = ตัวรับสัญญาณ; } โมฆะสาธารณะดำเนินการ () {this.receiver.dosomething (); }} ตัวรับสัญญาณคลาส {โมฆะสาธารณะ dosomething () {system.out.println ("การประมวลผลตรรกะของผู้รับธุรกิจ"); }} ไคลเอนต์คลาสสาธารณะ {โมฆะคงที่สาธารณะหลัก (String [] args) {ตัวรับสัญญาณตัวรับสัญญาณ = ตัวรับสัญญาณใหม่ (); Command Command = ใหม่ ConcreteCommand (ผู้รับ); // ไคลเอนต์ดำเนินการโดยตรงวิธีคำสั่งเฉพาะ (วิธีนี้สอดคล้องกับคำสั่งคลาสไดอะแกรม) execute (); // ไคลเอนต์ดำเนินการคำสั่งผ่านผู้โทร Invoker Invoker = new Invoker (); invoker.setCommand (คำสั่ง); invoker.action (); -ผ่านรหัสเราจะเห็นได้ว่าเมื่อเราโทรเวลาการดำเนินการเป็นอันดับแรกของคลาสผู้โทรจากนั้นคลาสคำสั่งและในที่สุดคลาสผู้รับ กล่าวอีกนัยหนึ่งการดำเนินการของคำสั่งแบ่งออกเป็นสามขั้นตอนและระดับการมีเพศสัมพันธ์นั้นต่ำกว่าการห่อหุ้มการดำเนินการทั้งหมดลงในชั้นเรียนมาก นี่คือสาระสำคัญของรูปแบบคำสั่ง: แยกผู้โทรของคำสั่งและผู้ดำเนินการเพื่อให้ทั้งสองฝ่ายไม่จำเป็นต้องสนใจว่าอีกฝ่ายทำงานอย่างไร
ข้อดีและข้อเสียของโหมดคำสั่ง
ก่อนอื่นโหมดคำสั่งนั้นมีการห่อหุ้มอย่างมาก: แต่ละคำสั่งถูกห่อหุ้มและสำหรับไคลเอนต์คำสั่งที่สอดคล้องกันเรียกว่ามากที่สุดเท่าที่ต้องการฟังก์ชั่นโดยไม่ทราบว่าคำสั่งถูกดำเนินการอย่างไร ตัวอย่างเช่นมีชุดคำสั่งการทำงานของไฟล์: สร้างไฟล์ใหม่คัดลอกไฟล์และลบไฟล์ หากการดำเนินการทั้งสามนี้ถูกห่อหุ้มลงในคลาสคำสั่งไคลเอ็นต์จะต้องรู้ว่ามีคลาสคำสั่งทั้งสามนี้ สำหรับตรรกะที่ห่อหุ้มอยู่ในคลาสคำสั่งไคลเอนต์ไม่จำเป็นต้องรู้
ประการที่สองโหมดคำสั่งมีความยืดหยุ่นที่ดี ในโหมดคำสั่งการห่อหุ้มขั้นพื้นฐานที่สุดของการดำเนินการในคลาสผู้รับและการห่อหุ้มระดับรองของคลาสคำสั่งของการดำเนินการพื้นฐานเหล่านี้ เมื่อเพิ่มคำสั่งใหม่การเขียนคลาสคำสั่งโดยทั่วไปจะไม่มาจากศูนย์ มีคลาสผู้รับจำนวนมากสำหรับการโทรและยังมีคลาสคำสั่งจำนวนมากสำหรับการโทรและรหัสสามารถนำกลับมาใช้ใหม่ได้มาก ตัวอย่างเช่นในการดำเนินการของไฟล์เราจำเป็นต้องเพิ่มคำสั่งเพื่อตัดไฟล์และเราจำเป็นต้องรวมสองคำสั่งของการคัดลอกไฟล์และลบไฟล์ซึ่งสะดวกมาก
สุดท้ายเรามาพูดถึงข้อเสียของโหมดคำสั่งนั่นคือถ้ามีคำสั่งมากมายมันจะเป็นอาการปวดหัวในการพัฒนา โดยเฉพาะอย่างยิ่งคำสั่งง่ายๆจำนวนมากเป็นเพียงไม่กี่บรรทัดของรหัสที่จะนำไปใช้ หากคุณใช้โหมดคำสั่งคุณไม่ต้องกังวลเกี่ยวกับคำสั่งง่าย ๆ คุณต้องเขียนคลาสคำสั่งเพื่อห่อหุ้มมัน
สถานการณ์ที่ใช้งานได้สำหรับโหมดคำสั่ง
สำหรับฟังก์ชั่นโหมดการตอบสนองต่อการร้องขอส่วนใหญ่เหมาะสมกว่าที่จะใช้โหมดคำสั่ง ตามที่คำจำกัดความของโหมดคำสั่งระบุว่าโหมดคำสั่งนั้นสะดวกกว่าสำหรับการใช้งานฟังก์ชั่นเช่นการบันทึกและการยกเลิกการดำเนินการ
สรุป
ไม่ว่าจะใช้โหมดในโอกาสเป็นคำถามที่พันกันมากสำหรับนักพัฒนาทุกคน บางครั้งเนื่องจากการเปลี่ยนแปลงความต้องการบางอย่างรูปแบบการออกแบบบางอย่างใช้สำหรับความยืดหยุ่นและความยืดหยุ่นของระบบ แต่ข้อกำหนดที่คาดการณ์ได้นี้ไม่ได้ ในทางตรงกันข้ามข้อกำหนดที่ไม่สามารถคาดเดาได้จำนวนมากเกิดขึ้นส่งผลให้รูปแบบการออกแบบที่ใช้มีบทบาทตรงกันข้ามเมื่อแก้ไขรหัสเพื่อให้ทีมงานโครงการทั้งหมดบ่น ฉันเชื่อว่าโปรแกรมเมอร์ทุกคนได้พบตัวอย่างเช่นนี้ ดังนั้นตามหลักการของการพัฒนา Agile เมื่อเราออกแบบโปรแกรมถ้าเราสามารถแก้ปัญหาได้ดีโดยไม่ต้องใช้รูปแบบที่แน่นอนตามความต้องการในปัจจุบันเราไม่ควรแนะนำเพราะมันไม่ยากที่จะแนะนำรูปแบบการออกแบบ เราสามารถทำได้ในระบบเมื่อเราต้องการใช้มันและแนะนำรูปแบบการออกแบบนี้
ใช้โหมดคำสั่งเป็นตัวอย่าง ในการพัฒนาของเราฟังก์ชั่นโหมดการตอบสนองการร้องขอเป็นเรื่องธรรมดามาก โดยทั่วไปแล้วเราจะห่อหุ้มการตอบสนองต่อการร้องขอลงในวิธีการ วิธีการห่อหุ้มนี้สามารถเรียกได้ว่าเป็นคำสั่ง แต่ไม่ใช่โหมดคำสั่ง ไม่ว่าการออกแบบนี้ควรได้รับการยกระดับความสูงของรูปแบบจะต้องพิจารณาแยกต่างหากหรือไม่เพราะหากใช้โหมดคำสั่งจะต้องแนะนำทั้งสองบทบาทของผู้โทรและตัวรับสัญญาณ ตรรกะที่วางไว้ในที่เดียวนั้นกระจัดกระจายเป็นสามประเภท เมื่อออกแบบจำเป็นต้องพิจารณาว่าค่าใช้จ่ายนี้คุ้มค่าหรือไม่
ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้ ฉันหวังว่ามันจะเป็นประโยชน์ต่อการเรียนรู้ของทุกคนและฉันหวังว่าทุกคนจะสนับสนุน wulin.com มากขึ้น