รูปแบบ“ ศูนย์การแจ้งเตือน” ส่งเสริมการออกแบบโปรแกรมที่ดีหรือไม่ดีหรือไม่?

บางครั้งฉันเจอ API สไตล์ฮับข้อความเช่น Cocoa NSNotificationCenter: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSNotificationCenter_Class/Reference/Reference.html

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

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

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

แก้ไข: ฉันเดาว่าปัญหาที่ใหญ่ที่สุดของฉันในรูปแบบนี้คือ API "โกหก" เกี่ยวกับการพึ่งพาและข้อต่อวัตถุและสามารถแสดงด้วยตัวอย่างนี้:

myObj = new Foo();
myOtherObj = new Bar();
print myOtherObj.someValue; // prints 0
myObj.doSomething();
print myOtherObj.someValue; // prints 1, unexpectedly, because I never indicated that these objects had anything to do with each other

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

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

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

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

การส่งข้อความแบบอะซิงโครนัสเป็นสถาปัตยกรรมที่ดีสำหรับระบบขนาดใหญ่ที่ต้องขยาย

เทียบเท่า Java นี้คือ JMS และโดยทั่วไปถือว่าเป็นสิ่งที่ดี

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

คุณสามารถทำให้ URI ของฮับข้อความสามารถกำหนดค่าภายนอกและไม่ฝังในซอร์สโค้ดได้อย่างง่ายดาย

นี่คือการใช้รูปแบบ Oberserver ทั่วไป (หรือบางครั้งเรียกว่ารูปแบบฟังหรือบางครั้งเรียกว่ารูปแบบสมาชิก / ผู้เผยแพร่) ในแอปพลิเคชันที่มีพฤติกรรมนี้มีประโยชน์มันเป็นรูปแบบที่ดีที่จะใช้ ไม่ควรใช้รูปแบบหากไม่เพิ่มมูลค่าให้กับโซลูชัน

จากคำถามของคุณดูเหมือนว่าคุณกังวลว่าทุกอย่างรู้เกี่ยวกับ NotificationCenter และสิ่งทั่วโลกเป็นสิ่งที่ไม่ดี บางครั้งใช่สิ่งที่ทั่วโลกไม่ดี แต่ลองดูทางเลือกอื่น สมมติว่าคุณมี 2 องค์ประกอบตัวอย่างนี้มันไม่สำคัญว่าพวกมันจะทำอะไรหรือมันเป็นอะไร Component1 มีข้อมูลบางอย่างที่ดำเนินการหรือเปลี่ยนแปลงในทางใดทางหนึ่ง Component2 ต้องการทราบเกี่ยวกับการเปลี่ยนแปลงข้อมูลประเภทที่ Compoent1 จัดการ Component2 ควรรู้เกี่ยวกับการมีอยู่ของ Component1 หรือไม่ หรือมันจะดีกว่าสำหรับ Component2 สมัครสมาชิก / ฟังข้อความที่บอกว่าส่วนประกอบบางส่วนในแอพเปลี่ยนข้อมูลบางส่วนที่มันสนใจ ทีนี้ลองดูตัวอย่างนี้แล้วคูณมันด้วยส่วนประกอบหลายสิบอย่างหรือมากกว่านั้นและคุณสามารถดูได้ว่าค่าของรูปแบบนั้นอยู่ที่ไหน

มันเป็นโซลูชั่นที่สมบูรณ์แบบสำหรับทุกสถานการณ์หรือไม่ มันเป็นนามธรรมในการสื่อสารระหว่างองค์ประกอบและให้การมีเพศสัมพันธ์ที่หลวมมากขึ้นใช่

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