الگوها

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

در این قسمت، مایکل و مارکوس در ارتباط با الگوها صحبت می‌کنند. آن‌ها با الگوهای «بیشتر استفاده شده» خود آغاز کرده و به سراغ برخی جزییات تاریخچه الگوها می‌روند. سپس اشکال مختلف الگوها و همین‌طور برخی تصورات غلط درباره الگوها را توضیح می‌دهند. بحث‌های دیگر این مصاحبه شامل حوزه‌هایی که الگوها آن‌ها را پوشش داده‌اند و همین‌طور زبان‌های الگو است.

۳ مثال خیلی مطرح از الگوها که می‌توانید عنوان کنید، کدامند؟

فکر می‌کنم الگویی که بیشترین استفاده را داشته و احتمالاً بیش از همه شناخته شده است، الگوی ناظر (Observer) است که در آن یک شیء، مجموعه‌ای از اشیاء دیگر را از وقوع تغییرات باخبر می‌کند. مثلاً اگر یک برنامه گرافیکی داشته باشید که در آنجا چند منظر (View) داشته باشید که تغییراتی در نوعی ساختارهای داده را انعکاس می‌دهند، وقتی ساختار داده تغییر می‌کند، اشیاء مختلف، اشیاء منظر را از تغییرات باخبر می‌کند و اشیاء منظر، در مورد داده‌های تغییریافته پرس‌وجو می‌کنند و خود را متناظر با آن تغییر می‌دهند.

الگوی معروف دیگر، احتمالاً الگوی نماینده (Proxy) است. این الگو، همیشه در سیستم‌های از راه دور (Remoting Systems) استفاده می‌شود. به‌جای اینکه با یک شیء مستقیم صحبت کنید -که در مورد شیء‌های دور (Remote Objects) امکانپذیر نیست- با یک شیء محلی صحبت می‌کنید که مانند شیء دور به نظر می‌رسد و شیء محلی یا همان نماینده، همه فراخوانی‌ها را از طریق شبکه یا روش‌های دیگر، به شیء دور، ارسال می‌کند.

الگوی دیگر، الگوی رآکتور (Reactor) است. فکر کنم بهتر باشد که شما توضیحش دهید.

رآکتور، اساساً کارهای ناهمبسته‌سازی (Decouple)، مقسم‌سازی (Demultiplexing) و توزیع (Dispatching) رخدادها را انجام می‌دهد. به‌عنوان مثال، در مورد رخدادهای شبکه این کار را انجام می‌دهد و این امور را از منطقی که برنامه برای رسیدگی به رخدادها دارد مجزا می‌سازد. در یک طرف رآکتور را دارید و در طرف دیگر رسیدگی‌کننده‌هایی (Handler) دارید که برای رخدادهای مختلف در رآکتور ثبت‌نام (Register) می‌شوند. هرگاه یک رخداد ثبت‌نام شده رخ دهد، رسیدگی‌کننده موردنظر درگیر شده و به آن عکس‌العمل نشان می‌دهد.

آیا این الگو، غالباً در سیستم‌های مقیاس‌پذیرِ چندنخی (Multithread) استفاده می‌‌شود؟

در واقع در سیستم‌های چندنخی خیر. رآکتور می‌تواند به خوبی برای طراحی برنامه‌های تک‌نخی مقیاس‌پذیر استفاده شود. البته می‌توانید در محیط‌های چندنخی نیز با آن کار کنید. در آن صورت به الگوهای دیگر مثلاً الگوی پیشوا-پیروان (Leader/Followers) نیاز دارید تا به همروندی، بپردازید.

بسیار خوب. قبل از اینکه بخواهیم به جزییات زیاد بپردازیم بهتر است که کمی در مورد تاریخچه الگوها صحبت کنیم. فکر کنم کانینگهام اولین کسی باشد که بخواهیم در موردش صحبت کنیم. درسته؟

کانینگهام و کنت بک در سال ۱۹۸۷ کار بر روی مستندسازی حداقل ۵ الگوی واسط کاربری (User Interface) را آغاز کردند و آن را در c2.com مستند کردند. از آنجا بود که همه چیز شروع شد. در دهه ۹۰ اریک گاما ، این سبک نگارش الگو را آغاز کرد که بعداً در سال ۱۹۹۵ به کتاب معروف الگوهای طراحی انجامید که توسط اریک گاما ، ریچارد هلم ، راف جانسون و جان وسیدس، معروف به دسته چهارتایی‌ها (Gang of Four)، نوشته شد.

جالب است زیرا فکر می‌کنم غالب افراد فکر می‌کنند که کتاب GOF، اولین نوشته در مورد الگوها در دنیای IT بوده است اما اینطور نیست.

بله، کمی بعد از GOF، کار کتاب معماری نرم‌افزار الگو‌گرا (Pattern Oriented Software Architecture) آغاز شد که بوشمن ، منییِر ، رونرت ، سامرلد و استال نویسندگان جلد اول کتاب بودند. بیشتر آن را با عنوان POSA1 می‌شناسند.

تفاوت‌هایی بین الگوهای کتاب GOF و کتاب POSA هست. الگوهای کتاب GOF، الگوهای طراحی کلاسیک هستند. محتوای کتاب POSA1 چیست؟

بله. POSA1 در ارتباط با الگوهای معماری است. گاهی با عنوان سبک‌های معماری (Architectural Styles) نیز نامیده می‌شود.

بسیار خوب. قبل از آنکه بخواهیم در مورد محتوای برخی الگوهای خاص صحبت کنیم، فکر می‌کنم بهتر باشد یک نگاهی به شکل الگوها بیاندازیم. الگوها با یک روش کاملاً مشخص، مستند می‌شوند. در واقع، چندین روش وجود دارد. فکر می‌کنم در کتاب GOF برای هر الگو، ۱۱ بخش داریم. درسته؟

بله، فکر می‌کنم.

مهمترین آنها، زمینه (Context)، مسأله (Problem) و راه حل (Solution) است. اگر بخواهیم الگو را تعریف کنیم گفته می‌شود الگو، مسأله‌ای معروف در یک زمینه خاص است که راه حل مشخصی دارد. مستندسازی یک الگو تنها در صورتی معنی می‌دهد که افراد زیادی با مسأله‌اش احتمالاً در زمینه‌های تکنیکی مختلف مواجه شده باشند و راه‌حل‌های مختلفی داشته باشد. بخش زمینه یک الگو هر محیط یا شرایطی که در ارتباط با نرم‌افزار دارید را توضیح می‌دهد. بعد از آن بخش مسأله مطرح می‌شود و بعد از آن راه حل را نشان می‌دهید که کمک می‌کند در آن زمینه خاص مسأله را حل کنید. بخش مهم دیگر الزامات (Forces) است. شما تنها در صورتی می‌توانید یک مسأله را به یک روش خاص حل کنید که بدانید هنگام حل آن، چه مواردی را باید در نظر داشته باشید؛ مواردی از قبیل اینکه سیستم باید سریع اجرا شود یا اینکه کمترین مقدار ممکن از حافظه را مصرف کند. وقتی دارید در یک الگو مسأله را توضیح می‌دهید همواره باید الزاماتی که شما را در جهت یافتن راه حل کمک می‌کند را توضیح دهید. به این شکل یک دانش قابل استفاده مجدد تهیه می‌شود که دیگران می‌توانند آن را بخوانند و در محیط یا نرم‌افزار خودشان به‌کار گیرند.

در این مورد، من اغلب اصطلاحِ ‌زمینه حاصل (Resulting Context) را می‌شنوم. زمینه حاصل شده از یک الگو واقعاً چیست؟

اگر راه‌حل یک الگو را توضیح دهید و آن راه‌حل به روش خاصی مسأله را با درنظر گرفتن الزاماتش حل کند، بعد از پیاده‌سازی آن راه حل، پیامدهایی حاصل خواهد شد. مثلاً اینکه حل مسأله به یک روش، باعث می‌شود سیستم خیلی سریع شود یا کند شود یا کوچک شود یا مقیاس‌پذیر باشد یا ... . بعد از آن، می‌توانید مسائل جدیدی که با بکارگیری آن الگو، به‌وجود می‌آیند را توضیح دهید که جاده را برای الگوهای دیگری که در ادامه الگوی کنونی می‌آیند باز می‌کند. به این ترتیب که اگر شما فلان الگو را پیاده‌سازی کنید، می‌توانید پیاده‌سازی الگوی دیگری را نیز در نظر بگیرید زیرا پیامد حاصل شده از آن، چنین چیزی را توصیه می‌کند. این موضوع خصوصاً در زبان‌های الگو (Pattern Languages) و دنباله‌‌های الگو (Pattern Sequences) اهمیت می‌یابد که فکر می‌کنم بعداً در مورد آن توضیح دهیم.

من می‌دانم برای الگوها، شکل الکساندری وجود دارد، شکل GOF را داریم، POSA هم شکل خودش را دارد، شکل پورتلند را هم داریم و ... . تفاوت‌های اصلی میان این شکل‌ها چیست؟ چرا شکل‌های مختلفی وجود دارد؟

فکر می‌کنم جامعه قبول دارد که همان‌ طور که قبلاً گفتم الگو بیان یک مسأله در یک زمینه خاص با یک راه حل خوب است. با این وجود انواع مختلفی از الگوها وجود دارد که در ادامه خواهیم دید. این الگوهای مختلف می‌توانند در شکل‌های لفظی متفاوتی بهتر توضیح داده شوند. به‌عنوان مثال، اگر الگویی داشته باشید که خیلی فنی باشد و مربوط به تکنیک طراحی باشد، شکل GOF می‌تواند خیلی مفید باشد زیرا در این شکل، بخش‌هایی مانند ساختار (Structure) را دارید که عموماً در آنجا یک نمودار کلاسی یا چیز مانند آن می‌افزایید و همین طور بخش تعاملات (Interactions) را دارید که در آنجا از نمودار توالی (Sequence Diagram) یا چیزهای شبیه به آن استفاده می‌کنید تا نشان دهید که تعاملات میان شرکت‌کنندگان در الگو چگونه شکل می‌گیرد. با این وجود اگر یک الگوی سازمانی (Organizational Pattern) داشته باشید -که ما چند دقیقه دیگر در مورد آن صحبت خواهیم کرد- این الگوها لزوماً نمی‌توانند با این‌گونه اصطلاحات و نمودارهای فنی بیان شوند. بنابراین شکل‌های دیگری وجود دارد که برای این نوع از الگوها، مفیدتر است.

در مورد شکل الکساندری، جالب است که این شکل در اصل توسط کریستوفر الکساندر ، ابداع شده است که یک معمار ساختمان است و ارتباطی با نرم‌افزار ندارد. او کسی است که در اصل، استفاده از این شکل الگوها برای توضیح دادن چیزها را اختراع کرد. او کتابی با عنوان یک زبان الگو نوشت که فکر می‌کنم ۲۵۳ الگو دارد که در قالب یک زبان الگو سازماندهی شده‌اند. او کمک می‌کرد که افراد طراحی‌های خوبی برای شهرها، ساختمان‌ها، اتاق‌های نشیمن‌ و چیزهای شبیه به آن داشته باشند. او از شکل خاصی استفاده می‌کرد که ساختار خیلی کوچکی داشت. اینطور نبود که مثلاً ۱۱ زیربخش داشته باشد، فکر می‌کنم ۴ یا ۵ بخش داشت. اگر درست به‌خاطر بیاورم، زمینه، مسأله و الزامات آن، راه‌حل، زمینه حاصل و بعد هم مثال‌ها بود. چنانچه بخواهید چیزهای غیرفنی را توضیح بدهید، این شکل، خوب است. البته می‌توانید مباحث فنی را هم با آن توضیح دهید همان طور که ما در کتابمان، برای توضیح دادن زیرساخت‌های امور راه دور (Remoting Infrastructure) استفاده کردیم.

شکل GOF، با یک تیتر آغاز می‌شود و بعد بخش‌های کوچکی، شاید یکی دو بخش داریم که هدف الگو را بیان می‌کند. سپس، با توضیح انگیزه (Motivation) ادامه می‌دهیم که عموماً یک شرایطی است که شما دوست دارید از الگو استفاده کنید. بخش بعدی، محل‌های قابل استفاده (Applicability) است که توضیح می‌دهیم در حالت کلی در چه شرایطی این الگو به‌کار می‌آید. نکته جالب این است که واقعاً هیچ بخشی که عنوانش دقیقاً راه حل باشد وجود ندارد. در ادامه بخش ساختار را داریم که ساختار راه حل توضیح داده می‌شود. سپس، شرکت‌کننده‌های مختلف توضیح داده می‌شوند به‌عنوان مثال، در مورد الگوی ناظر (Observer)، (در بخش شرکت‌کننده‌ها)، موضوع (Subject) را داریم که تغییرات را خبر می‌دهد و ناظر‌ها را داریم که چیزهایی هستند که باید از تغییرات آگاه شوند. بعد تعاملات را دارید که از یک دیدگاه پویا (Dynamic) به نحوه تعاملات بین شرکت‌کننده‌ها می‌پردازد. بعد پیامدها (Consequences) را داریم و بعد یک بخش مهم در مورد طراحی‌های سطح پایین یا پیاده‌سازی کدهای الگو داریم. معمولاً می‌توانید یک الگو را به روش‌های مختلفی پیاده‌سازی کنید. در بخش پیاده‌سازی، نحوه پیاده‌سازی یک الگو به‌صورت گام‌ به گام نمایش داده می‌شود و اگر روش‌های متنوعی برای پیاده‌سازی باشد آنها را نشان می‌دهد. بخش بعدی، کد مثالی (Sample Code) است که حتی کدهای بیشتری را فراهم می‌کند و مرتبط با انگیزه مقدماتی مطرح شده است. و بعد یک بخش خیلی مهم در توضیح الگوها داریم که استفاده‌های شناخته شده (Known Uses) است؛ یک الگو چیزی نیست که شما اختراعش کنید بلکه چیزی است که با کاوش سیستم‌های موجود، استخراجش می‌کنید. برای اینکه اثبات کنید که چیزی که توضیح داده‌اید، یک راه حلی است که شناخته شده هست و به خوبی برای حل مسأله استفاده شده است، برخی استفاده‌های شناخته شده آن را فهرست می‌کنید و توضیح می‌دهید. در انتها، شکل GOF با بخش ارجاع به تعدادی الگوهای مرتبط دیگر پایان می‌پذیرد که نقشه راهی از خلال کتاب برایتان فراهم می‌آورد.

لطفاً شما هم کمی در مورد شکل POSA صحبت کنید.

شکل POSA یک شکل دیگر است که در ۳ جلد گذشته کتاب استفاده شده است (در زمان مصاحبه یعنی سال ۲۰۰۶ سه جلد از کتاب POSA منتشر شده بود. در سال ۲۰۰۷ جلدهای ۴ و ۵ کتاب POSA هم منتشر شدند - مترجم). این شکل بیشتر مربوط به همان کتاب POSA است. شاید به‌ همین خاطر من شکل POSA را بیشتر دوست دارم. در شکل POSA، صریحاً یک بخش با عنوان راه حل وجود دارد و صریحاً الزامات را برجسته و فهرست می‌کند. من فکر می‌کنم خیلی باارزش است که بدانیم مصالحه‌هایی (Tradeoff) که در ارتباط با الگو وجود دارد و باید در نظر بگیریم، کدامند؟ همچنین در این شکل، صریحاً یک بخش با عنوان گونه‌ها (Variations) داریم که در آنجا تعدادی از گونه‌های مشخصی که درباره بطن الگو وجود دارد مستند می‌شود بنابراین به جای اینکه برای آن فقط یک الگو داشته باشید، گونه‌هایی از آنها را خواهید داشت. به‌غیر از آن، بخش‌های زیادی هم مشترک (با شکل GOF) است. در اینجا، بخش زمینه (Context) معادل با بخش انگیزه (Intent) [در کتاب GOF] است.

بگذارید به برخی برداشت‌های نادرست در مورد الگوها بپردازیم. فکر می‌کنم چندین مورد وجود دارد. آیا دوست دارید توضیح دهید؟

بله، خیلی می‌شنوم که الگوها به‌عنوان یک طرح UML نگریسته می‌شوند. اینکه الگوها همواره باید یک ساختار پیاده‌سازی و کلاسیِ شی‌ءگرا داشته باشند و الگوها فقط درمورد شیءگرایی هستند. این درست نیست. الگوها را می‌توانید برای سیستم‌های دیگر هم به‌کار بگیرید. حتی برای روش‌های غیرشیءگرای حل مسأله و برنامه‌نویسی. در برخی ابزارهای مهندسی نرم‌افزار به کمک کامپیوتر (Computer Aided Software Engineering) که امروزه ابزارهای مهندسی نرم‌افزار مبتنی بر مدل (Model Driven Software Development) خوانده می‌شوند، چیزهایی وجود دارد که طرح‌های اولیه (Blueprint) خوانده می‌شوند و الگوهایی وجود دارد اما باید در مورد اینکه آنها چه هستند دقت داشته باشید. دوست دارم شما در مورد این مطلب ادامه دهید.

بله، این چیزی است که من نظر صریحی در مورد آن دارم. اغلب ابزارهای توسعه مبتنی بر مدل در مورد پیاده‌سازی الگوها به‌صورت خودکار صحبت می‌کنند که تا حدی بی‌معنی است. از یک طرف، اگر تصمیم بگیرید که می‌خواهید یک الگوی خاص را در یک شرایط خاص به‌کار ببرید، می‌توانید با ابزار تولیدکننده خود، ابزار توسعه مبتنی بر مدل یا ... مطمئن شوید که ابزار، الگوی مورد نظر را در کدی که تولید می‌کند، پیاده‌سازی می‌کند اما اینکه الگو را به چیزی که در چنین ابزارهایی خودکار شده، تنزل دهیم واقعاً ایده بدی است زیرا الگوها اساساً، [از جنس] مستندات هستند. جنبه‌های خیلی زیادی وجود دارد که نمی‌تواند خودکار شود. مواردی از قبیل الزامات، راهنمایی‌هایی که شما را هدایت می‌کند که آیا از الگو استفاده کنید و از کدام‌یک از گونه‌ها استفاده کنید و چرا و چگونه این کار را بکنید، این موارد چیزهایی نیستند که بتوانید به‌راحتی در ابزارها، خودکار کنید. بهتر است اصطلاح الگو را از خودکارسازی‌های تولید کد موجود در ابزارها مجزا کنیم. احتمالاً بهتر است آنها را قالب (Template) بنامیم. البته اگر قالب‌هایی دارید که الگوی ناظر (Observer) را پیاده‌سازی می‌کنند، خوب است که بگویید تولیدکننده کد، در داخل خود از الگوی ناظر استفاده می‌کند.

برداشت نادرست دیگر که متداول است این است که الگوها، نوآوری هستند. در واقع، برعکس است. الگوها سرمشق (Best Practice) هستند. الگوها باید بکارگیری‌های شناخته شده‌ای در سیستم‌های موجود داشته باشند بنابراین دیگر نوآوری نیستند. با این حال به منظور مستندسازی و تبادل سرمشق‌ها خیلی ارزشمند هستند. به‌عنوان مثال برای حوزه‌های جدید برنامه‌نویسی، مثلاً در زمینه مهندسی نرم‌افزار جنبه‌گرا (Aspect Oriented) چنانچه الگوها را از ابتدا تنها بر پایه تجربیات خودمان بسازیم، الگو نیستند. باید حوزه‌ای که می‌خواهیم کار کنیم، بالغ شده باشد. افراد باید ابتدا بیاموزند و تجربه‌هایی داشته باشند و بعد با همدیگر، الگوها را استخراج نمایند.

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

بله.

بیایید به برخی حوزه‌ها که با الگوها پوشش داده شده‌اند، نگاهی بیاندازیم. فکر می‌کنم اکثر افراد، کتاب GOF را می‌شناسند بنابراین با الگوهای طراحی آشنا هستند. [الگوهای طراحی]، الگوهایی هستند که کمک می‌کنند طراحی شیء‌گرای بهتری داشته باشید. این کمترین چیزی است که افراد باید از الگوها بدانند. فکر می‌کنم همه این را می‌دانند اما بیایید کمی در مورد برخی حوزه‌های الگوها که خیلی شناخته شده نیستند، صحبت کنیم.

نزدیکترین این حوزه‌ها، حوزه معماری نرم‌افزار است و قطعاً POSA1 یکی از مثال‌های این حوزه است. همچنین موارد دیگر مثلاً الگوهای طراحی واسط کاربری، الگوهای تعاملات کاربر، الگوهای تست و الگوهای تدریس را داریم. آیا می‌خواهید در مورد الگوهای تدریس توضیح دهید؟

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

حوزه بعدی، مستندسازی است. در این‌باره، کتاب الگوهای مستندسازی چابک را داریم که نوشته اندرآس روپینگ است. حوزه دیگر، حوزه سازمانی است که اخیراً جیمز کوپلین و نیل هریسون به آن پرداخته‌اند (اشاره به کتاب الگوهای سازمانی توسعه چابک نرم‌افزار - مترجم) که قطعاً ارزش خواندن دارد و چیزهای زیادی می‌توانید از آن فرا بگیرید.

همچنین کتاب‌هایی در مورد الگوهای میان‌افزارها (Middleware) و چیزهای زیرساختی از قبیل امور راه دور (Remoting) و مؤلفه‌ها (Component) وجود دارد که فکر می‌کنم بهتر باشد در قسمت‌های بعدی به آنها بپردازیم بنابراین اینجا وارد جزییات نمی‌شویم. درسته؟

بله.

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

بله. PLoP مخفف زبان‌های الگوی برنامه‌نویسی (Pattern Languages of Programming) است و در اوایل دهه ۹۰ آغاز شد. فکر می‌کنم اولین کنفرانس سال ۱۹۹۴ بود. این کنفرانس‌ها یک شکل خیلی رایج دارند که رخداد‌ مهم در آنها، کارگاه‌های نویسندگان است. ممکن است توضیح دهید که یک گارگاه نویسنده چیست؟

بله، ایده کنفرانس‌های در مورد الگو، این نیست که افراد بیایند و کارهای‌شان را به مخاطبینی نشان دهند که آنجا هستند و نشسته و گوش می‌دهند. البته، نویسنده‌ها به آنجا می‌روند و کارشان را عرضه می‌کنند اما بعد از آن، بازخورد می‌گیرند. اولین گام در این کنفرانس‌ها چیزی است که شبانی (Shepherding) خوانده می‌شود. شما مقاله‌تان را می‌فرستید و بعد یک نویسنده باتجربه در حوزه الگو، یک بازخورد بسیار دقیق در سطح ریز جزییات به شما می‌دهد. این روندی است که حدود ۲ ماه طول می‌کشد که معمولاً ۲ تا ۴ مرحله خواهد داشت. در نتیجه، الگوی شما نه تنها از نظر محتوا بلکه از لحاظ ساختار و زبان نیز نسبت به مقاله ارسالی اولیه بهتر خواهد شد. گام بعدی این است که به کنفرانس می‌روید و همه را ملاقات می‌کنید و کلی خوش خواهد گذشت! بعد در کارگاه نویسنده، معمولاً گروهی حدود ۶ تا ۱۲ نفر حضور دارند که معمولاً به‌صورت گرد نشسته‌اند. شما به‌عنوان نویسنده چیز زیادی نمی‌گویید، بلکه آنجا می‌نشینید و به توضیحات همکاران‌تان که الگوی شما را توضیح می‌دهند، گوش می‌دهید. آنها می‌گویند که از چه چیز الگوی شما خوش‌شان می‌آید و شما برخی ایده‌های خوب را تأیید می‌کنید. آنها همچنین به شما می‌گویند که چه چیزی در الگو باید بهبود داده شود. بعد از معمولاً حدود نیم ساعت که به حرف‌هایشان گوش دادید، ایده‌های زیادی در مورد چگونگی بهبود الگوی‌تان می‌گیرید. در نتیجه، بعد از آنکه الگویی، چنین کارگاهی را طی می‌کند، معمولاً خیلی بهتر می‌شود. حداقل از دیدگاه خوانایی بهتر می‌شود و این کمک می‌کند که کیفیت الگوهایی که منتشر می‌شود افزایش یابد.

بسیار خوب. و کنفرانس PLoP اصلی همانی است که در ایلینویز آمریکا برگزار می‌شود اما انشقاق‌هایی از آن در اروپا مثلاً در اسکاندیناوی و آلمان و همین طور در جنوب آفریقا برگزار می‌شود.

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

یک لینک خوب برای بررسی، hillside.net است. این گروه انجمنی درباره الگوها است. در آنجا همه اطلاعات و لینک‌های مرتبط در مورد انجمن، الگوها، کتاب‌های نوشته شده و تقریباً همه چیز را می‌یابید.

پیش از این در مورد اصطلاح زبان الگو (Pattern Language) صحبت کردیم. فکر می‌کنم باید در مورد اصطلاحات و ادبیات الگوها کمی بیشتر صحبت کنیم. آیا می‌خواهید شروع کنید؟

بله. کتاب POSA1 اصطلاح سیستم الگوها (System of Patterns) را مطرح کرد که الگوهایی هستند که ارتباط سستی با هم دارند. گاهی از اصطلاح کاتالوگ هم برای آن استفاده می‌شود. از طرفی، اصطلاح الگوی مرکب (Compound Pattern) را هم داریم به‌عنوان مثال الگوی بروکراسی (Bureaucracy Pattern) از دریک‌ ریله یک الگوی مرکب است. الگوی مرکب شامل ترکیب خلاقانه الگوهای دیگر است. به‌عنوان مثال در مورد الگوی بروکراسی، در داخل خودش از الگوی ترکیب (Composite)، الگوی واسط (Mediator)، الگوی زنجیره مسئولیت‌ها (Chain of Responsibilities) و الگوی ناظر (Observer) برای رسیدن به راه‌حل موردنظرش استفاده کرده است.

یعنی تعدادی از الگوهای موجود را برمی‌دارید و آنها را ترکیب کرده و اسم جدیدی به آنها می‌دهید؟

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

بسیار خوب. مورد بعدی از اصطلاحات الگوها، دنباله‌های الگو (Pattern Sequences) است.

بله، دنباله‌های الگو موضوعی است که همچنان در حال بالغ شدن است. دنباله الگو اساساً توضیح می‌دهد که چطور سیستم نمو می‌کند. اینکه اولین الگویی که استفاده شده است کدام است؟ الگوی دوم کدام بوده است؟ در واقع، اصلاح کردن و توسعه گام به گام معماری‌تان است. دنباله الگوها، یک روش مفید به منظور اصلاحات گام به گام برای ساختن سیستم با استفاده از الگوها است.

بسیار خوب، احتمالاً روشی برای ترکیب کردن الگوها که بیش از همه سازماندهی‌ شده باشد، زبان‌های الگوها است.

بله، زبان‌های الگو، چندین دنباله الگو را برای یک حوزه خاص با هم ترکیب می‌کند. به‌عنوان مثال در حوزه‌ای مانند امور راه دور، زبان الگو، متداول‌ترین و کارآمدترین الگوهای حوزه و همین طور مصالحه‌ها (Trade-off) و گزینه‌های جایگزین (Alternative) آنها را مستند می‌کند. هرگاه الگویی را انتخاب کنید بسته به زمینه‌ای که حاصل می‌شود، در نتیجه آن الگوهای دیگر را اختیار می‌کنید و با عبور از خلال زبان الگوها، دنباله‌های الگو توضیح داده می‌شود.

شاید خیلی سودمند به نظر نرسد اما اگر برخی کتاب‌هایی که در این زمینه نوشته شده است را ببینید، یک راهنمای عملی در مورد موضوعاتی که بالقوه می‌توانند خیلی پیچیده باشند، ارائه می‌کنند. به‌عنوان مثال در مورد امور راه دور (Remoting)، با چیزهایی از قبیل نماینده (Proxy) و جاآرایی (Marshaling) آغاز می‌کنند و بعد در مورد اینکه چگونه می‌توان چرخه حیات این اشیاء راه دور را مدیریت کرد، صحبت می‌کنند، در مورد ارتباطات ناهمگام (Asynchronous) صحبت می‌کنند و ... . اینکه یک حوزه را عمیق‌تر متوجه شوید خیلی سودمندتر است تا اینکه فقط یک API مثلاً CORBA را یاد بگیرید. فکر می‌کنم این ما را به موضوع بعدی می‌برد و آن مزایای الگوها است. چرا الگوها مهم هستند؟

فکر می‌کنم، پیش از هرچیز، الگوها به این خاطر ایده‌ خوبی هستند که اجازه می‌دهند بهتر در مورد نرم‌افزار گفتگو کنیم. روشن است که نرم‌افزار را نمی‌توانید لمس کنید. بدون الگوها، صحبت کردن در مورد ساختارهای داخلی و منطق طراحی‌ نرم‌افزار همواره سخت بوده است. به‌وسیله الگوها ابزار و زبان مشترکی برای صحبت کردن در مورد نرم‌افزار، ساختار آن، طراحی‌ آن و همه چیز حول آن را داریم.
مورد دوم، استفاده مجدد (Reuse) است. ما تجربیات و سرمشق‌ها (Best Practice) را به اشتراک می‌گذاریم و تا حدی، حوزه توسعه نرم‌افزار را نمو می‌دهیم. همچنین یک هدف غایی وجود دارد که یک رساله معماری نرم‌افزار (Software Architecture Handbook) تهیه شود. چندین بار در مورد آن تلاش شده است اما هنوز به‌دست نیامده است.

مورد اخیرش، رهیافت گردی بوش است (اشاره به سایت handbookofsoftwarearchitecture.com - مترجم). درسته؟

بله. اما امیدواریم و سرانجام اجتماع ما در آینده موفق خواهد شد. چنین چیزی واقعاً می‌تواند مفید واقع شود تا توسعه نرم‌افزار به یک حوزه مهندسی بالغ تبدیل شود. تا بیشتر ساختار داشته باشد و به جنبه مهندسی در مهندسی نرم‌افزار دست یابیم.

:-) این مهم است؛ ما الان در رادیوی «مهندسیِ» نرم‌افزار هستیم!

مورد دیگر این است که واقعاً به من کمک می‌کند که افکارم را سازمان دهم. کمکم می‌کند که روش فکر کردن و روش کار مهندسی نرم‌افزارم را سازمان دهم. تمرکز قوی بر روی ساختار، در خوب نوشتن مشخصه‌های نیازمندی هم کمکم می‌کند زیرا می‌دانم بعداً که بخواهم سیستمم را طراحی کنم، باید بر نیازمندی‌هایم تکیه کنم تا تصمیمات طراحی خوبی بگیرم.

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

چیز دیگری که فکر می‌کنم مهم است این است که نوشتن الگوها نیز کمک می‌کند که چیزها را بهتر فرا بگیرید. خیلی وقت پیش که اولین بار کتاب GOF را خواندم، کمکم کرد که بفهمم، شیءگرایی فراتر از ارث‌بری و محصور کردن (Encapsulation) است. در گام بعدی، ساختن سیستم‌های شیءگرا بر اساس کتاب GOF را فراگرفتم. بعد که نوشتن الگو را آغاز کردم، خودش گام بعدی بود زیرا سبک نگارشم را بهبود داد. اگر امروزه بخواهم مقاله یا هر نوع مستند دیگری را بنویسم که زمان کافی برای درست نوشتنش را داشته باشم، همواره تا حدودی مانند الگو خواهد شد. تلاش می‌‌کنم که اول ‌زمینه کار را توضیح دهم، بعد مسئله‌ای را طرح می‌کنم که سعی دارم با این سیستمی که مستند می‌کنم، حلش کنم. بعد راه حل را می‌آورم و توضیح می‌دهم که پیامدها چه هستند و با یک مثال که فهمش ساده باشد، انگیزه همه آنها را می‌سازم. بنابراین نوشتن الگو تنها برای گرفتن بلیط پرواز به ایلینویز برای کنفرانس نیست بلکه واقعاً کمک‌تان می‌کند که سبک نگارش‌تان را بهبود دهید. و این چیزی است که خیلی از افراد باید انجام دهند.

منم gosh!

بله! برای اینکه توضیح داده باشم، اصطلاح gosh در دومین کارگاه نویسندگان برای بیان اینکه شما هم دقیقاً همان عقیده را دارید، استفاده می‌شد. در عوض اینکه یک چیز را دوباره و دوباره تکرار کنید این اصطلاح را می‌گفتید تا دقیقاً با چیزی که نفر دیگر گفته بود موافقت کنید.

قبل از پایان دادن به مصاحبه و ذکر مراجع اضافی، فکر می‌کنم واقعاً جالب باشد که به حجم نوشته‌هایی اشاره نماییم که توسط انجمن الگوها ایجاد شده است. فکر می‌کنم حدود ۵۰ کتاب باشد.

بله، من به تازگی در سایت hillside.net جستجو کردم و بین ۵۰ تا ۷۰ کتاب جدی در مورد الگوها بود. (آمارها مربوط به زمان مصاحبه در سال ۲۰۰۶ است - مترجم)

منظورتان از جدی این است که مربوط به کارگاه‌ها بوده است؟

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

بله، خصوصاً در گذشته مشاجره جدی در این زمینه وجود داشت که عنوان الگو را بر روی جلد کتاب‌تان بگذارید. شاید سختگیرانه باشد که بگوییم اگر کسی در کنفرانس‌ها شرکت نکرده است اجازه استفاده از عنوان الگو را ندارد اما امروزه افراد تا حدی انتظار دارند که الگوهایی که در کتاب‌ها می‌آید یا حداقل بخشی از آنها از کارگاه‌های یکی از کنفرانس‌ها آمده باشد. درسته؟

بله، بنابراین در انجمن ما، کنفرانس‌های PLoP، تضمین‌کننده کیفیت است.

همچنین به غیر از فهرست‌های جامعی که از منابع مختلفی مانند صفحات وب می‌توانید بیابید، فهرست بهترین‌ها نیز وجود دارد. انتشارات Addison-Wesley یک مجموعه با نام PLoPD (مخفف Pattern Languages of Program Design) منتشر کرده است. تا بحال ۴ جلد منتشر شده است البته جلد ۵ باید خیلی وقت پیش چاپ می‌‌شد و انتشارات گفته است که چاپش در مراحل نهایی است. این مجموعه PLoPD، یک مجموعه منتخب حتی بهبودیافته‌تر از الگوهای کنفرانس‌های مختلف است و به نوعی، بهترین‌ها است.

نکته دیگری که خوب است اشاره کنم، تقویم الگو (Pattern Almanac) نوشته لیندا رایزینگ است که الگوهای تا سال ۲۰۰۰ را دارد اما هنوز معتبر است و می‌توانید ایندکس آن را استفاده نمایید تا الگوهای مرتبط با مشکلی که با آن مواجه شده‌اید، را بیابید.

آیا یک کاتالوگ (کاملِ) الگوها در وب وجود دارد؟ فکر می‌کنم وجود نداشته باشد.

خیر، هنوز وجود ندارد. همانند رساله معماری نرم‌افزار، (برای این موضوع هم) خیلی‌ها تلاش کرده‌اند اما هنوز وجود ندارد. من می‌دانم قطعاً برایش برنامه‌ریزی شده است و هرگاه فراهم شود مطمئنم که می‌توانید لینک آن را در hillside.net بیابید.

بسیار خوب، فکر می‌کنم بحث ما در مورد الگوها به پایان می‌رسد.