ความแตกต่างระหว่าง Observer, Pub / Sub และ Data Binding

คือความแตกต่างระหว่างสิ่งที่รูปแบบสังเกตการณ์ , เผยแพร่ / สมัครสมาชิกและการผูกข้อมูล ?

ฉันค้นหาใน Stack Overflow เล็กน้อยและไม่พบคำตอบที่ดี

สิ่งที่ฉันเชื่อคือการผูกข้อมูลเป็นคำทั่วไปและมีวิธีการใช้งานที่แตกต่างกันเช่นรูปแบบการสังเกตการณ์หรือรูปแบบ Pub / Sub ด้วยรูปแบบ Observer Observable จะอัพเดต Observers ด้วย Pub / Sub ผู้เผยแพร่โฆษณาจำนวนมากสามารถเผยแพร่ข้อความของบางคลาสและสมาชิกจำนวนมากสามารถสมัครสมาชิกข้อความของคลาสที่ต้องการได้

มีรูปแบบอื่น ๆ ของการใช้ "การผูกข้อมูล" หรือไม่?

นี่คือสิ่งที่ฉันใช้ในสามข้อ:

การผูกข้อมูล

โดยพื้นฐานแล้วที่แกนกลางนี่หมายถึง "คุณค่าของ X ทรัพย์สินในวัตถุ Y ถูกผูกมัดความหมายกับมูลค่าของทรัพย์สิน A บนวัตถุ B ไม่มีการสันนิษฐานว่า Y รู้หรือได้รับการเปลี่ยนแปลงในวัตถุ B อย่างไร

ผู้สังเกตหรือสังเกต / สังเกตการณ์

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

ผับ / ตำบล

ชื่ออื่น (อาจจะมีความหมาย "ออกอากาศ" มากกว่า) ของรูปแบบการสังเกตการณ์ / ผู้สังเกตการณ์ซึ่งโดยปกติจะหมายถึงรสชาติ "แบบไดนามิก" ที่มากขึ้น - ผู้สังเกตการณ์สามารถสมัครสมาชิกหรือยกเลิกการสมัครรับการแจ้งเตือนและอีกคนหนึ่ง ใน. NET หนึ่งสามารถใช้เหตุการณ์มาตรฐานสำหรับเรื่องนี้เนื่องจากเหตุการณ์เป็นรูปแบบของ MulticastDelegate และสามารถรองรับการส่งกิจกรรมไปยังผู้สมัครสมาชิกหลายคนและยังสนับสนุนการยกเลิกสมาชิก ผับ / ย่อยมีความหมายที่แตกต่างกันเล็กน้อยในบริบทบางอย่างมักจะเกี่ยวข้องกับ "ตัวตน" ระหว่างเหตุการณ์และ eventer มากขึ้นซึ่งสามารถอำนวยความสะดวกโดย abstractions จำนวนใด ๆ มักจะเกี่ยวข้องกับ "คนกลาง" บางคน (เช่นคิวข้อความ) ที่รู้ทั้งหมด ฝ่าย แต่ฝ่ายบุคคลไม่รู้เกี่ยวกับกันและกัน

Data Binding, Redux

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

การผูกข้อมูลใหม่ Redux

อีกทางเลือกหนึ่งสำหรับการผูกข้อมูล? ตกลงนี่เป็นคนโง่:

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

มีสองความแตกต่างที่สำคัญระหว่างรูปแบบการสังเกตการณ์ / สังเกตได้และผู้เผยแพร่ / สมาชิก:

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

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

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

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

สิ่งหนึ่งที่ควรทราบคือ: เป้าหมายของรูปแบบเหล่านี้คือพยายามแยกโค้ดออก

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

รูปแบบการสังเกตการณ์

นี่หมายถึงการobservable objectมีรายการที่มันเก็บทั้งหมดobservers(ซึ่งมักจะมีฟังก์ชั่น) และสามารถข้ามรายการนี้และเรียกใช้ฟังก์ชันเหล่านี้เมื่อรู้สึกดี

ดูตัวอย่างรูปแบบของผู้สังเกตการณ์นี้เพื่อดูรายละเอียด

รูปแบบนี้ดีเมื่อคุณต้องการฟังการเปลี่ยนแปลงข้อมูลใด ๆ บนวัตถุและอัปเดตมุมมอง UI อื่น ๆ ตามลำดับ

แต่จุดด้อยคือสิ่งที่สังเกตได้มีเพียงหนึ่งอาร์เรย์ในการรักษาผู้สังเกตการณ์ (ในตัวอย่างคืออาร์เรย์observersList)

มันไม่ได้แยกความแตกต่างว่ามีการเรียกใช้การปรับปรุงอย่างไรเนื่องจากมีเพียงหนึ่งnotify functionฟังก์ชันเท่านั้นซึ่งจะเรียกใช้ฟังก์ชันทั้งหมดที่เก็บไว้ในอาร์เรย์นั้น

ถ้าเราต้องการจัดกลุ่มตัวจัดการผู้สังเกตการณ์ตามเหตุการณ์ต่าง ๆ เราแค่ต้องปรับเปลี่ยนสิ่งนั้นobserversListให้Objectเหมือนกัน

var events = {
    "event1": [handler1, handler2],
    "event2": [handler3]
}

ดูตัวอย่าง pubsub นี้เพื่อดูรายละเอียด

pub/subและคนเรียกรูปแบบนี้เป็น ดังนั้นคุณสามารถเรียกใช้ฟังก์ชั่นต่าง ๆ ตามที่eventsคุณเผยแพร่

ฉันเห็นด้วยกับข้อสรุปของคุณเกี่ยวกับรูปแบบทั้งสอง แต่สำหรับฉันฉันใช้ Observable เมื่อฉันอยู่ในกระบวนการเดียวกันและฉันใช้ Pub / Sub ในสถานการณ์ระหว่างกระบวนการที่ทุกฝ่ายรู้ช่องทางทั่วไป แต่ไม่ใช่ฝ่าย .

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

หากคุณสนใจในการสื่อสารระหว่างกระบวนการฉันขอแนะนำให้คุณ:

"รูปแบบการรวมในระดับองค์กร: การออกแบบการสร้างและการปรับใช้โซลูชันการส่งข้อความ" - http://www.addison-wesley.de/9780321200686.html

หนังสือเล่มนี้มีแนวคิดมากมายเกี่ยวกับวิธีการส่งข้อความระหว่างกระบวนการหรือคลาสที่สามารถใช้งานได้แม้ในงานการสื่อสารภายในกระบวนการ (มันช่วยให้ฉันเขียนโปรแกรมในลักษณะหลวมมากขึ้น)

ฉันหวังว่านี่จะช่วยได้!