وقتی امروز درباره Design Pattern حرف می زنیم، معمولاً ذهن مان می رود سمت برنامه نویسی، کلاس ها، objectها و اسم هایی مثل Factory، Observer یا Strategy.

اما جالب است بدانید ایده Pattern اول از دنیای نرم افزار شروع نشد.

قبل از اینکه برنامه نویس ها درباره Design Pattern صحبت کنند، معمارها دنبال راهی بودند تا تجربه های موفق طراحی را ثبت کنند؛ تجربه هایی که در ساخت خانه ها، خیابان ها، میدان ها و فضاهای شهری بارها تکرار می شدند.

این مقاله قرار نیست دوباره تعریف Design Pattern را از اول توضیح دهد. اینجا می خواهیم ببینیم این ایده از کجا آمد، چطور وارد نرم افزار شد و چرا هنوز هم بعد از سال ها درباره آن صحبت می کنیم.

شروع ماجرا از معماری بود

یکی از نام های مهم در تاریخچه Patternها، Christopher Alexander است؛ معمار و نظریه پردازی که روی الگوهای تکرارشونده در طراحی فضاهای انسانی کار می کرد.

او به این فکر می کرد که در طراحی ساختمان ها و شهرها، بعضی مسئله ها همیشه تکرار می شوند.

مثلاً اینکه یک فضای عمومی چطور باید طراحی شود تا مردم دوست داشته باشند در آن بمانند.
یا ورودی یک ساختمان چطور می تواند حس دعوت کنندگی داشته باشد.
یا چطور می شود بین نور، مسیر حرکت، فضاهای خصوصی و فضاهای عمومی تعادل ایجاد کرد.

Alexander تلاش کرد این تجربه ها را به شکل Pattern ثبت کند.

یعنی به جای اینکه فقط بگوید «این طراحی خوب است»، توضیح بدهد:

در چه شرایطی این مسئله به وجود می آید؟
چه نیازی پشت آن وجود دارد؟
و چه راه حلی معمولاً در چنین موقعیتی جواب می دهد؟

این نگاه بعدها برای دنیای نرم افزار الهام بخش شد.

چرا برنامه نویس ها به Pattern علاقه مند شدند؟

نرم افزار هم مثل معماری، پر از مسئله های تکراری است.

هر پروژه ای شکل و جزئیات خودش را دارد، اما خیلی از چالش های طراحی در پروژه های مختلف شبیه هم اند.

مثلاً تیم ها بارها با این مسئله ها روبه رو می شوند:

چطور ساخت objectها را از منطق اصلی جدا کنیم؟
چطور وابستگی بین بخش های مختلف سیستم را کمتر کنیم؟
چطور تغییرات یک بخش را به بخش های دیگر اطلاع دهیم؟
چطور رفتارهای مختلف را بدون شلوغ کردن کد مدیریت کنیم؟

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

این اتفاق یک مزیت مهم داشت:

تیم ها می توانستند درباره طراحی نرم افزار با زبان مشترک صحبت کنند.

وقتی یک نفر می گفت «اینجا Observer به درد می خورد»، لازم نبود کل ایده را از صفر توضیح دهد. خود اسم Pattern، یک مفهوم طراحی را منتقل می کرد.

نقطه عطف: کتاب Gang of Four

مهم ترین نقطه در تاریخچه Design Patternهای نرم افزاری، کتاب معروف Design Patterns: Elements of Reusable Object-Oriented Software بود.

این کتاب توسط چهار نفر نوشته شد:

Erich Gamma، Richard Helm، Ralph Johnson و John Vlissides.

این چهار نفر بعدها با نام Gang of Four یا به اختصار GoF شناخته شدند.

کتاب GoF در سال ۱۹۹۴ منتشر شد و ۲۳ Design Pattern کلاسیک را معرفی کرد؛ Patternهایی که هنوز هم در آموزش ها، مصاحبه ها، code reviewها و بحث های معماری نرم افزار استفاده می شوند.

اما ارزش اصلی این کتاب فقط معرفی ۲۳ اسم نبود.

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

بعد از این کتاب، developerها می توانستند درباره ساخت object، ارتباط بین objectها، مسئولیت کلاس ها و تغییرپذیری سیستم با واژه های دقیق تری صحبت کنند.

چرا کتاب GoF این قدر اثرگذار شد؟

برای اینکه اهمیت این کتاب را بهتر بفهمیم، باید فضای آن زمان را تصور کنیم.

در دهه ۹۰ میلادی، برنامه نویسی شیءگرا یا Object-Oriented Programming بسیار پررنگ بود. زبان هایی مثل C++ و Java در حال رشد بودند و تیم ها می خواستند سیستم هایی بسازند که قابل توسعه، قابل نگهداری و قابل استفاده مجدد باشند.

اما فقط داشتن class و object کافی نبود.

مسئله اصلی این بود که:

کلاس ها چطور باید با هم ارتباط داشته باشند؟
مسئولیت ها چطور باید تقسیم شوند؟
وابستگی ها چطور باید کنترل شوند؟
و تغییرات آینده چطور باید ساده تر شوند؟

Design Patternها دقیقاً در چنین فضایی جدی شدند.

آن ها کمک کردند بحث برنامه نویسی از سطح syntax بالاتر برود و به سطح طراحی برسد.

به جای اینکه فقط بپرسیم «چطور این کد را بنویسیم؟»، شروع کردیم به پرسیدن سؤال های بهتر:

چرا این مسئولیت اینجاست؟
آیا این بخش بیش از حد به بخش دیگر وابسته شده؟
اگر فردا این رفتار تغییر کند، چند جای سیستم باید تغییر کند؟

این همان جایی است که Design Patternها ارزش واقعی پیدا می کنند.

دسته بندی کلاسیک Design Patternها

یکی از کارهای مهم کتاب GoF، دسته بندی Patternها بود.

این دسته بندی هنوز هم یکی از بهترین راه ها برای یادگیری Design Patternهاست.

Creational Patterns درباره ساخت objectها هستند.
یعنی کمک می کنند منطق ساخت objectها کنترل شده تر و قابل تغییرتر باشد.

Structural Patterns درباره ساختار و ترکیب بخش های مختلف سیستم هستند.
یعنی کمک می کنند objectها، classها یا moduleها بهتر کنار هم قرار بگیرند.

Behavioral Patterns درباره رفتار و ارتباط بین بخش های مختلف سیستم هستند.
یعنی کمک می کنند همکاری بین objectها تمیزتر و قابل مدیریت تر شود.

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

Design Patternها بعد از GoF

بعد از کتاب GoF، Design Patternها به سرعت وارد دنیای آموزش، مصاحبه های فنی، کتاب های نرم افزاری و فریم ورک ها شدند.

برای سال ها، دانستن Patternها یکی از نشانه های جدی تر شدن در برنامه نویسی محسوب می شد.

اما مثل هر ابزار دیگری، استفاده اشتباه از آن ها هم زیاد شد.

بعضی developerها شروع کردند به پیدا کردن Pattern برای هر مسئله کوچک. گاهی برای یک منطق ساده، چندین class و interface ساخته می شد فقط برای اینکه کد «حرفه ای تر» به نظر برسد.

این نگاه بعدها نقد شد.

کم کم جامعه نرم افزار به نگاه بالغ تری رسید:

Design Patternها ابزارند، نه هدف.

قرار نیست هرجا که شد از Pattern استفاده کنیم. Pattern زمانی ارزش دارد که واقعاً مسئله ای را ساده تر، قابل فهم تر یا قابل نگهداری تر کند.

آیا Design Patternها هنوز کاربرد دارند؟

بله، اما نه همیشه به شکل کلاسیک گذشته.

امروز زبان ها و فریم ورک ها تغییر کرده اند. JavaScript، TypeScript، React، NestJS، Express، Angular و معماری های مدرن باعث شده اند شکل استفاده از Patternها متفاوت شود.

بعضی Patternها در زبان های جدید ساده تر شده اند.
بعضی ها داخل فریم ورک ها پنهان شده اند.
بعضی ها هم دیگر مثل گذشته زیاد استفاده نمی شوند.

اما مسئله هایی که Patternها برای آن ها ساخته شدند هنوز وجود دارند.

هنوز هم باید object بسازیم.
هنوز هم باید وابستگی ها را مدیریت کنیم.
هنوز هم باید رفتارهای قابل تغییر را کنترل کنیم.
هنوز هم باید بین بخش های مختلف سیستم ارتباط تمیز بسازیم.

برای همین، یادگیری Design Patternها هنوز ارزش دارد؛ به شرطی که آن ها را به عنوان ابزار فکر کردن ببینیم، نه فرمول های آماده.

جمع بندی

Design Patternها از دنیای معماری الهام گرفتند؛ از این ایده که می شود راه حل های موفق برای مسئله های تکراری را ثبت کرد و دوباره به کار گرفت.

بعدها این نگاه وارد دنیای نرم افزار شد و با کتاب معروف Gang of Four به یکی از پایه های مهم طراحی نرم افزار شیءگرا تبدیل شد.

اما نکته مهم این است که Design Patternها قرار نیست ما را مجبور کنند کد را پیچیده تر بنویسیم.

آن ها قرار است به ما کمک کنند مسئله را بهتر ببینیم، درباره راه حل ها دقیق تر صحبت کنیم و تصمیم های طراحی بهتری بگیریم.

در مقاله بعدی، سراغ دسته بندی Design Patternها می رویم و بررسی می کنیم تفاوت Creational Patterns، Structural Patterns و Behavioral Patterns چیست.

تاریخچه دیزاین پترن ها؛ از معماری تا دنیای نرم افزار

علی صفری

نظرات