การสืบทอดบริบทเป็นเช่นที่แสดงโดยตัวอย่างเป็ดของ Head First Design Patterns ซึ่งไม่เกี่ยวข้องกับรูปแบบกลยุทธ์หรือไม่

ในHead First Design Patternsมันสอนรูปแบบกลยุทธ์โดยใช้ตัวอย่าง Duck ที่ subclasses ที่แตกต่างกันของ Duck สามารถกำหนดพฤติกรรมเฉพาะที่รันไทม์ จากความเข้าใจของฉันจุดประสงค์ของรูปแบบกลยุทธ์คือการเปลี่ยนพฤติกรรมของวัตถุเดี่ยวที่รันไทม์ แต่พวกเขากำลังใช้การสืบทอดของ Duck เพื่อเปลี่ยนพฤติกรรมของ Duck ชนิดต่างๆ

ความสัมพันธ์กัน?

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

ตัวอย่างที่เรียบง่าย

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

ตัวอย่างด้านบนของฉันจะเป็นรูปแบบกลยุทธ์ด้วยหรือไม่

แก้ไข:

ผมเป็นคนที่ประสบความสำเร็จในการหาง่าย 2 ตัวอย่างรูปแบบกลยุทธ์ที่ปฏิบัติตามอย่างเคร่งครัดมากขึ้นที่จะเป็นรูปแบบเพียงกลยุทธ์โดยไม่ต้องมรดกบริบท: Hunter.javaและsolver.py

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

จากรูปแบบการออกแบบ: องค์ประกอบของ OOP ที่ใช้ซ้ำได้คุณจะใช้รูปแบบกลยุทธ์เป็น

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

หากคุณใช้การสืบทอดเพื่อนำพฤติกรรม Quack และ Fly มาใช้คุณจะส่งผลกับคลาสย่อยเหล่านี้เพื่อแสดงชุดค่าผสมทั้งหมดของพฤติกรรม

• FlyableQuackableDuck
• FlyableSqeakableDuck
• FlyableMuteDuck
• NoFlyQuackableDuck
• NoFlySqueakableDuck
• NoFlyMuteDuck

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

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

สิ่งนี้สอดคล้องกับคำแนะนำในการสนับสนุนการจัดองค์ประกอบมากกว่าการสืบทอดเมื่อเป็นไปได้

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

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

โรงงานนามธรรม - การก่อสร้างเชิงบริบท

นี่คือรูปแบบ BTW โปรดทราบว่ามันใช้กลยุทธ์เอง

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

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