دیزاین پترن Design Pattern چیست؟ + انواع آن
دیزاین پترن Design Pattern یا الگوی طراحی، یک راه حل قابل تکرار در حوزه برنامه نویسی است که از آن برای رفع مشکلات احتمالی نرم افزار که امکان بروز مکررشان وجود دارد، استفاده می شود.
در دنیای برنامه نویسی و مهندسی نرم افزار، گاهی مشکلاتی از یک جنس به صورت مکرر در شرایط مختلف اجرای نرم افزار و کار کردن با آن به وقوع می پیوندد. لذا لازم است یک طرح کلی به عنوان راه حلی که بتواند همه این مشکلاتِ هم جنس را در شرایط مختلف برطرف سازد، ارائه شود. به این راه حل کلی که می تواند به صورت مکرر در شرایط مختلف برای مقابله با مشکلاتی خاص به اجرا در بیاید، general repeatable solution می گویند.
دیزاین پترن یک دیزاین یا طرح تمام شده نیست که بتوان آن را به عنوان یک کدِ تکمیل شده به کد اصلی برنامه اضافه کرد. در واقع دیزاین پترن یک شرح (Description) یا یک قالب (Template) کلی است که به کد کمک می کند تا مشکلاتی را که ممکن است در شرایط مختلف و خاصی به وجود بیاید، برطرف سازد.
آشنایی بیشتر با کاربرد دیزاین پترن
دیزاین پترن در واقع سرعت فرآیند توسعه و کدنویسی را تا میزان بسیار زیادی افزایش می دهد. دلیل این افزایش سرعت نیز کاهش نیاز به آزمودن کد و آزمایش کردن برنامه در مراحل مختلف است. بدون استفاده از الگوی طراحی، برنامه در هر مرحله از کدنویسی نیاز به آزمایش کردن دارد تا خطاهای احتمالی آن نمایان شده و راه حلی برای آن ها ارائه شود.
پس Design Pattern یک الگوی توسعه ثابت شده است که می توان با استفاده از آن حجم آزمون و خطاها را کاهش داده و روند توسعه را سرعت بخشید. یک برنامه نویسی ارزشمند و تاثیرگذار، برنامه نویسی است که بتواند خطاها و ایرادات احتمالی را که تا پیش از زمان اجرا خودشان را بروز نمی دهند، پیش بینی و شناسایی کند.
استفاده مکرر از الگوی طراحی در برنامه نویسی، به جلوگیری از مشکلات احتمالی و نامحسوسی کمک می کند که در آینده می توانند منجر به بروز مشکلات و دردسرهای بزرگتری شوند. همچنین دیزاین پترن، خوانایی کد را برای کدنویسان و مهندسانی که با پترن ها آشنایی دارند، افزایش می دهد و کار کردن با کدها را برای آن ها به امری آسان تبدیل می کند.
معمولا، افراد در حوزه کدنویسی به خوبی می دانند که برای حل یک مشکل خاصِ پیش آمده، چه نوع تکنیک یا راهکاری را باید پیاده سازی کنند. اما چالش اصلی در واقع پیاده سازی و اجرای این تکنیک ها برای رنج و طیف وسیعی از مشکلات است.
دیزاین پترن، راه حل های کلی که در فرمتی خاص ذخیره سازی شده اند را برای کدنویسان مهیا می کند. پس آن ها دیگر برای رو به رو شدن با طیف وسیعی از مشکلات و خطاها نیاز به چیدمان جدید راه حل ها و ارائه تکنیک هایی که با مشکلات همخوانی داشته باشد، ندارند.
به علاوه اینکه Design Pattern سبب شده است تا تمام کدنویسان، توسعه دهندگان و فعالان این حوزه بتوانند برای عملیات پر تکراری که در مسیر کدنویسی خود با آن مواجه می شوند، از اسامی و عناوینی استفاده کنند که همگی به آن ها واقف هستند. در واقع به عبارت ساده تر، دیزاین پترن سبب به وجود آمدن یک ادبیات مشترک میان فعالان حوزه برنامه نویسی شده است.
نکته دیگر درباره دیزاین پترن این است که می توان آن را به مرور زمان ارتقا داده و بهینه سازی کرد. به این ترتیب در یک روند کلی، دیزاین پترن ها با ساختاری تکامل یافته تر و قوی تر از گذشته ظاهر می شوند و به کمک کدنویسان و برنامه نویسان می روند. دیزاین پترن انواع گوناگون دارند که در ادامه به معرفی آن ها خواهیم پرداخت.
انواع دیزاین پترن ها
1- دیزاین پترن های خلاقانه
این دیزاین پترن ها همگی در زمینه نمونه سازی Class ارائه شده اند. هر یک از این پترن ها در آینده می توانند به دو بخش مجزای Class-Creation patterns و Object-Creational patterns تقسیم شوند.
Class-Creation Pattern در زمینه نمونه سازی اولیه فعالیت می کند، در حالی که Object-Creational Pattern طرح کلی را تکمیل کرده و آن را به پترنی قابل اجرا تبدیل می کند.
- Abstract Factory
یک نمونه از خانواده های مختلفِ کلاس ها را ایجاد می کند.
- Builder
از هر آبجکت، یک ساختار کلی را به عنوان نماینده آن آبجکت جدا کرده و دسته بندی می نماید.
- Factory Method
یک نمونه از مشتقات کلاس های مختلف را ایجاد می نماید.
- Object Pool
هزینه های مربوط به تحلیل و بررسی و انتشار منابع را از راه بازیافت آبجکت هایی که دیگر مورد استفاده قرار نمی گیرند، کاهش می دهد.
- Prototype
یک نمونه کامل از مقدار دهی اولیه که کپی یا شبیه سازی شده است.
- Singleton
یک کلاس که فقط یک نمونه در آن مجاز به قرار گرفتن و حضور است.
2- دیزاین پترن های ساختاری
این نوع از دیزاین پترن ها به کامپوزیت های class و object مربوط می شوند. دیزاین پترن های ساختاری کلاس یا Structural Class-Creation Patterns، برای نوشتن رابط ها استفاده می شود. در حالی که دیزاین پترن های ساختاری آبجکت یا Structural Object-Patterns، راه هایی را برای نوشتن آبجکت هایی برای به دست آوردن عملکردهایی جدید، تعریف می کند.
- Adapter
رابط های کلاس های مختلف را به یکدیگر وصل کرده و ارتباط می دهد.
- Bridge
یک رابط آبجکتی یا Object’s interface را پیاده سازی آن جدا می کند.
- Composite
یک ساختاری درختی از آبجکت های ساده Simple Objects و آبجکت های نوشته شده Composite Objects است.
- Decorator
وظایفی را به صورت داینامیک به آبجکت ها اضافه و محول می نماید.
- Facade
یک تک کلاس یا Single Class که کل زیر سیستم را نمایش می دهد.
- Flyweight
یک نمونه کوچک برای یک به اشتراک گذاری کارآمد.
- Private Class Data
دسترسی اکسسور یا جهش دهنده را محدود می سازد.
- Proxy
یک آبجکت که آبجکت دیگری را نمایش می دهد.
3- دیزاین پترن های رفتاری
این دیزاین پترن ها مربوط به ارتباطات آبجکت های کلاس هستند. درواقع به دیزاین پترن هایی که بیشترین فعالیتشان در زمینه برقراری ارتباط میان آبجکت ها می باشد، دیزاین پترن های رفتاری یا Behavioral Design Patterns می گویند.
- Chain of responsibility
زنجیره وظایف و مسئولیت ها، راهی برای انتقال یک درخواست از میان یک زنجیره آبجکتی است.
- Command
ارائه یک کامند درخواست (Command Request) به عنوان یک آبجکت.
- Interpreter
راهی برای ادغام کردن و اضافه کردن المان های زبان برنامه نویسی در یک برنامه یا کد.
- Iterator
دسترسی به کالکشن المان ها به صورت ترتیب یافته و اولویت بندی شده.
- Mediator
ارتباطات بین کلاس ها را به صورت ساده سازی شده تعریف می کند.
- Memento
دریافت و ذخیره سازی حالت داخلی یک آبجکت.
- Null object
این پترن برای مقدار دهی پیش فرض به یک آبجکت طراحی شده است.
- Observer
راهی برای دریافت تغییرات به وجود آمده در تعدادی از کلاس ها.
- State
رفتار یک آبجکت را زمانی که حالت داخلی آن عوض می شود، تغییر می دهد.
- Strategy
ایجاد یک الگوریتم در یک کلاس.
- Template Method
انتقال گام های مشخصی از یک الگوریتم به یک زیر کلاس.
- Visitor
یک عملکرد جدید را بدون ایجاد هیچ گونه تغییری را برای یک کلاس تعریف می کند.
نقد و بررسی دیزاین پترن
تاکنون دیزاین پترن توسط بسیاری از افراد فعال در حوزه کامپیوتر و برنامه نویسی مورد انتقاد قرار گرفته است. دلایل این انتقادات به گفته بسیاری از افراد متخصص در این حوزه به شرح زیر می باشد:
-
دیزاین پترن هدف را اشتباه شناسایی می کند.
پترن ها برای آنکه بتوانند وظایف خود را به درستی انجام دهند و آنچه را که برای تحققش ایجاد شده اند به درستی پیاده سازی کنند، نیاز به ابزارها و مایحتاج خاصی دارند. آن ها این احتیاجات خود را از زبان برنامه نویسی یا تکنیک هایی که برنامه نویس از آن ها برای کدنویسی استفاده کرده است، دریافت می کنند.
این تکنیک ها در توانایی برداشت و انتقال مفاهیم به تنهایی کافی نیستند. در یک فاکتورینگ ایده آل، مفاهیم نباید کپی شوند، بلکه باید ارجاع دهی شوند. یعنی نباید از تکنیک Copy به جای تکنیک Reference برای مفاهیم یا concept ها استفاده کرد. اما اگر موضوعی به جای کپی شدن، ارجاع دهی شود، آن وقت دیگر پترنی برای آن وجود ندارد. در این صورت هیچ پترنی را نمی توان به آن موضوع الحاق کرده و به عنوان label ضمیمه آن کرد.
-
عدم وجود پایه و اساس رسمی برای Design Pattern
مطالعه دیزاین پترن به امری بسیار افراطی تبدیل شده است تا جایی که عده ای از متخصصان بر سر ایجاد یک پایه و اساس یکپارچه و رسمی برای آن با یکدیگر به جدال می پردازند.
-
دیزاین پترن به راه حل هایی ناکارآمد منتهی می شود.
در وهله اول، مطالعه درباره دیزان پترن و آشنایی با آن ممکن است این تفکر را در ما پدید آورد که با یک مقوله بسیار کارآمد و کمک کننده در دنیای توسعه و کدنویسی مواجه هستیم، اما در عمل متوجه خواهیم شد که بسیاری از مواقع استفاده از پترن دیزاین تنها منجر به داپلیکیت شدن های بی دلیل و ناکارآمدی کدها می شود و عملا مشکلی را حل نمی کند.
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.