https://virgool.io/feed/@alirezadp10 در حال حاضر: مطالبی که میخونم رو اینجا بازنشر میکنم fa 2026-06-10 16:07:05 https://files.virgool.io/upload/users/864343/avatar/sq6XaS.jpeg?height=120&width=120 https://virgool.io/@alirezadp10 https://virgool.io/@alirezadp10/choosing-between-an-interface-and-an-abstract-class-onte9lt20qwt They accomplish the same result; it depends on what you’re trying to do.During a few interviews, I’ve been asked to explain the difference between an interface and an abstract class and when I would choose one over the other.Because this happened so much, I’m going to define each one and explain the difference between the two, and give an example of when to choose one over the other.I will use Java to write sample code, but the concept should be similar in other languages as well.What Is an Interface?An interface is a behavioral contract between multiple systems.That means any class that implements an interface guarantees and must provide some implementation for all of its methods. All methods in an interface must be public and abstract.The interface definition looks like this:public interface Movable { public void accelerate(); public void decelerate(); } public interface Drivable{ public void drive(); }What Is an Abstract Class?An abstract class is prefixed by the abstract keyword in its declaration and is a guideline created for its derived concrete classes. Abstract classes must have at least one abstract method and provide the implementation for its non-abstract methods.If you define an abstract class with implementation, then you may need to consider whether going with an interface would be a better choice.Abstract class definition looks like this:public abstract class Vehicle { public void getReady(){ System.out.println(&quotI'm all set and ready to go&quot); } public abstract void start(); public abstract void stop(); }To bring it all together, let’s create a Bus class that extends the Vehicle abstract class and implements both Drivable and Movable interfaces.public class Bus extends Vehicle implements Drivable, Movable { @Override public void Drive() { System.out.println(&quotDriving...&quot); } @Override public void accelerate() { System.out.println(&quotaccelerating...&quot); } @Override public void decelerate() { System.out.println(&quotdecelerating...&quot); } @Override public void start() { System.out.println(&quotStarting engine...&quot); } @Override public void stop() { System.out.println(&quotShutting down engine...&quot); } }Differences and SimilaritiesAll methods in an interface are public and abstract implicitly. Abstract classes can use public, partial, protected, and static access modifiers for their methods.Classes can implement multiple interfaces, but only one abstract class. Abstract classes can contain non-abstract methods.They can both have methods, variables, and neither one can be instantiated. All variables declared in an interface are final, while an abstract class may contain non-final variables.Which One to ChooseIf you need to provide some implementation or need a base class, then an abstract class is the way to go.For instance, maybe you want to make sure to initialize some variables in a class to perform logic in a helper method which all derived classes can use, choosing to go with an abstract class is the right choice.If you need to provide additional behavior for your classes, then interfaces are the way to go.The same functionalities can be accomplished with both, however, when considering coding standards, an interface helps you accomplish abstraction and polymorphism, which are two of the main four OOP principles.It also makes it easier to keep your code loosely coupled instead of tightly coupled, which happens when high-level modules depend on low-level modules.Interfaces are also used for dependency injection (a.k.a. DI/IoC) and make it easier to mock derived classes while testing.Thank you for reading. Happy coding!Reference alirezadp10 alirezadp10 Mon, 23 Aug 2021 17:57:06 +0430 https://virgool.io/@alirezadp10/aop-%DA%86%DB%8C%D8%B3%D8%AA-gfauyfcupe7f شاید قبلاً نام AOP (سرنام Aspect Oriented Programming) را شنیده باشید. بسیاری از ما اولین بار که این نام را شنیدیم با تصور این که AOP نیز یکی از آن پارادایم‌هایی است که هر چند سال یکبار برای جایگزینی برنامه‌نویسی شیء‌گرا مطرح می‌شوند، بی‌تفاوت آن را کنار گذاشتیم. اما داستان AOP، طولانی‌تر از این حرف‌ها است. زمان آن رسیده که کمی خاک شیوه برنامه‌نویسی خود را بگیرید. مکاشفات جذابی وجود دارد.بسیاری از افراد معتقدند، علوم کامپیوتر آن قدرها هم که به‌نظر می آید، سریع پیشرفت نمی‌کند. آن‌ها معتقدند، در بسیاری از شاخه‌ها کار تقریباً تمام شده‌است و کارهای جدید فقط در حد پیشرفت‌های جزئی انجام می‌گیرد. در حقیقت، بعضی از موضوع‌های مطرح شده توسط این گروه بدبین، تا حدودی به واقعیت نزدیک است. بسیاری از پایه‌های علوم کامپیوتر شکل گرفته است و به نظر میآید تغییر آن‌ها، دست‌کم به این زودی‌ها امکان‌پذیر نیست. در بعضی از شاخه‌ها یک فناوری آن‌چنان جای پایش را محکم کرده‌است که حتی تصور وجود روشی دیگر کمی سخت به نظر می‌رسد.اما کامپیوتری‌ها مردم جالبی هستند. شاید آن‌ها خیلی پرکار نباشند، اما همیشه ایده‌های جدید و خلاقانه راهی برای نفوذ به درون دنیایشان پیدا می‌کنند. شاید در بسیاری از زمینه‌ها، کار شما به مطالعه کارهای کلاسیک انجام شده محدود شود، اما همیشه جاده‌های جدیدی وجود دارد.گریگور کیزالس (Gregor Kiczales)، بیشتر وقت خود را در آزمایشگاه پارک (PARC) که مبدأ شروع بسیاری از خلاقیت‌های بزرگ حوزه علوم کامپیوتر بوده، گذرانده است. محیط صنعتی - آکادمیک آزمایشگاه علاوه بر دل‌مشغولی‌های آکادمیک، کیزالس را به مسائل و مشکلات حوزه نرم‌افزار در دنیای واقعی آشنا ساخته است. در حقیقت، یکی از همین مشکلات (Cross-cutting Concern) بود که منجر به ارائه مدل AOP توسط این پروفسور دانشگاه UBC و همکارانش در زیراکس پارک شد. مدلی که به تحرکات زیادی در حوزه نرم‌افزار منجر شد تا جایی که Daniel Sabbah، معاون بخش استراتژی‌های نرم‌افزاری شرکت آی‌بی‌ام درباره آن می‌گوید: «زمان توسعه نرم‌افزارها به وسیله مفهوم Aspect-Oriented فرا رسیده‌است. صنعت نرم‌افزار به آن نیاز دارد و آی‌بی‌ام در حال حاضر از آن استفاده می‌کند.»اولین ارائه رسمی از این موضوع به سال 1997 برمی‌گردد. البته، اطلاعات تاریخی درباره AOP بسیار اندک است و ما از روند کار چیز زیادی نمی‌دانیم. کیزالس خود در پاسخ به پرسش نگارنده پیرامون تاریخچه و روند شکل‌گیری AOP می‌گوید: «متأسفانه هیچ تاریخ مدونی برای AOP وجود ندارد.» در این مقاله سعی کرده‌ایم معرفی مناسبی از این پارادایم جدید برنامه‌نویسی ارائه دهیم.چرا از پارادایم استفاده می‌کنیم؟توماس کوهن، پارادایم را این‌گونه تعریف می‌کند: «پارادایم در نتیجه فعالیت‌های اجتماعی ظاهر می‌شود که در آن مردم ایده‌هایشان را توسعه می‌دهند و قواعد و مثا‌ل‌هایی می‌سازند که این ایده‌ها را بیان کند.» این شاید یکی از رسمی‌ترین تعریف‌هایی باشد که در سراسر عمرتان برای پارادایم می‌شنوید. اما این جمله زیبا برای یک برنامه‌نویس چه معنایی دارد؟کامپیوترهای اولیه توسط کدهای باینری برنامه‌ریزی می‌شدند و برنامه‌نویس، با ارسال دنباله‌ای از صفر و یک ها به پردازنده مرکزی به‌طور مستقیم برای آن کامپیوتر برنامه‌نویسی می‌کرد. با گذشت زمان، زبان‌هایی با سطوح بالاتر عرضه شدند. اسمبلی، C و جاوا نمونه‌ای از زبان‌های نسل‌های مختلف هستند. با معرفی هر نسل، نحوه نوشتن برنامه و نگرش به مفاهیم نیز در آن تغییر می‌یافت. ارائه شیوه‌های جدید تولید نرم‌افزار به امید ایجاد راه‌های بهتر برای طراحی و پیاده‌سازی یک برنامه، هنوز نیز ادامه دارد. روش پایه‌ای برنامه‌نویسی را که در بالا بیان شد، پارادایم برنامه‌نویسی می‌نامند. در حقیقت، پارادایم‌ها چهارچوب کلی معماری یک برنامه و نحوه ارتباط اجزای آن با یکدیگر را مشخص می‌کنند. با ذکر مثال‌هایی از پارادایم‌های مختلف، مفهوم را روشن‌تر می‌کنیم.شاید برنامه‌نویسی رویه‌ای (Procedural Programming) اولین پارادایم مطرح‌شده برای زبان‌های برنامه‌نویسی است. در این پارادایم، اعمال، مرحله به مرحله توسط فراخوانی رویه‌هایی که برای انجام کارهای مختلف نوشته می‌شوند، انجام می‌گیرند. این مدل با مشخص کردن ترتیبی برای فراخوانی رویه‌ها یکی‌یکی آن‌ها را اجرا می‌کند و با اتمام کار هر کدام رویه بعدی اجرا می‌شود. در حقیقت، برنامه‌نویسی رویه‌ای، ادامه ایده کلی‌تری به‌نام برنامه‌نویسی امری (Imperative Programming) است. به‌طور ساده استراتژی این مدل برنامه‌نویسی به این صورت است که تعدادی دستور وجود دارند که باید توسط کامپیوتر اجرا شوند. زبان‌های امری دقیقاً مانند اسمشان عمل می‌کنند: اول این کار را انجام بده، بعد آن را و... .برنامه‌نویسی شیءگرا نیز در بیشتر مواقع مثالی از مدل امری است، زیرا در آن‌جا نیز روش کار برنامه عموماً به صورت اجرای سلسله‌ای از دستورها است. اگرچه معمولاً برنامه‌نویسی شیءگرا به صورت یک مدل جداگانه مورد بررسی قرار می‌گیرد. در مقابل مدل برنامه‌نویسی امری، مدل اعلانی (Declarative) قرار دارد. در این مدل تمرکز روی ماهیت چیزها است نه نحوه کارکرد آن‌ها. در مدل اعلانی آن‌چه اهمیت دارد، توصیف این است که یک جزء برنامه چگونه است، نه این‌که چگونه ساخته می‌شود. اگر برنامه خود را به دو قسمت منطق و کنترل تقسیم کنید، در مدل اعلانی شما منطق برنامه خود را در اختیار می‌گیرید و نگران آن‌چه در بخش کنترل اتفاق می‌افتد، نیستید. مثال بارز این‌گونه زبان‌ها، HTML است. با توجه به نزدیک بودن ساختار مدل اعلانی به ساختار ریاضیات، اثبات درستی یک برنامه در این مدل راحت‌تر انجام می‌گیرد. به همین دلیل، مدل اعلانی در نوشتن برنامه‌هایی که باید درستی آن‌ها به صورت یک حکم ریاضی ثابت شود، کاربرد فراوانی دارد. عموماً زبان‌های مدل امری در محیط‌های کاری از محبوبیت بیشتری برخوردارند، اما نمی‌توان از تأثیر مدل اعلانی در ساخت برنامه‌های علمی (به خصوص ریاضی) به سادگی گذشت. این معرفی بسیار کوتاه از پارادایم‌ها فقط برای این بود که بدانیم آن‌ها واقعاً یکی نیستند! هر پارادایم، یک سبک برنامه‌نویسی و از آن مهم‌تر یک سبک نگرش را به دنبال دارد که می‌تواند تعاریف و اصول یک برنامه‌نویس را دگرگون سازد. پارادایم‌ها قطعاً به وجود نیامده‌اند که معجزه کنند، بلکه قرار است کار را برای برنامه‌نویسان راحت‌تر سازند.Aspect-Oriented Programming نیز، که در واقع در ادامه مدل OOP عرضه شد، یک پارادایم برنامه‌نویسی است که در ادامه به معرفی آن می‌پردازیم.وقتی OOP جواب‌گو نیست‌...سناریوی زیر را در نظر بگیرید: فرض کنید شما مسئول طراحی وب‌سایت برای یک شرکت فروش آنلاین لباس شده‌اید. این سایت، مانند بیشتر سایت‌های دنیا دو بخش دارد: بخش نخست برای مشتریان که می‌توانند در آن اجناس را مشاهده کنند و آن‌ها را بخرند. بخش دوم نیز برای انجام کارهای اداری خود شرکت است که فقط کارمندان خاصی به آن دسترسی دارند. به‌عنوان مثال، اضافه کردن اقلامی به فروشگاه آنلاین یا بررسی کردن حساب بعضی از مشتری‌ها. شما و گروه برنامه‌نویسی با تلاشی قابل ستایش سایتی بسیار جامع و زیبا طراحی می‌کنید و آن را به شرکت ارائه می‌دهید. اما روزی که برای دریافت حق‌الزحمه خود می‌روید، متوجه می‌شوید که همه از دست شما عصبانی هستند. کارمندان نمی‌توانند البسه جدید را وارد فهرست فروشگاه کنند، کاربران سایت در حال افزایش اعتبار حساب کاربری خود به صورت دستی هستند! ایمیل کاربران با فرمت اشتباه ذخیره شده است، پیگیری فروش روز‌های قبل در مواردی دچار مشکل می‌شود و... . مشکل چیست؟با افزایش پیچیدگی در یک برنامه نحوه کنترل شما روی روند رشد آن نیز دشوارتر می‌شود. با این که ممکن است در بسیاری از قسمت‌های برنامه کارهایی شبیه به هم انجام دهید، اما جا انداختن یکی از این کارها در هر یک از قسمت‌ها می‌تواند کارایی کل برنامه شما را زیر سؤال ببرد. به مثال امنیت سایت فروش لباس باز می‌گردیم. شما متوجه می‌شوید با توجه به پیچیده شدن معماری سایت، بسیاری از کارهای ضروری را از قلم انداخته‌اید. در بسیاری از جاها فراموش شده که قبل از فراخوانی روش‌های امن (Secure) هویت کاربر مشخص شود تا فرد غیرمسئول نتواند به اطلاعات محرمانه دسترسی داشته باشد. در بسیاری از قسمت‌ها ورودی‌های اشتباهی که کاربران به صورت دستی به سیستم می‌دهند، تأیید اعتبار (Validate) نمی‌شوند و این باعث بروز سردرگمی در سیستم می‌شود. در ضمن در بعضی از روش‌ها با توجه به زیاد بودن کارهای حاشیه‌ای (مانند ثبت کردن عملیات یک سیستم (Logging)، تراکنش‌های پایگاه‌داده و مدیریت خطاها فراخوانی روش‌های بعضی کارها از قلم افتاده‌است. در نتیجه سایت کاملاً کارایی خود را از دست داده و عملاً به یک سیستم خراب تبدیل شده‌است. از تمام این موارد بدتر این‌که مشکلات شما به اینجا ختم نمی‌شود. وقتی درصدد اصلاح کدها بربیایید، می‌بینید این‌کار خیلی دشوارتر از آن است که تصور می‌کردید، زیرا کد هر قسمت آمیخته‌ای از روند کاری اصلی برنامه (Business Logic) و کارهای حاشیه‌ای مانند بررسی کردن امنیت و Logging و ... است. جداسازی کد به صورتی که بتوانیم بخش‌های مختلف را مورد بررسی قرار دهیم، کار بسیار مشکلی است و این‌کار شما و گروه طراحی را دشوارتر از قبل می‌کند.مشکل سایت قسمت بالا مشکل تمام سیستم‌های شیءگرا است. به کارهای مذکور که برای تمام قسمت‌های سایت یکسان هستند، Cross-Cutting Concern گفته می‌شود. در حقیقت، Cross-Cutting Concern ،Concernهایی هستند که در چندین قسمت سیستم مورد توجه قرار می‌گیرند (به‌عنوان نمونه، در مثال بالا بررسی امنیت و تراکنش‌های پایگاه‌داده و عملیات Logging).این Concernها معمولاً نمی‌توانند در یک ماجول به‌طور کامل کپسوله شوند. همان‌طور که در مثال مذکور می‌بینید، باید چندین فراخوانی هر کدام از آن‌ها را در سیستم‌های امنیتی بالا قرار دهیم تا بتوانند آن‌ها را به قسمت برقراری امنیت متصل کنند. Cross-Cutting Concern جایی است که دیگر مدل شیءگرا جواب کارآمدی به ما نمی‌دهد.AOP؛ تولد یک مفهوم‌در 1997 گریگور کیزالس و گروهش در زیراکس پارک مفهومی را معرفی کردند که Aspect Oriented Programming یا به اختصار AOP نامیده می‌شود. نام اولیه این پروژه تجزیه و سرهم کردن (Decomposition & Weaving) بود، اما بعدها به AOP تغییر نام داد. کیزالس درباره این موضوع می‌گوید: «این نظر یکی از اعضای گروه بود که به درستی اشاره کرد تلفظ این نام بسیار سخت است و در ضمن به نظر کمی زیادی Nerdy است.»AOP، در حقیقت به‌عنوان یک مکمل برای برنامه‌نویسی شیءگرا عرضه شد تا ضعف‌هایی را که در قسمت قبل به اختصار به آن اشاره کردیم پوشش دهد. کار اصلی AOP کار کردن با Cross-Cutting Concern ها است. اما بیایید دقیق‌تر به مفهوم AOP بپردازیم. شما برای نوشتن یک برنامه علاوه بر منطق کاری برنامه خود (که جریان اصلی برنامه است)، باید به‌طور هم‌زمان نگران بسیاری از کارهای حاشیه‌ای دیگر نیز باشید. سؤال‌هایی از قبیل: «اگر یک قسمت از برنامه مطابق پیش‌بینی کار نکرد، چه کنم؟» یا «چگونه امنیت را به برنامه‌ام تزریق کنم؟» یا حتی «چگونه مدیریت حافظه را انجام دهم؟»، سؤالاتی هستند که هر برنامه‌نویس در طول یک پروژه بارها از خود می‌پرسد. اما چگونه باید با این Concern ها کنار آمد؟ شاید به ذهن همه ما این فکر خطور کرده باشد که چه خوب بود اگر کارهای حاشیه‌ای و کد اصلی در دو فرآیند کاملاً جدا تولید می‌شدند تا علاوه بر افزایش Modularization، بتوانیم نگرانی‌های خود را تقسیم کنیم. در حقیقت این ایده، فکر اصلی پشت سر AOP است. البته انجام کارهای حاشیه‌ای در پشت صحنه ایده‌ای قدیمی‌تر از AOP است. به‌عنوان مثال، می‌توانید انجام مدیریت حافظه و Garbage Collection توسط JVM در زبان جاوا را در نظر بگیرید. شما می‌توانید کد خود را بدون نگرانی درباره مسائل مربوط به دو مورد ذکرشده در بالا بنویسید، زیرا جاوا خود با آن‌ها کنار می‌آید. انجام جداگانه کد و کارها باعث افزایش modularization می‌شود و همه برنامه‌نویسان می‌دانند که این افزایش می‌تواند چه‌قدر دنیا را زیبا کند!جان هانت می‌گوید: «من هنوز می‌توانم خودم را جلوی سورس کد یک برنامه تصور کنم در حالی‌که سعی می‌کنم منطق کاری پایه‌ای آن را از بقیه چیزهای دور و برش مجزا سازم.» شاید شما هم در غم او شریک باشید. درک سازوکار اصلی کارکرد یک برنامه، موضوع بسیار مهمی است که معمولاً بسیار سخت انجام می‌گیرد. زیرا تمام کد اصلی برنامه با جزئیات حاشیه‌ای (البته نه لزوماً از نوع پیش‌پا افتاده) مخلوط شده ‌است که علاوه بر مشغول ساختن ذهن کدنویس و کند کردن فرآیند عیب‌یابی، باعث می‌شود تا درک روند کاری اصلی کد نیز برای کسی که سعی در فهم آن دارد، بسیار مشکل شود. اما راه حل گروه کیزالس برای این موضوع چه بود؟ چیزی که آن‌ها عرضه کردند می‌توانست Cross-Cutting Concernها را به صورت یک ماجول جداگانه مورد بحث قرار دهد. ماجولی که علاوه بر عملیات اصلی که باید انجام دهد، در برگیرنده شرط اجرای این Concernها نیز است. بگذارید با ذکر یک مثال موضوع را مشخص کنیم. به همان بحث امنیت باز می‌گردیم. در مدل شیء‌گرا راه‌حل ما ساختن یک کلاس (یا یک روش در یک کلاس) برای بررسی بحث دسترسی کاربر موردنظر بود. پس از ساخت یک ماجول برای بررسی، با اضافه کردن عبارت‌های فراخوانی آن در قسمت‌های مختلف برنامه، کار را تکمیل می‌کنیم. در حقیقت، روند کاری در مدل شیء‌گرا در دو جا دنبال می‌شود. یکی کلاس یا روشی که برای بحث امنیت نوشته‌ایم،‌ یکی هم مکان‌های فراخوانی آن از کد اصلی برنامه.اما راه‌حل AOP متفاوت است. در AOP دو مکان قبلی (ماجول امنیت و مکان فراخوانی) تقریباً با یکدیگر ترکیب می‌شوند. به این ترتیب که شما کد مربوط به Concern (در مثال ما چک کردن امنیت) را در یک ماجول جداگانه قرار می‌دهید و سپس در همان ماجول شرط‌های فراخوانی این کد را ذکر می‌کنید (به‌عنوان مثال، درباره بحث موردنظر ما باید بررسی هویت در مواردی انجام شود که یک روش امن فراخوانی می‌شود). به این ترتیب، تمام روند کاری Cross-cutting Concernها از سازوکار اصلی برنامه مجزا می‌شوند. کاملاً مشخص است که این جدایی می‌تواند چه مزیت‌هایی را برای سیستم به ارمغان بیاورد. به‌عنوان مثال، می‌توان این دو بخش کد (کد اصلی و Cross-cutting Concernها) را به دو گروه مختلف برنامه‌نویسی واگذار کرد یا حتی درباره خود Cross-cutting Concernها می‌توان هر بخش را به خبره آن کار سپرد. مثلاً بخش بررسی کردن امنیت به متخصصان امنیت یا بخش تراکنش‌های پایگاه‌داده به متخصصان آن.شاید باز هم اصرار کنید که تمام این کارها با مدل شیءگرا نیز قابل دسترس بود (بحث کامل‌تری درباره این مقایسه در بخش آخر مقاله آمده است). البته درست می‌گویید! اما توجه داشته باشید که در یک مدل شیء‌گرا برنامه‌نویس باید از نکات زیر آگاهی داشته باشد:1- برنامه‌نویس باید از وجود چنین کلاس‌هایی که برای هماهنگ کردن این Cross-cutting Concernها ساخته شده است، خبر داشته باشد.2- باید Specification دقیق آن کلاس را بداند تا بتواند از آن استفاده کند.3- باید بداند دستور مربوط به فراخوانی روش‌های آن کلاس را کجای کد اصلی قرار دهد.در تمام این سه مرحله امکان رخ دادن خطا وجود دارد. به خصوص در قسمت آخر که فراموشی برنامه‌نویس برای فراخوانی تمام روش‌های لازم از شایع ترین اشتباه‌ها است. اما با استفاده از AOP، با توجه به جدا شدن دغدغه‌های برنامه‌نویسان این دو بخش چنین مشکلاتی اصولاً مطرح نمی‌شوند (البته مشکلات دیگری مطرح می‌شوند که چند نمونه از آن‌ها در قسمت آخر مقاله مطرح می‌شود). با استفاده از AOP می‌توانیم بدون تغییر کد اصلی، Concernهایی به آن اضافه کنیم که رفتارهای سیستم را تقویت کند. در بخش بعد به بررسی مفاهیم اصلی AOP می‌پردازیم.این یک AOP است...چه چیزی مُهر AOP را روی یک سیستم می‌زند؟ مسلماً معیار طراحی یک سیستم براساس AOP، این نیست که سازنده آن این‌گونه بگوید. این موضوع که آیا یک پروژه از AOP استفاده می‌کند یا خیر، به مکانیزم کاری آن پروژه و ماهیت نیازهای آن بستگی دارد. به‌عنوان مثال، کل عملیات مربوط به پرینت کردن یک سند را در نظر بگیرید. شما ممکن است در قسمت‌های مختلفی از برنامه خود عملیات پرینت کردن را نیاز داشته باشید. به این ترتیب، باید بارها روش‌های مربوط به آن را فراخوانی کنید. ممکن است با توجه به این تعاریف شما پرینت را به صورت یک Concern در نظر بگیرید. اما آیا این طراحی یک طراحی منطقی است؟ در تعریف Concernهایی که در AOP مورد توجه قرار می‌گیرند یک نکته فرعی وجود دارد و آن این است: این Concernها معمولاً به صورت یک ماجول جداگانه (در مدل های قبل از AOP) دسته‌بندی نمی‌شوند. این تعریف جواب سؤال بالا را مشخص می‌کند. در مثال بالا روش‌های مربوط به عملیات پرینت کردن برای برنامه‌نویس کاملاً مشخص است و مطرح کردن این نکته که او ممکن است فراموش کند که آن‌ها را فراخوانی کند تا حدودی خنده‌دار به نظر می‌آید. پس چندان منطقی نیست که پرینت کردن را به وسیله AOP پیاده‌سازی کنیم. عدم استفاده از AOP در مثال بالا بدیهی بود، اما ایده پشت این مطلب را مشخص می‌کند. AOP باید در مواردی به کار گرفته شود که به آن نیاز است. وقتی مکانیزمی که وجود AOP را می‌طلبد، موجود نیست می‌توانیم خیلی راحت از پارادایم های دیگر استفاده کنیم. پس باید قبل از استفاده از AOP نیازهای یک سیستم را کاملاً تحلیل کنیم تا لزوم یا عدم لزوم به کارگیری آن را مشخص سازیم. در ادبیات AOP، تعاریفی رسمی‌تر از مفاهیم اولیه آن وجود دارد که موارد استفاده AOP را روشن‌تر می‌کند.Quantification یا تعیین عناصر:Quantification ایده‌ای است که در آن یک برنامه‌نویس می‌تواند با نوشتن یک سری عبارت در قالب یک واحد و به صورت مجزا از بقیه سیستم، بسیاری از جاهای غیرمحلی برنامه را تحت‌تأثیر قرار دهد. درباره AspectهاQuantification می‌تواند به این صورت معنی شود که توانایی Aspectها برای اثرگذاری در نقاط مختلف یک برنامه است.Obliviousness یا فراموش‌کاری‌:Obliviousness بیانگر این ایده است که یک برنامه اطلاعی از این که یک Aspect کی و کجا اجرا می‌شود، ندارد. نتیجه این‌که شما نمی‌توانید با نگاه کردن به کد بگویید کدام Aspect اجرا می‌شود و این باعث ارتقای مفهوم جدا‌سازی می‌شود.تعریف Filman-Friedmanدو مفهوم ذکر شده در بالا (تعیین عناصر و فراموش‌کاری) از دیدگاه تعریف Filman-Friedman دو مفهوم لازم‌الاجرا در زمینه طراحی برنامه‌های Aspect Oriented هستند. در حقیقت، با توجه به این تعریف هر طراحی باید شامل هر دو ایده به‌طور کامل باشد. هرچند خیلی‌ها این دو تعریف را بسیار سخت‌گیرانه می‌دانند، زیرا برنامه‌های بسیاری با طراحی AOP وجود دارند که تنها به خاطر جلوگیری از اختلا‌ط دو کد، یکی از آن‌ها Aspect محسوب می‌شود که این طراحی لزوماً نقاط مختلف برنامه را مورد هدف قرار نمی‌دهد (مثال رعایت نشدن تعیین عناصر). همچنین در بعضی مواقع، برنامه‌نویسان AOP محل فراخوانی Aspect را با علا‌متی خاص مشخص می‌سازند (مثال رعایت نشدن فراموشکاری)دو اصطلاح Tangling و Scattering● پراکندگی: (Scattering) پیاده‌سازی یک Concern، پراکنده شده است هر گاه کد آن بین چند ماجول پخش شده باشد.● پیچش: (Tangling) پیاده‌سازی یک Concern، پیچیده شده‌است هر گاه کد آن با کد یک Concern دیگر مخلوط شده باشد.پراکندگی و پیچش در Aspect Oriented به‌عنوان علائم یک Cross-Cutting Concern در نظر گرفته می‌شوند. در حقیقت عموماً Concernهایی که چنین خصوصیاتی را در پیاده‌سازی‌های غیر AOP داشته باشند، مورد بحث قرار می‌گیرند.AOP در عمل‌باید اعتراف کرد که با وجود ارزشمند بودن توضیحات و تئوری‌های برنامه‌نویسی، تا وقتی که آن‌ها را در عمل، به وسیله برنامه‌نویسی مورد آزمایش قرار ندهیم، در حقیقت کار خاصی انجام نداده‌ایم. در ادامه سعی می‌کنیم مفاهیم مطرح شده را به همراه کد آن مورد بررسی قرار دهیم تا علاوه بر معرفی و تعریف مفاهیم موجود در AOP، با نحوه به کارگیری آنان نیز آشنا شویم، اما قبل از هر چیز باید به این سؤال پاسخ دهیم که کجا می‌توانیم AOPبنویسیم؟برای پاسخ دادن به این پرسش، ابتدا باید ببینید AOP چگونه اجرا می‌شود. برای نوشتن یک پروژه به صورت AOPشما ابتدا هر دو بخش کد خود را (اعم از روند کاری اصلی برنامه و کدهای مربوط به Aspectها) به صورت جداگانه در یک زبان شیءگرا می‌نویسید و سپس موجودی به نام Aspect Weaver آن دو بخش را با یکدیگر ترکیب کرده و کد نهایی را می‌سازد. جداسازی کد اصلی و کد Concernها (کد اصلی نیازی به اطلاع از بخش Concernها ندارد) به افزایش قابلیت استفاده دوباره‌ (Reusability) و قابلیت نگهداری (Maintainability) پروژه کمک شایانی می‌کند. شکل 1 نحوه کار Weaverها را نشان می‌دهد. دو نمونه بارز از ابزارهایی که می‌توان با استفاده از آن‌ها برنامه‌های Aspect-Oriented نوشت AspectJ و AspectWerkz هستند.AspectJ یک Extension است که برای زبان جاوا در زیراکس پارک و توسط گروه به‌وجود آورنده AOP نوشته شده‌است. این Extension به دو صورت تنها و تعبیه شده در Eclipse IDE عرضه می‌شود. AspectJ پتانسیل پشتیبانی از مدلRT Weaver را نیزدارد، اما برای بهره بردن از توانایی‌های آن باید از آن به‌صورت یک Compile-time Weaver استفاده کرد (هم‌اکنون به صورت Compile-time و loadtime عرضه می‌شود).Aspect Weaver !در حقیقت Aspect Weaver کد اصلی و کد Aspectها را به‌عنوان ورودی می‌گیرد و محصول نهایی را تولید می‌کند. توجه به این موضوع ضروری است که نگاه کلی به Weaverها مانند یک کامپایلر نیست، زیرا قرار نیست که تمام کارهای پیچیده‌ای را که یک کامپایلر انجام می‌دهد. Weaver نیز در مورد ترکیب دو بخش کد انجام دهد. در حقیقت، همان‌طور که خود کیزالس هم اشاره می کند، وظیفه Weaverها فقط Integration ) مجتمع‌سازی ) است. تکنیک‌های اولیه Weaving به دو دسته عمده تقسیم می‌شوند: Compile Time) CT) و Run-Time) RT Weaver)هایCT. همان‌طور که از نامشان پیدا است، تمام کارهای مربوط به ترکیب کد را در زمان کامپایل انجام می‌دهند و در حقیقت کد نهایی که اجرا می‌شود، محصول کامل است. در مقابل RTها این‌کار را در زمان اجرا انجام می‌دهند و ایجاد ارتباط را تا آن وقت به تأخیر می‌اندازند. Weaverهای CT با توجه به این که تمام فرآیند ایجاد ارتباط را در ابتدای کار و هنگام کامپایل انجام می‌دهند بسیار سریع‌تر از RTها عمل می‌کنند، اما در مقابل RTها هم این مزیت را دارند که در صورت تغییر کد Aspectها نیازی به انجام دوباره عملیات Weaving نیست و برخلاف CTها در Run-Time Weaver تغییرات در کد بدون نیاز به هیچ کاری سریع منعکس می‌شوند. همان‌طور که در بالا ذکر کردیم، تکنیک‌های Weaving دیگری نیز وجود دارند که در واقع فضای بین Compile-time و Run-time قرار می‌گیرند. این دو تکنیک Weaving را (post-compile time (binary و Load-time می‌نامند. Binary Weaving در حقیقت عملیات Weaving را روی byte code انجام می‌دهد (پس از کامپایل). Load time Weaving نیز یک نوع binary Weaving است. با این تفاوت که عملیات Weaving را تا زمانی که یک کلاس به Class loader معرفی نشده است، به تأخیر می‌اندازد. (این توانایی می‌تواند برخی از نقص‌های مدل Compile-time را برطرف کند، زیرا شما می‌توانید بدون کامپایل کردن دوباره کد اصلی خود (Aspect ،(Business Logicهایی به برنامه اضافه کرده و سپس آن‌ها را به پروژه اصلی لینک دهید). در حقیقت، در این مدل تا جایی که ممکن است عملیات Weaving به تأخیر می‌افتد و تا مرحله Load شدن کلاس‌های موردنیاز هیچ ترکیبی انجام نمی‌شود.AspectJ محیطی ساده و بسیار کارا دارد و هم‌اکنون محبوب‌ترین ابزار برنامه‌نویسی Aspect-Oriented است. نسخه‌های جدیدتر AspectJ به‌طور کامل با محیط توسعه Eclipse هماهنگی دارند و می‌توان از تمام امکانات Eclipse در مورد Aspectها نیز سود برد.توجه به این نکته ضروری است که AspectJ تغییراتی در Syntax زبان به وجود می‌آورد که این موضوع می‌تواند باعث بروز مشکلاتی شود (Eclipse با توجه به اضافه کردن Keywordهای مربوط به برنامه‌نویسی AOP این مشکل را ندارد).این مشکلات باعث شدند تا ابزارهای دیگری به وجود آیند که به این تغییرات گرامری در زبان برنامه‌نویسی نیازی نداشته باشند. یک نمونه مشهور از این زبان‌ها‌ AspectWerkz است. AspectWerkz در حال حاضر از هر سه مدل Compile-time ،Load-time و Run time استفاده می‌کند. خصوصیت بارز AspectWerkz این است که Syntax زبان را تغییر نمی‌دهد و در حقیقت تغییرات را با استفاده از Annotation انجام می‌دهد که به یک ساختار زبانی جدید نیازی ندارد. در حال حاضر، دو پروژه AspectJ و AspectWerkz با یکدیگر ترکیب شده‌اند تا بتوانیم از قابلیت‌های هر دو به صورت هم‌زمان استفاده کنیم.تمام این مقدمه‌ها برای این ذکر شد که شما کمی بیشتر با نحوه عملکرد داخلی ابزارهای توسعه برنامه‌های Aspect-Oriented آشنا شوید.منبع : ماهنامه شبکه alirezadp10 alirezadp10 Mon, 16 Aug 2021 01:54:41 +0430 https://virgool.io/@alirezadp10/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-php-%D8%A8%D8%A7-%D9%85%D8%AF%D9%84-asynchronous-%D9%86%D8%A7%D9%85%D8%AA%D9%82%D8%A7%D8%B1%D9%86-%D8%BA%DB%8C%D8%B1%D9%87%D9%85%D8%B2%D9%85%D8%A7%D9%86-gagoirxxqbw7 در برنامه‌نویسی به زبان PHP، کدها به‌صورت متقارن اجرا می‌شوند. برای درک بهتر این‌موضوع، هر خط کد را یک بلاک یا مسدودساز در‌نظر بگیرید که درهنگام اجرای برنامه، ابتدا خط شماره یک اجرا می‌شود، درقدم بعد خط شماره دو و این‌توالی به همین شکل تا پایان کد‌ها ثابت می‌ماند. این‌یکی از مدل‌های برنامه‌نویسی است که PHP را از زبان‌هایی مانند Go، NodeJs و چندی دیگر از زبان‌ها متمایز می‌سازد.برنامه‌نویسی با مدل نامتقارن (Asynchronous)، به شما این اجازه را می‌دهد که بدون انتظار برای انجام عملیات‌های دیگر، کد‌های خود را در زمان مورد نیاز، بصورت همزمان اجرا کنید. یک مثال از اتفاق‌های واقعی زندگی روزمره ما اهمیت این‌مدل را بهتر نمایان می‌کند: شما یک ایمیل برای دوستان خود می‌فرستید، بعد ‌از آن به انجام دیگر کارها می‌پردازید و تا وقتی دوستانتان برای شما پاسخی ارسال نکردند، به سراغ ایمیل‌هایتان نمی‌آیید یا به عبارت دیگر شما مجبور نیستید بیکار بمانید تا پاسخی دریافت کنید.برای دستیابی به این‌مدل در وب‌سرور، شما می‌توانید از رشته‌ها (thread) یا فرایندهای (process) مختلف جداگانه، در زمانی که برنامه شما، درحال انجام کارهای دیگر روی رشته اصلی است، استفاده کنید. برای مثال، یک عملیات را برای اجرا در صف اپلیکیشن لاراولی خود قرار‌ می‌دهید که به شما اجازه می‌دهد، در زمانی که فرایند‌اصلی برنامه توان بیشتری از پردازشگر را اشغال کرده‌است، عملیات خود را به یک worker process بسپارید.مقایسه رشته‌ با فرایند (thread vs process):فرایند یک واحد مجزا، در‌بخش اجرایی به شمار می‌آید. فرایند‌ها منابعی از پردازشگر را به خود اختصاص می‌دهند و آن را با دیگر فرایند‌ها به اشتراک نمی‌گذارند. با ‌این‌حال، یک فرایند واحد می‌تواند از رشته‌های متعددی تشکیل شده‌باشد، تمامی رشته‌ها، بصورت اشتراکی از توان پردازشگر، که به فرایند مورد نظر اختصاص داده شده استفاده می‌کنند. برای کوتاه تر شدن مقاله، باید بگویم: زبان PHP به کمک افزونه جداگانه‌ای به نام pthreads از برنامه‌نویسی چندنخی پشتیبانی می‌کند، درحال‌حاضر این‌افزونه بایگانی شده‌است.Call stack و Event loop:برای شروع باید‌ بگویم در زبان فارسی event‌ loop را حلقه‌رویداد و call‌ stack را فراخوانی‌پشته می‌نامند. یکی دیگر از راه‌حل‌های موجود برای دستیابی به مدل برنامه‌نویسی نامتقارن در PHP، استفاده از حلقه‌رویداد است. با این‌دیدگاه به موضوع نگاه کنید که حلقه‌ای مانند یک worker، توابع در صف انتظار برای اجرا را، مداوما دریافت می‌کند و درصورتی که call stack خالی باشد توابع را اجرا می‌کند. فراخوانی‌پشته، یک جریان همزمان عادی در برنامه شماست.پس بصورت زیر می‌توان به مدل اجرای نامتقارن کدها در php دست‌ پیدا کرد:use Symfony\Component\Process\Process; $process = new Process(['php', 'artisan', 'task:run']); $process2 = new Process(['php', 'artisan', 'anothertask:run']); $process->start(); $process2->start(); // انجام برخی کارها // سپس منتظر می‌مانیم فرآیند فرعی تمام شود while ($process->isRunning() || $process2->isRunning()){ sleep(1); } // در پایان پاسخ را برگشت میدهیم return response();با استفاده از کدبالا، ما 2 فرایند فرعی را برای اجرای task:run و anothertask:run توسط artisan، در زمانی که برخی کارها درحال انجام هستند، بوجود آورده‌ایم. قبل از به انجام رسیدن عملیات پدر، ما برای به اتمام رسیدن عملیات فرزند صبر می‌کنیم.این یک مثال ساده، برای پیاده سازی مدل اجرای کدهای نامتقارن است. برای موارد پیشرفته‌تر، Spatie یک پکیج به نام spatie/async ساخته است. به کمک این بسته نرم‌افزاری شما می‌توانید، چندین فرایند با مدل نامتقارن، در کدهای PHP خود داشته باشید و همچنین آن‎ها را مدیریت کنید.فرایند اصلی برنامه شما، فرایندهای فرعی متعددی را شروع می‌کند و برروی اجرای آن‌ها درحالی که به کار خود ادامه می‌دهند نظارت دارد. برای مدیریت ارتباط بین فرآیند والد و فرزند از سیگنال‌های PHP’s async استفاده می‌کند. برای اطلاع بیشتر از نحوه کار این بسته، مقاله آقای Brent Roose را مشاهده بفرمایید.منبع: https://divinglaravel.com/authentication-and-laravel-airlockارجاع alirezadp10 alirezadp10 Fri, 28 May 2021 19:59:47 +0430 https://virgool.io/@alirezadp10/asynchronous-%DA%86%DB%8C%D8%B3%D8%AA-bwdmtds1rya9 برنامه نویسی طی این سال‌ها پیشرفت زیادی داشته و هر روز شاهد معرفی زبان‌ها یا تکنولوژی‌های جدید هستیم. هر ابزار جدید که معرفی می‌شود به دنبال حل یک مساله بوده و سعی دارد شرایط فعلی را بهتر کند. در واقع زبان ها، فریم ورک‌ها و تمام ابزارهای برنامه نویسی که امروز از آن‌ها استفاده می‌کنیم، حاصل تلاش انسان‌های زیادی در طول سال‌های مختلف بوده است. امروز سراغ مفهومی به نام Asynchronous رفته و چالش هایی که این مدل سعی در حل آن دارد را با هم مرور می‌کنیم. بعد از مطالعه این مطلب می‌فهمید که روش Asynchronous چیست ، چه تفاوتی با Synchronous داشته و چه کاربردهایی دارد. همراه ما باشید.برنامه نویسی Synchronous چیست؟برای درک مفهوم برنامه نویسی غیرهمزمان بهتر است اول برنامه نویسی همگام یا Synchronous را بشناسیم. در این روش کدهای برنامه نویس پشت سر هم و به صورت خطی اجرا می‌شوند. یعنی اگر برنامه ما 400 خط کد داشته باشد، دستورات و توابع از خط 1 و به نوبت اجرا می‌شوند تا زمانی که به خط 400 برسیم و اجرای برنامه تمام شود. در این روش از برنامه نویسی دستورات باید به ترتیب اجرا شوند و تا زمانی که تابع "الف" اجرا نشده نمی‌توان سراغ تابع "ب" رفت.گفتن چند نکته به شما کمک می‌کند بیشتر با این نوع از برنامه نویسی آشنا شوید. اولین مورد درباره ترجمه کلمه Synchronous به فارسی بوده که کمی گمراه کننده است. با جستجو در چند دیکشنری معتبر به چنین نتایجی می‌رسیم: Synchronous: هم زمان، همگاه، واقع شونده بطور هم زمان. می‌بینید که تمام این کلمات اشاره به مفهومی به نام "زمان" دارند. ولی در این روش همه چیز به زمان خلاصه نشده و لزوما نباید همه چیز را در در زمان خلاصه کنیم. بلکه منظور از Synchronous این است که کدها پشت سر هم اجرا می‌شوند که این مورد می‌تواند به موارد دیگری به جز زمان هم وابسته باشد. پس مراقب باشید ترجمه این کلمه شما را گمراه نکند.نکته دیگر مربوط به خوب بودن یا بد بودن این روش است. نباید اینطور فکر کنیم که با روی کار آمدن Asynchronous دیگر فاتحه Synchronous خوانده شده و باید استفاده از آن را کنار بگذاریم. در کل نمی‌توان به یک تکنولوژی برچسب خوب یا بد زد. باید ببینیم این تکنولوژی کجا کاربرد دارد و چه قابلیت هایی دارد. در روش Synchronous هم اوضاع به همین شکل بوده و اگر در جای درست استفاده شود نتایج شگفت انگیزی به دنبال خواهد داشت.چند مثال در روش برنامه نویسی Synchronousمثال‌های زیادی برای برنامه نویسی همگام وجود دارند. در واقع بسیاری از برنامه نویسان آگاهانه یا ناآگاهانه در حال استفاده از این روش هستند. اما برای آشنایی بیشتر بهتر است چند سناریو را با هم بررسی کنیم. در یک مثال ساده تکه کدی به زبان Python می‌نویسیم که یک ورودی از کاربر گرفته و آن را در صفحه نمایش چاپ کند:در مثال بالا همه چیز با یک قاعده مشخص و خطی انجام می‌شود. کاربر یک ورودی وارد کرده و برنامه آن ورودی را چاپ می‌کند. یک مثال دیگر می‌تواند وقفه در زمان دانلود یک فایل باشد. فرض کنید برنامه ما قرار است اطلاعاتی را دانلود کرده و بعد تغییراتی روی این داده‌ها اعمال کند.متوجه ایراد کار شدید؟ در واقع تا زمانی که دانلود فایل‌ها تمام نشده باشد برنامه نمی‌تواند تغییرات خودش را اعمال کند. اگر روشی وجود داشت که برنامه با دانلود بخشی از فایل آن را پردازش هم بکند چقدر در عملکرد برنامه تاثیر مثبتی داشت. یا هنگامی که برنامه در حال دانلود فایل‌ها است بتوانیم توابع دیگر برنامه را اجرا کنیم. دقیقا به خاطر همین موارد و همین مزایا است که سراغ برنامه نویسی Asynchronous می‌رویم.برنامه نویسی Asynchronous چیست؟برنامه نویسی Asynchronous (ناهمگام یا نامتقارن) یک مدل و مفهوم در برنامه نویسی است. در این مدل برخلاف روش Synchronous کدهای ما پشت سر هم اجرا نمی‌شوند و به اصطلاح ترتیب کدها غیرخطی است. حالا دیگر اجباری نیست که برنامه 400 خطی ما به ترتیب از خط 1 تا 400 اجرا شود و این روال می‌تواند تغییر کند. یا مثالی که درباره دانلود و پردازش فایل‌ها زدیم را هم می‌توانیم به کمک Asynchronous بهتر پیاده سازی کنیم. به این شکل که تا فایل‌ها در حال دانلود هستند، CPU را به بخش‌های دیگر اختصاص بدهیم. پس در Asynchronous ترتیب اجرای دستورات پشت سر هم نیست. اما چه دلیلی دارد که ترتیب اجرای کدها را در برنامه به هم بریزیم؟CPU عضو حیاتی و مغز متفکر کامپیوتر به حساب می‌آید. می‌توان به راحتی از داشتن قطعاتی مثل کارت گرافیک، کارت صدای اکسترنال، خنک کننده‌ها یا دی وی دی رایتر چشم پوشی کرد اما بدون CPU کامپیوتر ما حتی روشن هم نمی‌شود. حالا به نظرتان چه دلیلی دارد که این عضو مهم را حتی برای یک لحظه هم بیکار بگذاریم؟ به کمک روش برنامه نویسی Asynchronous می‌توانیم از منابع سخت افزاری نهایت استفاده را داشته باشیم.Asynchronous می‌تواند بسیاری از مشکلات ما را حل کند. این روش از لحاظ ترتیب اجرا کاملا در نقطه مقابل Synchronous قرار دارد و ما در یک برنامه می‌توانیم چندین جریان اجرایی یا Control Flow داشته باشیم. Asynchronous کمی شبیه به حل پازل است. همانطور که ما هنگام چیدن پازل از ترتیب خطی استفاده نکرده و با توجه به شرایط مختلف قطعات پازل را کنار هم می‌چینیم، در روش Asynchronous هم پردازش‌ها با ترتیب مشخصی اجرا نمی‌شوند.آیا برنامه نویسی Asynchronous حتما سرعت برنامه ما را افزایش می‌دهد؟هیچ تضمینی وجود ندارد که استفاده از چند Control Flow و خارج کردن برنامه از حالت خطی و ترتیبی سرعت اجرای برنامه شما را افزایش دهد. در واقع این مدل اجرایی گاهی تاثیری در سرعت برنامه نداشته و حتی ممکن است در بعضی از موارد سرعت برنامه را کاهش هم بدهد. اگر به خاطر افزایش سرعت اجرا تصمیم گرفته اید از Asynchronous استفاده کنید باید یک تجدید نظر در تصمیم خود داشته باشید. اگر این تکنولوژی در جای مناسب به کار بگیرید می‌تواند نتایج بسیار خوبی به دنبال داشته باشد. در واقع هر بار که کد می‌نویسید باید از خودتان این سوال را بپرسید که استفاده از Asynchronous مفید خواهد بود یا خیر. مثلا می‌توانید بپرسید بهتر است در این قسمت از برنامه وقتی در حال خواندن فایلی هستم باید در پشت صحنه یک پردازش هم اجرا کنم یا خیر. اگر جواب مثبت بود استفاده از Asynchronous می‌تواند کمک بزرگی به حساب بیاید.آیا مدل Asynchronous وابسته به یک زبان برنامه نویسی یا فریم ورک خاص است؟?Asynchronous به تنهایی یک مفهوم است. بهتر است زمانی که در حال بررسی تئوریک آن هستیم وارد مباحث برنامه نویسی نشویم. زمانی که به خوبی این مدل را درک کردیم می‌توانیم هنگام کدنویسی از آن استفاده کنیم. زبان‌های برنامه نویسی روش‌های متنوعی برای پیاده کردن این مدل ارائه دادند که با توجه به زبانی که استفاده می‌کنیم ممکن است کمی متفاوت باشند. مثلا در زبان C# و بعد از تکنولوژی .NET Framework نسخه 4.5 به بعد دو کلیدواژه Async و Await معرفی شدند و کار پردازش نامتقارن داده‌ها را به عهده گرفتند. فراموش نکنید که عملیات Asynchronous محدود به دات نت فریم ورک و زبان برنامه نویسی سی شارپ نبوده و می‌توان از آن در بخش‌های مختلفی استفاده کرد.نتیجه گیریدر این مطلب بررسی کردیم که مفهوم Asynchronous چیست و چه کاربردهایی دارد. اول راجع به Synchronous صحبت کرده و گفتیم که در این روش برنامه ما به صورت خط به خط اجرا می‌شود. در مقابل به مدل Asynchronous رسیدیم که این ترتیب زمانی را به هم می‌ریخت تا برنامه ما برای یک وقفه طولانی معطل نشده و پردازش‌های دیگر را مدیریت کند. همینطور اشاره ای به کاربرد آن در تکنولوژی دات نت فریم ورک داشتیم. شاید در نگاه اول پردازش‌های نامتقارن و ناهمگام جذاب به نظر برسند اما باید با توجه به شرایط برنامه خود تصمیمی بگیرید که از آن استفاده کنید یا خیر.ارجاع alirezadp10 alirezadp10 Fri, 28 May 2021 18:23:04 +0430 https://virgool.io/CodeLovers/%D9%85%D9%82%D8%A7%DB%8C%D8%B3%D9%87-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-asynchronous-%D9%88-synchronous-icqrzkrfx5mv synchronousدر زبان های synchronous در هر لحظه تنها ۱ پردازش قابل اجراء است. این programming paradigm یا الگوی برنامه نویسی معمولا به علت ورودی/خروجی ها یا I/O ها باعث رخ دادن bottleneck و منتظر ماندن پردازش های دیگر می‌شود, و پردازنده مدت زمان زیادی را باید منتظر بماند.امروزه زبان های بسیار اندکی از این الگو پیروی می‌کنند, و مفسر هایی به مانند CPython که ۱ نخی هستند نیز با روش های مختلفی پردازش هارا asynchronous می‌کنند.asynchronousبرنامه نویسی asynchronous نوعی برنامه نویسی موازی یا parallel است 1. این الگوی برنامه نویسی اجازه می‌دهد تا نرم افزار منتظر پردازش های blocking یا مانع شوند نماند, و اگر پردازشی برای ادامه نیاز به I/O داشت در همان لحظه پردازش دیگری اجرا شود.منظور از blocking operation پردازشی است که تا تمام نشدن پردازش خود مانع اجرای پردازش های دیگر می‌شود.در زبان های asynchronous در صورت پیروی از الگوی asynchornous دیگر مشکل bottleneck وجود نخواهد داشت. برنامه نویسی چند نخی نیز شیوه ای از برنامه نویسی asynchornous است. 2When to Use (and Not to Use) Asynchronous Programming: 20 Pros Reveal the Best Use Cases ^The Difference Between Asynchronous And Multi-Threading ^ارجاع alirezadp10 alirezadp10 Fri, 28 May 2021 18:06:58 +0430 https://virgool.io/@alirezadp10/%D8%AA%D8%B4%D8%B1%DB%8C%D8%AD-%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-synchronous-%D9%88-asynchronous-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-%DB%8C-%D9%81%D8%A7%D8%B1%D8%B3%DB%8C-lornfy6pjisr مقدمهوقتی واژه‌ی Synchronous را در دیکشنری جستجو می‌کنید، چیزی که دستگیرتان می‌شود احتمالا این معنی است: هم‌زمان.و به تناسب، برای واژه‌ی Asynchronous هم با معنی «غیر هم‌زمان» مواجه خواهید شد.اگر در حال خواندن این نوشته هستید، احتمالا شما هم مثل من به این نتیجه رسیده‌اید که این معانی نمی توانند مفهوم این دو واژه را بدرستی منتقل نمایند. وقتی می خواهیم درباره‌ی این دو واژه در برنامه‌نویسی صحبت کنیم، متوجه خواهیم شد که «زمان» فقط یکی از فاکتورهایی است که در این موضوع دخیل است؛ حتی در خیلی از اوقات، قضیه «زمان» واقعا در اولویت نیست!بیشتر نوشته های موجود در اینترنت نیز هنگام توضیح این دو مفهوم، به سرعت با عوامل جانبی مانند چگونگی پیاده‌سازی این‌ها در فلان زبان یا فلان فریم ورک خاص مخلوط می‌شوند و هیچوقت به درستی درکی از خود این مفاهیم صورت نمی گیرد. نتیجه این می‌شود که برنامه‌نویس‌ها از چنین قابلیت‌هایی در کد‌هایشان استفاده می کنند، بدون اینکه واقعا اصل داستان را بدانند.من در این نوشته میخواهم به شیوه‌ی خودم این دو مفهوم پر استفاده را توضیح دهم؛ شاید این نوشته بتواند سودمند واقع شود.منظور از کدهای Synchronous چیست؟برای لحظه‌ای، موضوع «زمان» را به طور کامل از فکر خود بیرون کنید! بیاید از زاویه دیگری به مفهوم Synchronous نگاه کنیم؛وقتی می‌گوییم کدهای ما Synchronous است، در حقیقت داریم درباره «ترتیب اجرای» کدها حرف می‌زنیم! به شکلی که این «ترتیب اجرا»، برابر با همان «ترتیب نگارش» کدهایمان باشد.بنابراین «زمان» تنها فاکتور دخیل در Synchronous بودن نیست. در این مفهوم، «مکان» کدها و اینکه آن‌ها را به چه شیوه‌ای نوشته باشیم نیز از اهمیت برخوردار است.وقتی می‌گوییم کدهای ما حالت Synchronous دارند، به این معنی است که ترتیب اجرای آن‌ها پشت سر هم و به شکلی کاملا قابل پیش‌بینی اتفاق می‌افتد. فرضا شبه کد زیر را در نظر بگیرید:var a = 10; var f = file.open(&quotnames.txt&quot); var names = f.read(); print names; print a + 2;ما انتظار انجام یک سری از وظایف را از کامپیوتر داشتیم. با توجه به آن انتظارات، به ترتیب خاصی کدهای‌مان را نگارش کردیم و از بالا به پایین دستوراتی که کامپیوتر باید اجرا کند را برایش شرح داده‌ایم و انتظار داریم که این دستورات به همان ترتیبی که نگارش شده‌اند اجرا شوند:مقدار 10 در متغیر a ریخته شود.فایل names.txt باز شود و ارجاعی در آن در متغیر f ریخته شود.اطلاعات درون f خوانده شود و به طور رشته‌ای در متغیر s قرار بگیرد.محتوایی که در s قرار دارد چاپ شود.نتیجه‌ی محاسبه‌ای a + 2 نیز در خروجی چاپ شود.در مثال بالا، ما به عنوان برنامه‌نویس چنین رویه‌ای را دنبال کردیم:چیزی که از کامپیوتر انتظار داشتیم را در «فکر» خود حلاجی کردیم.افکار خود را در قالب «کد» نگارش کردیم.همچنین در این بین، «ترتیب نگارش» کدها را نیز مطابق افکار خود تنظیم کرده‌ایم.کامپیوتر نیز اجرای کدهای ما را به شکلی قابل پیش بینی انجام خواهد داد. فرضا چاپ کردن محتوای فایل، حتما بعد از باز کردن فایل اتفاق می‌افتد.ترکیب سه فاکتور «فکر»، «نگارش»، و «اجرا» مفهومی به اسم Control Flow یا «جریان کنترلی» را در برنامه‌نویسی به وجود می‌آورند که بیان کننده‌ی مدل اجرایی سیستم است.در کدهای Synchronous، قضیه Control Flow ترتیبی به و شکلی قابل پیش‌بینی خواهد بود.از همین رو، کدهای Synchronous کدهایی هستند که طبیعتی ترتیبی دارند. چیزی که در زبان انگلیسی می تواند با واژه‌ی Sequential بیان شود.منظور از کدهای Asynchronous چیست؟بر عکس چیزی که مردم فکر می کنند، مفهوم Asynchronous مشخصا در قطب مخالف Synchronous نیست! بلکه به نوعی مکمل آن است.کدهای Asynchronous کدهایی هستند که در آن‌ها «ترتیب اجرای» فرامین، دقیقا با «ترتیب نگارش» آن‌ها مطابق نخواهد بود.این ناهماهنگی چیز بدی نیست:خیلی از مسايل در کامپیوتر طبیعت‌ای غیر ترتیبی دارند. نتیجه اجرای بسیاری از فرامین ممکن است در همان لحظه در دسترس قرار نگیرند. فرضا در مثال بالا، باز کردن فایل names.txt ممکن است ۱ میلی ثانیه طول بکشد، یا ممکن است ۱۰ ثانیه طول بکشد!پردازنده‌های امروزی بسیار سریع‌تر از حدی هستند که بخواهیم از آن‌ها فقط برای اجرای «یک» روند ترتیبی بهره بگیریم. آن‌ها می توانند روند‌های اجرایی زیادی را به شکل غیر ترتیبی اجرا نمایند.چون کدهای Asynchronous ذاتی غیر ترتیبی دارند، از جریان اجرایی پیشفرض کدها که به حالت ترتیبی اتفاق می‌افتد پیروی نمی‌کنند؛ در حقیقت، هنگام استفاده از مدل Asynchronous، هر بخش از کد می تواند دارای جریان اجرایی جداگانه‌ای باشد. به همین دلیل می توان به کمک اعمال Asynchronous به جای یک جریان اجرایی، چندین و چند جریان اجرایی داشت.حالا می‌رسیم به قسمتی که در بیشتر نوشته‌ها باعث ریختن قیمه‌ها در ماست‌ها می‌شود! قسمتی که نویسنده مطلب تصمیم می‌گیرد مفهوم Asynchronous را با مدل پیاده‌سازی آن در زبان‌های مختلف قاطی کند، در حالی که Asynchronous یک مفهوم مستقل است که می توانند در هر سیستم به نوع متفاوتی ظاهر شود. اما چیزی که مهم است، غیر ترتیبی بودن کدهاست که در تمام پیاده سازی ‌ها مشترک است.نحوه‌ی اجرا شدن کدهای Asynchronous ممکن است به طور موازی اتفاق بیفتند؛ که باعث اجرای Parallel خواهد شد. همچنین ممکن است به طور غیر موازی اتفاق بیفتد که باعث اجرای «همروند» یا Concurrent می‌شود.زبان‌های مختلف، برای پیاده سازی مدل Asynchronous از راه‌حل‌های متفاوتی استفاده می‌کنند. در نهایت، موضوع به این برمی‌گردد که چگونه جریان‌های غیرترتیبی در مدل Asynchronous را اجرا و مدیریت می کنند:با استفاده از Process ها، که مبتنی بر حافظه‌ی غیر اشتراکی هستند.با استفاده از Thread ها، که بسیار نزدیک به Process ها هستند با این تفاوت که از حافظه‌ی اشتراکی استفاده می‌کنند.با استفاده از Event ها، و به کمک Event loop و سایر الگوریتم‌هایی که مبتنی بر آن هستند (مثل callback یا Promise یا …)با استفاده از ترکیبی از تمام موارد بالا… (یا هر مدل دیگری که ممکن است به فکرتان برسد)هر کدام از روش‌های بالا مزایا و معایب خود را دارند. زبان‌هایی که به «همروند» بودن شهرت دارند، زبان‌هایی هستند که از تمام این مدل‌های استفاده کرده اند و سعی کرده‌اند به طور مناسبی هر مدل را در سناریو ای که برایش مناسب تر است استفاده کنند.فرقی ندارد که از کدام زبان استفاده می‌کنید، و آن زبان از کدام مدل برای پیاده سازی مفهوم Asynchronous استفاده کرده است. در هر حال، هنگام کار با کدهای Asynchronous باید نکات زیر را بخاطر داشته باشید:ترتیب اجرای کدهای مشخص نیست.زمان به نتیجه رسیدن هر جریان اجرایی مشخص نیست.نحوه‌ دسترسی هر جریان اجرایی به «داده‌ها» مشخص نیست.کدهای Asynchronous بیانگر یک «مدل» اجرایی می‌باشند؛ Asynchronous بودن نه ربطی به سرعت کدها دارد و نه ضمانتی در اینباره ارايه می‌دهد.بنابراین:باید یک راه منطقی برای فکر کردن راجع به Control Flow کدهای‌تان پیدا کنید.هیچوقت تصمیم گیری‌های‌تان را بر مبنای اینکه «اتمام فلان تکه از کد، فلان مقدار زمان خواهد برد» پایه گذاری نکنید.خود را برای این قضیه که داده‌های شما به شکل همروند در دسترس خواهند بود آماده کنید.کدهای شما ممکن است سریع‌تر شوند؛ و یا کندتر شوند! بدون فکر انتخابی انجام ندهید!سخن آخردر نوشته‌ای که خواندید، سعی شد بدون پرداختن و درگیر شدن با جزییات زبان‌های مختلف برنامه‌نویسی و ابزار‌های‌شان، توضیحی ساده از مفاهیم Synchronous و Asynchronous ارائه شود. همچنین از روی عمد، از واژه‌هایی مانند blocking و Non-blocking استفاده نشد تا باعث گمراهی بیشتر نشود؛ چرا که این مفاهیم داستان خودشان را دارند.امیدوارم این نوشته هم برای خودتان مفید واقع شده باشد، و هم اینکه بتواند رفرنس خوبی برای‌تان باشد تا برنامه‌نویس های دیگری که قصد آشنایی با این مفاهیم دارند را به آن ارجاع دهید.ارجاع alirezadp10 alirezadp10 Fri, 28 May 2021 17:53:36 +0430