آموزش صفر تا صد دیزاین پترن (Design Pattern) در جاوا
از این Design Pattern در شرایطی استفاده می‌شود که یک کلاس پدر داریم که چند کلاس فرزند دارد و می‌خواهیم بر اساس ورودی یکی از کلاس‌های فرزند را به عنوان خروجی بفرستیم. اگر با Design Pattern Factory جاوا آشنا باشید، می‌دانید که ما یک کلاس Factory داریم که بر اساس ورودی، کلاس‌های فرزند مختلفی را برمی‌گرداند. کلاس Factory برای انجام این کار از دستور if-else یا Switch استفاده می‌کند. از این پترن زمانی استفاده می‌کنیم که ساخت یک شئ جدید هزینه، زمان و منابع زیادی می‌گیرد و یک شئ آماده‌ی مشابه آن نیز داریم. این Design Pattern از Cloning جاوا برای کپی شی استفاده می‌کند. این پترن نوعی Design Pattern ساختاری است و زمانی از آن استفاده می‌کنیم که دو واسط غیرمرتبط بخواهند با هم همکاری کنند. این پترن یکی از Design Patternهای ساختاری است و زمانی از آن استفاده می‌کنیم که قصد نمایش یک سلسله‌مراتب جزء-کل را داشته باشیم. تعریف بالا همه‌چیز را به خوبی عنوان می‌کند و از این Design Pattern برای کنترل دسترسی به یک عملکرد استفاده می‌کنیم. وقتی قصد ساخت تعداد زیادی شئ از یک کلاس را داریم، از این Design Pattern استفاده می‌کنیم. پیاده‌سازی String Pool در جاوا یکی از بهترین مثال‌های دیزاین پترن Flyweight است. این Design Pattern برای تعامل ساده‌تر اپلیکیشن‌های کلاینت با سیستم طراحی شده است. حالا یک اپلیکیشن کلاینت می‌تواند از این واسط‌ها برای دریافت اتصال (Connection) لازم به پایگاه داده استفاده و یک گزارش تولید کند. برای حل این مشکل می‌توانیم از دیزاین پترن Facade استفاده کنیم. وقتی هم در واسط‌ها و هم در پیاده‌سازی دارای سلسله‌مراتب هستیم، از این Design Pattern برای جداسازی واسط از پیاده‌سازی استفاده می‌کنیم. پیاده‌سازی دیزاین پترن Bridge نشان‌دهنده‌ی این موضوع است که برنامه‌نویس ترکیب را به ارث‌بری ترجیح می‌دهد. وقتی قصد تغییر عملکرد یک شئ را در زمان اجرا داریم، از این Design Pattern استفاده می‌کنیم. Decorator نیز یکی از دیزاین پترن‌های ساختاری است و از کلاس یا واسط Abstract و ترکیب برای پیاده‌سازی استفاده می‌کند. ما برای گسترش رفتار یک شئ از ارث‌بری یا ترکیب استفاده می‌کنیم، اما این کار در زمان کامپایل صورت می‌گیرد و روی همه‌ی اشیاء کلاس اعمال می‌شود. نمی‌توانیم در زمان اجرا، عملکردی جدید را برای حذف رفتارهای موجود یک شئ، اضافه کنیم و این همان شرایطی است که Decorator به کارمان می‌آید. Template یک Design Pattern رفتاری است و از آن برای ساخت یک استاب متد (Stub) و انجام برخی از مراحل پیاده‌سازی در کلاس فرزند استفاده می‌شود. در این شرایط، از یک متد Template استفاده می‌کنیم که از متدهای مختلفی برای ساخت ساختمان استفاده می‌کند. از این Design Pattern برای ارائه‌ی یک واسط ارتباطی متمرکز بین اشیاء سیستم استفاده می‌شود. در شرایطی که در یک اپلیکیشن سازمانی، اشیاء مختلفی داریم که با هم تعامل دارند، این دیزاین پترن بسیار کاربرد دارد. دیزاین پترن Mediator تلاش می‌کند یک واسط (Mediator) بین اشیاء قرار دهد تا از طریق آن با هم ارتباط داشته باشند و به پیاده‌سازی loose Coupling بین اشیاء کمک می‌کند. برج کنترل ترافیک هوایی، یکی از بهترین مثال‌ها برای دیزاین پترن Mediator است، که در آن برج کنترل به عنوان واسطی بین پروازهای مختلف عمل می‌کند. وقتی درخواست کلاینت برای پردازش به زنجیره‌ای از اشیاء داده می‌شود، برای داشتن Loose Coupling از این Design Pattern استفاده می‌شود. وقتی State یک شئ برایمان اهمیت دارد و می‌خواهیم از هر تغییری در آن مطلع شویم، از این Design Pattern استفاده می‌کنیم. اگرچه از این گزینه‌ها استفاده‌ی چندانی نمی‌شود، چون بسیار ساده هستند و اغلب اوقات نمی‌خواهیم فقط به هدف پیاده‌سازی پترن Observer از یک کلاس ارث‌بری داشته باشیم، چون جاوا از ارث‌بری چندگانه پشتیبانی نمی‌کند. (Java Message Service (JMS از پترن‌های Mediator و Observer استفاده می‌کند تا به اپلیکیشن‌ها این امکان را بدهد که برای هم داده بفرستند و یکدیگر را Subscribe کنند. وقتی چند الگوریتم برای انجام یک کار داریم و کلاینت در زمان اجرا تصمیم می‌گیرد از چه الگوریتمی استفاده کند، از این Design Pattern استفاده می‌کنیم. از این Design Pattern برای داشتن Loose Coupling در یک مدل Request-Response استفاده می‌کنیم. در دیزاین پترن Command، درخواست به Invoker فرستاده می‌شود و این Invoker است که آن را به شئ Command کپسوله‌شده (Encapsulated) منتقل می‌کند. زمانی از این Design Pattern استفاده می‌کنیم که یک شئ رفتارش را بر اساس State داخلی خود تغییر دهد. برای انجام عمل‌های متفاوت نیز براساس این متغیر، می‌توانیم از بلوک شرطی if-else استفاده کنیم. وقتی می‌خواهیم عملی را روی گروهی از اشیاء مشابه انجام دهیم، از این Design Pattern استفاده می‌کنیم. حالا می‌توانیم این منطق محاسبه‌ی هزینه را در کلاس‌های مربوط به هر آیتم قرار دهیم یا آن را با استفاده از دیزاین پترن Visitor به کلاس دیگری ببریم. از این Design Pattern برای نمایش گرامری یک زبان استفاده می‌شود. این پترن نیز یک Design Pattern رفتاری است و زمانی از آن استفاده می‌شود که به دنبال روشی استاندارد برای گشتن در میان گروهی از اشیاء هستیم. از دیزاین پترن Iterator در Java Collection Framework بسیار استفاده شده است. این دیزاین پترن پیاده‌سازی اصلی را پنهان می‌کند و برنامه‌های کلاینت تنها از متدهای Iterator استفاده می‌کنند. وقتی به‌منظور استفاده‌های بعدی، قصد ذخیره‌ی State یک شئ را داریم، از این Design Pattern استفاده می‌کنیم. دیزاین پترن Memento به گونه‌ای این کار را انجام می‌دهد که داده‌ی State شئ از بیرون قابل دسترسی نباشد. از این Design Pattern برای بردن منطق ماندگاری داده (Data Persistence Logic) به یک لایه‌ی دیگر استفاده می‌شود. وقتی می‌خواهیم سیستمی طراحی کنیم که با پایگاه داده کار می‌کند، دیزاین پترن DAO بسیار مفید است. با این Design Pattern می‌توانیم Dependencyهای استاتیک (Hard-Coded) را حذف کنیم و اپلیکیشنی Loosely Coupled، قابل توسعه و با هزینه‌ی نگداری پایین داشته باشیم. این پترن یکی از قدیمی‌ترین معماری‌های موجود برای ساخت اپلیکیشن‌های تحت وب است.
متن کامل نوشته در سایت فرانش
نظرات