عرض مصدر Design Patterns/what is pattern

<noinclude>{{DISPLAYTITLE:ما هي أنماط التصميم}}</noinclude>
تشبه الأنماط في تصميم البرمجيات وصفات الطهي، فهي ليست أطباقًا جاهزة، لكنها إرشادات لتقطيع وتجهيز المنتجات وطهيها ومن ثم تقديمها.

== محتوى النمط ==
يتكون وصف النمط عادة من التالي:
* مشكلة يحلها النمط.
* دافع لحل المشكلة باستخدام الأسلوب الذي يرشحه النمط.
* هيكلة الفئات التي تكوّن الحل.
* مثال بلغة برمجية.
* وصف فروق تنفيذ النمط في سياقات مختلفة.
* العلاقات مع الأنماط الأخرى.

== من يخترع الأنماط؟ ==
الأنماط تُكتشف ولا تخترع، فهي نماذج لحل مشاكل متكررة وليست أفكارًا مبتكرة أو فريدة. وأول من قدم وصفًا للأنماط كان كريستوفر أليكساندر (Christopher Alexander) في كتابه "لغة النمط: المدن والمباني والإنشاء" (A Pattern Language: Towns, Buildings, Construction)، ويتحدث في الكتاب عن "لغة" لتصميم بيئة المدن، وتجيب فصول الكتاب عن أسئلة معمارية تصف ما يجب أن تكون عليه تلك المدن، مثل ارتفاع النوافذ وعدد الطوابق لكل مبنى، وحجم المساحات الخضراء في كل حي وهكذا.

وقد ألهمت فكرة الكتاب أربعة مؤلفين -عُرفوا بعصابة الأربعة- هم إريك جاما (Erich Gamma) وجون فليسيدز (John Vlissides) ورالف جونسون (Ralph Johnson) وريتشارد هيلم (Richard Helm) لينشروا كتابًا في 1995 اسمه "أنماط التصميم: عناصر البرمجيات كائنية التوجه القابلة لإعادة الاستخدام" (Design Patterns: Elements of Reusable Object-Oriented Software)، طبقوا فيه مبدأ الأنماط التقليدية على البرمجة، وقد احتوى الكتاب على ثلاثة وعشرين نمطًا تحل أغلب مشاكل التصميم كائني التوجه. وقد اكتُشفت عشرات الأنماط منذ ذلك الوقت وصار مبدأ الأنماط مشهورًا في أنواعٍ أخرى من البرمجة، ما يعني إمكانية اكتشاف أنماط جديدة خارج نطاق التصميم كائني التوجه.

== تصنيف الأنماط ==
تختلف الأنماط عن بعضها في مدى تعقيدها ومستوى التفاصيل التي فيها ومجال تطبيقها على النظام الذي تصممه، فبالعودة للتشبيه مع وصفات الطهي، قد يكون لديك وصفة بسيطة لحساء أو قائمة ضخمة لعشاء في احتفالية. وبإسقاط ذلك المثال على الأنماط فإن أبسط صورة للأنماط هي المصطلحات (idioms) وهي ليست عامة بما أنه لا يمكن تطبيقها إلا في لغة برمجة وحيدة، وأكثر صورة عامة هي الأنماط المعمارية (architectural patterns) التي يمكن استخدامها في أي لغة تقريبًا، وهي ضرورية لتصميم البرنامج ككل وليس بعض المكونات فيه.

== أهمية تعلم أنماط التصميم ==
لعل أهم سبب لتعلم أنماط التصميم هو أن الأنماط تبسّط تصميم ودعم البرامج، لكن توجد بعض الفوائد الأخرى من تعلم أنماط التصميم، أهمها ما يلي:

=== الحلول المجربة والمختبرة ===
ستقضي وقتًا أقل من خلال تطبيق الحلول الجاهزة بدلًا من إعادة اختراع العجلة.

=== توحيد الشيفرة البرمجية ===
سيكون لديك مشاكل أقل (Bugs) بما أنك تستخدم حلولًا موحدة نموذجية قد اكتشفت مشاكلها المخفية وتم حلها.

=== معجم عالمي للمبرمجين ===
لن تحتاج إلا إلى ذكر اسم نمط التصميم الذي استخدمته حين تريد إيصال فكرة التصميم لغيرك من المبرمجين، بدلًا من قضاء ساعة في شرح التصميم الجديد الذي ابتكرته وسرد الفئات (classes) المطلوبة.

== النقد ==
خرجت انتقادات كثيرة لأنماط التصميم منذ ظهورها أول مرة حتى قيل أنه ما ترك نقدها إلا الكسول، إليك أهم الانتقادات التي وُجِّهت إلى أنماط التصميم:

=== حلول سريعة للغات البرمجة الضعيفة ===
لا تظهر الحاجة إلى الأنماط إلا حين يختار الناس لغة أو تقنية تفتقر إلى مستوى التعبير المطلوب، وتصبح الأنماط في تلك الحالة هي الحل السريع الذي يعطي اللغة القدرات الخارقة التي تحتاجها. فمثلًا يمكن تطبيق نمط الاستراتيجية (strategy pattern) من خلال دالة (lamda) بسيطة في لغات البرمجة الحديثة. وقد كان أول من تحدث عن وجهة النظر تلك هو بول جراهام (Paul Graham) في مقاله ([http://www.paulgraham.com/icad.html Revenge Of The Nerds]) .

=== حلول تفتقر للكفاءة ===
تحاول الأنماط أن تنظم الطرق المستخدمة بالفعل، وذلك التوحيد يراه العديد على أنه مذهب يطبقونه حرفيًا دون النظر إلى سياق المشروع الذي يعملون عليه.

=== استخدام غير مبرر ===
<blockquote>إن لم يكن لديك إلا مطرقة، فإن كل شيء يبدو كمسمار.</blockquote>يواجه المبتدئون مشكلة بمجرد أن يتعلموا أنماط التصميم، ذلك أنهم يحاولون استخدامها حتى في المواقف التي يؤدي فيها الغرض مجرد شيفرة بسيطة.
[[تصنيف:Design Patterns]]