الگوی طراحی مشاهده گر در پایتون

معرفی

نرم افزار الگوهای طراحی به تسریع توسعه کمک کند process با ارائه طرحی قابل استفاده مجدد برای کد خود برای حل یک مشکل خاص. ما از الگوهای طراحی پیروی می‌کنیم تا کدهای تعمیم‌یافته، قابل استفاده مجدد و خواندنی بنویسیم که توسط دیگران آشنا با الگوهایی که ما اعمال کرده‌ایم به راحتی قابل درک باشد.

آنها تجربه انباشته مهندسان نرم افزار را در حل مشکلات مشابه در بر می گیرند و راه حل هایی را برای مسائل رایج مرتبط با طراحی نشان می دهند.

بسته به طبقه بندی های مختلفی از الگوهای طراحی وجود دارد روی کدام طبقه از مشکلات را حل می کنند – در میان آنها الگوی طراحی ناظر متعلق به الگوی رفتاری کلاس

این دسته از الگوها روش ارتباط اشیاء با یکدیگر را تعیین می کند. در این راهنما، همه چیزهایی را که باید در مورد الگوی طراحی Observer بدانید، یاد خواهید گرفت و متوجه خواهید شد که چگونه می‌توانیم از آن برای حل مؤثر مشکلات خاص استفاده کنیم.

الگوی طراحی ناظر

را الگوی طراحی ناظر با یک به چند روابط و استفاده می کند مناسبت ها اجازه دادن نهادهای مشترک از تغییرات در یک قابل مشاهده.

منشأ این وقایع را می نامند موضوع یا قابل مشاهده که رویدادها را به صورت جریانی ارسال می کند. را ناظران یا غرق می شود می توانید برای به دست آوردن رویدادها در مشاهدات مشترک شوید. قابل مشاهده لیست مشاهده کنندگان را ردیابی می کند و هنگامی که وضعیت مشاهده تغییر می کند آنها را از تغییرات مطلع می کند.

این قابلیت مفاهیم و پیاده سازی های زیادی دارد و عملکرد مشابهی در اطراف شما وجود دارد. این یک الگوی بسیار ساده و در عین حال بسیار مؤثر و گسترده است.

اجرای مشابه این الگوی طراحی در تولید خوراک دیده می شود روی پلتفرم های اجتماعی شما – Pub/Sub (ناشر/مشترک) مدل/الگو. هنگامی که یک ناشر محتوا پست های خود را منتشر می کند، مشترکین از محتوا مطلع می شوند. یک قیاس مشابه ممکن است افرادی باشد که به دنبال یک سیگنال شعله ور یا آتش بازی برای یک رویداد خاص هستند و بسته به آن واکنش نشان می دهند (یا نه). روی نقش های خاص آنها

آیا این بدان معناست که الگوی طراحی ناظر و الگوی انتشار/اشتراک همان هستند؟

قبلاً هر دو الگو مترادف بودند. امروزه، هر الگو دارای ویژگی های متمایز است که آنها را به دو الگوی مجزا تبدیل می کند.

تفاوت‌های عمده بین الگوی مشاهده‌گر و الگوی Pub/Sub به شرح زیر است:

• مشاهده‌کنندگان و سوژه‌ها به شدت با هم مرتبط هستند. آزمودنی ها باید ناظران خود را پیگیری کنند. در حالی که در الگوی Pub/Sub، آنها با صف پیام بین ناظران و آزمودنی‌ها به صورت آزاد همراه هستند.
• رویدادها به صورت همزمان از سوژه ها به ناظران منتقل می شوند. اما در الگوهای Pub/Sub رویدادها به صورت ناهمزمان منتقل می شوند.
• در الگوی مشاهده‌گر، هم سوژه‌ها و هم مشاهده‌کنندگان قرار دارند روی همان محل برنامه در حالی که آنها می توانند اقامت داشته باشند روی مکان های مختلف در الگوی Pub/Sub.

یکی از بهترین راه ها برای درک این الگو پیاده سازی آن است، بیایید آن را در پایتون پیاده سازی کنیم!

پیاده سازی

یک پیاده سازی اساسی به دو کلاس نیاز دارد – یک Observable و یک Observer. را Observer کلاس با یک شی به عنوان آرگومان مقداردهی اولیه می شود. شی چیزی نیست جز یک Observable برای پیگیری، که پس از ایجاد مشترک است.

کلاس نیز دارای notify() تابع، که واکنشی را آغاز می کند و دریافت اعلان/رویداد از قابل مشاهده را تأیید می کند:

class Observer:

    def __init__(self, observable):
        observable.subscribe(self)

    def notify(
        self,
        observable,
        *args,
        **kwargs
        ):
        print ('Got', args, kwargs, 'From', observable)

را Observable کلاس با یک لیست خالی برای نگه داشتن آن مقداردهی اولیه می شود Observer نمونه ها همچنین دارای عملکردهایی مانند subscribe() برای افزودن یک ناظر ، notify_observers() برای تماس با notify() تابع روی هر ناظر ، و unsubscribe() برای حذف ناظر از لیست:

class Observable:

    def __init__(self):
        self._observers = ()

    def subscribe(self, observer):
        self._observers.append(observer)

    def notify_observers(self, *args, **kwargs):
        for obs in self._observers:
            obs.notify(self, *args, **kwargs)

    def unsubscribe(self, observer):
        self._observers.remove(observer)

با وصل کردن تمام مؤلفه‌های ذکر شده در بالا، اجازه دهید کدی بنویسیم که یک مشاهده‌گر و قابل مشاهده را تنظیم می‌کند و پیام‌هایی را ارسال می‌کند که باعث واکنش می‌شود:

"""
Demonstrating the Observer pattern implementation
"""

subject = Observable()


observer1 = Observer(subject)
observer2 = Observer(subject)


subject.notify_observers('This is the 1st broadcast',
                         kw='From the Observer')
subject.unsubscribe(observer2)



subject.notify_observers('This is the 2nd broadcast',
                         kw='From the Observer')

توجه داشته باشید که قبل از انتشار پیام دوم، اشتراک یک ناظر را نیز لغو می کنیم. این باعث می شود که پیام به جای دو بار فقط یک بار چاپ شود روی تلاش دوم، زیرا تنها توسط یک مشترک دریافت می شود.

اجرای این کد منجر به موارد زیر می شود:

$ python observer_pattern.py
Got ('This is the 1st broadcast',) {'kw': 'From the Observer'} From <__main__.Observable object at 0x7f6c50d2fb50>
Got ('This is the 1st broadcast',) {'kw': 'From the Observer'} From <__main__.Observable object at 0x7f6c50d2fb50>
Got ('This is the 2nd broadcast',) {'kw': 'From the Observer'} From <__main__.Observable object at 0x7f6c50d2fb50>

همانطور که می بینید، قابل مشاهده می تواند به طور مستقیم با ناظران تعامل داشته باشد و بالعکس. تا زمانی که ناظر در فهرست اشتراک مشاهده پذیر مشترک باشد، مشاهده پذیر با مشاهده گر در تعامل خواهد بود.

مزایا و معایب

با پیاده سازی در محل، مزایا و معایب این الگوی طراحی را می توان به شرح زیر مقایسه کرد:

طرفداران

• رابطه یک به چند بین اشیا تعریف شده است. این تضمین می‌کند که وقتی یک شی تغییر می‌یابد، منجر به ایجاد آبشاری از تغییرات می‌شود که بر روی اشیاء وابسته اعمال می‌شود.

• اشیاء با اتصال آزاد به این معنی است که اجزا می توانند تعویض شوند.

منفی

• ارتباط بین مشاهده‌پذیر و مشاهده‌گر همزمان است و با افزایش بار رویدادهای اشتراک و لغو اشتراک، شی قابل مشاهده می‌تواند با درخواست‌ها بمباران شود. این می تواند با تنظیم زمان خواب برای هر درخواست کاهش یابد.

• راه حل خواب همچنین می تواند باعث از دست دادن احتمالی سرعت، عملکرد و رویدادها شود. این دلیل اصلی ایجاد صف پیام بین ناشر و مشترک در الگوی Pub/Sub بود.

• نشت حافظه در این الگو رایج است زیرا یک مرجع قوی بین مشاهده گر و قابل مشاهده وجود دارد. موارد قابل مشاهده باید به طور اجباری از شی قابل مشاهده حذف شوند.

برای کاهش بیشتر معایب، یک صف پیام بین مشاهده‌گر و مشاهده‌پذیر برای غلبه بر همه این مشکلات معرفی شد، که منجر به ابداع الگوی Pub/Sub – نوعی از الگوی مشاهده‌گر (Observer Pattern) شد.

نتیجه

این راهنما الگوی Observer، روش اجرای آن را پوشش می‌دهد و جوانب مثبت و منفی آن را با هم مقایسه می‌کند.

جالب است بدانید که الگوی مشاهده گر یکی از الگوهای رفتاری است که به بسیاری از ویژگی هایی که امروزه استفاده می کنیم، مانند فیدهای RSS، فید رسانه های اجتماعی و غیره منجر شده است.

با آشنا شدن با تفاوت های ظریف الگوهای طراحی، ساختن عملکرد از پایه آسان تر است. و البته، دانستن الگوهای طراحی مختلف به شما امکان می دهد بهترین راه حل را برای انواع مختلف مشکلات بسازید.