คลาสผู้จัดการสามารถเป็นสัญลักษณ์ของสถาปัตยกรรมที่ไม่ดีได้หรือไม่?

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

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

• ผู้จัดการหลายครั้งดูเหมือนว่าจะใช้เพื่อบรรเทาปัญหาในการออกแบบเช่นเมื่อโปรแกรมเมอร์ไม่สามารถหาวิธีที่จะทำให้โปรแกรม Just Work ^TMและต้องอาศัยคลาสผู้จัดการเพื่อให้ทุกอย่างทำงานได้อย่างถูกต้อง

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

คลาสผู้จัดการเป็นสัญลักษณ์ของสถาปัตยกรรมที่ไม่ดีจริง ๆ หรือไม่?

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

• ตัวบ่งชี้ที่ไม่มีความหมาย

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

• ความรับผิดชอบเศษส่วน

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

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

• สิ่งที่เป็นนามธรรมที่ไม่มีโครงสร้าง

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

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

เราเขียนDispatcherของEventอินสแตนซ์สำหรับหลักเหตุผลเดียวกันกับที่เราเขียนGarbageCollectorหรือFactory:

ผู้จัดการรู้ว่าอะไรที่เพย์โหลดไม่ควรต้องรู้

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

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

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

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

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

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

คำตอบสั้น ๆ : มันขึ้นอยู่กับ

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

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

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

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

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

คลาสผู้จัดการสามารถเป็นสัญลักษณ์ของสถาปัตยกรรมที่ไม่ดีได้หรือไม่?

คุณตอบคำถามของคุณ: พวกเขาไม่จำเป็นต้องเป็นสัญลักษณ์ของการออกแบบที่ไม่ดี

ยกเว้นตัวอย่างในคำถามของคุณที่มี EventManager มีอีกตัวอย่าง: ในรูปแบบการออกแบบMVCผู้นำเสนอสามารถมองเห็นเป็นผู้จัดการสำหรับคลาส / มุมมองโมเดล

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

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

ชื่อคลาสที่แย่ที่สุดที่ฉันเคยเห็นคือ "DataContainerAdapter"

"ข้อมูล" ควรเป็นหนึ่งในสารตั้งต้นที่ถูกแบนในชื่อนั่นคือข้อมูลทั้งหมด "ข้อมูล" ไม่ได้บอกคุณมากในโดเมนส่วนใหญ่

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

ทำไม? ชื่อ "-er" บอกเป็นนัยว่าผู้ออกแบบโค้ดใช้เวลาดำเนินการบางอย่างและแปลงเป็นคลาส ด้วยเหตุนี้เราจึงมีสิ่งประดิษฐ์ที่ไม่สะท้อนแนวคิดที่จับต้องได้ แต่เป็นการกระทำบางอย่าง ฟังดูเป็นขั้นตอนมาก

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

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

วัตถุดังกล่าวไม่จำเป็นต้องถูกควบคุม พวกเขารู้ว่าต้องทำอะไรและทำอย่างไร ดังนั้นคลาสผู้จัดการจะทำลายหลักการ OOP สองครั้ง นอกจากจะเป็นคลาส "-er" มันยังควบคุมวัตถุอื่น ๆ แต่มันก็ขึ้นอยู่กับผู้จัดการว่า เขาควบคุมมัน - เขาเป็นผู้จัดการที่ไม่ดี ถ้าเขาประสานงาน - เขาเป็นผู้จัดการที่ดี นั่นเป็นสาเหตุที่ตัวอักษร "C" ในMVCควรสะกดเป็น "ผู้ประสานงาน"

คำตอบที่ถูกต้องสำหรับคำถามนี้คือ:

1. มันขึ้นอยู่กับ.

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