27 يونيو 2025·8 دقيقة
أفكار آلان كاي الكبرى: Smalltalk والواجهات الرسومية وأنظمة البرمجيات
استكشف الأفكار الأساسية لآلان كاي حول Smalltalk والواجهات الرسومية المبكرة — وكيف شكّلت نظرتنا اليوم للبرمجيات كنظم متفاعلة من كائنات.
استكشف الأفكار الأساسية لآلان كاي حول Smalltalk والواجهات الرسومية المبكرة — وكيف شكّلت نظرتنا اليوم للبرمجيات كنظم متفاعلة من كائنات.
آلان كاي ليس مجرد اسم من تاريخ البرمجة. كثير من الفرضيات اليومية التي نحملها عن الحواسيب — ما هي "النافذة"، ولماذا يجب أن تكون البرامج تفاعلية، وكيف يمكن بناء البرامج من أجزاء متعاونة — تشكّلت من أفكار دفعها قُدمًا (غالبًا مع فرق في Xerox PARC).
هذه التدوينة عن مفاهيم، لا عن توافه. لا تحتاج أن تعرف البرمجة لتتبعها، ولن تجد جولة في تفاصيل تقنية غامضة. بدلًا من ذلك، سنركز على نماذج ذهنية لا تزال تظهر في الأدوات والمنتجات التي نستخدمها: كيف يمكن فهم البرنامج، تغييره، وتعلّمه.
أولًا، Smalltalk: ليست مجرد لغة برمجة، بل بيئة عمل كاملة تشجّع الاستكشاف والتعلّم.
ثانيًا، الواجهات الرسومية (GUI): نوافذ، أيقونات، قوائم — البرمجيات التفاعلية كأشياء يمكنك التلاعب بها مباشرة، لا مجرد إعطاء تعليمات.
ثالثًا، تفكير النظم: رؤية البرمجيات كمجموعة أجزاء تتفاعل مع حلقات تغذية راجعة، بدلًا من كومة ملفات كود.
لن تعامل كاي كعبقري منفرد، ولن تدّعي أن هناك "نمطًا صحيحًا" يصلح لكل شيء. بعض الأفكار نجحت ببراعة، وبعضها سُوء فهم، وبعضها لم ينتشر كما يمكن أن يكون.
الهدف عملي: بنهاية القراءة، ينبغي أن تنظر إلى التطبيقات وقواعد الكود الحديثة بفهم أوضح لـ لماذا تبدو كما تبدو — وما يمكنك استعارةَه لمشروعك التالي.
دخل آلان كاي إلى ثقافة حوسبة قوية وغالية وموجّهة في الغالب لخبراء. كانت الحواسيب تعامل كبنية تحتية مشتركة: تحجز وقتًا، تُقدّم عملًا، وتنتظر النتيجة. ذلك النموذج شكّل كل شيء — شكل البرامج، من يمكنه استخدامها، وما الذي يعتبره الناس "نجاحًا".
لبعض المستخدمين، الحوسبة تعني تسليم مهمة للآلة (غالبًا عبر بطاقات أو طوابير محطات طرفية) وانتظار إخراج لاحقًا. إذا حدث خطأ، لم تكن تتجوّل وتتعلّم — كنت تعيد الإرسال وتنتظر مرة أخرى. كان الاستكشاف بطيئًا، وبدا الحاسوب أكثر كخدمة بعيدة من أداة تفكر بها.
لم يكن هدف كاي "أجهزة أصغر" فقط. كان هدفه علاقة مختلفة: الحاسوب كوسيط شخصي للتعلّم، الكتابة، المحاكاة، الرسم، وبناء الأفكار — خصوصًا للأطفال وغير المتخصصين. ذلك احتاج لحاضرية: أن ترى ما تفعله أفعالك، تعدّل بسرعة، وتحافظ على تدفّق إبداعي.
لمتابعة هذا النوع من التغيير، تحتاج مساحة لتجربة الأجهزة، البرمجيات، وتصميم التفاعل معًا. معامل البحث مثل Xerox PARC مولت رهانات طويلة: شاشات جديدة، أجهزة إدخال جديدة، نماذج برمجة جديدة، وطرق جديدة لربطها في تجربة متناسقة. الهدف لم يكن إطلاق ميزة — بل ابتكار نوع جديد من استخدام الحاسوب.
إذا كان الحاسوب سيصبح آلة للتعلّم والإبداع، لم يكن يمكن اعتبار قابلية الاستخدام فكرة ثانوية. يجب أن تدعم الواجهة الاكتشاف، التغذية الراجعة، والأفعال المفهومة. هذا التوجه دفع كاي نحو نظم حيث "إحساس" التفاعل — ما يحدث عند النقر أو التحرير أو الاستكشاف — مرتبط ارتباطًا وثيقًا بكيفية هيكلة البرمجية نفسها.
لم يبدأ آلان كاي بسؤال "كيف نجعل العمل المكتبي أسرع؟" بل بطرح سؤال مختلف: ماذا لو كان الطفل يحمل حاسوبًا شخصيًا ككتاب، ويستخدمه لاستكشاف الأفكار، صناعة الأشياء، والتعلّم بالممارسة؟ تحوّلت تلك الفكرة إلى Dynabook — ليست مواصفة منتج بقدر ما هي نجم مرشد للحوسبة الشخصية.
تخيل Dynabook خفيف الوزن، يعمل بالبطارية، ومتاح دائمًا. لكن الكلمة الأهم لم تكن "محمول"، بل "شخصي". هذا الحاسوب سيكون ملكًا لمستخدمه كما دفتر ملاحظات أو آلة موسيقية — شيء تشكّله عبر الزمن، لا شيء تشغله فقط.
الأهم أيضًا: يجب أن يكون قابلًا للتعلّم. هدف كاي لم يكن إخفاء الحوسبة خلف جدار قوائم؛ بل جعل الناس يتحولون تدريجيًا إلى مؤلفين، لا مستهلكين فقط.
تطبيقات القتل في Dynabook كانت القراءة، الكتابة، الرسم، تلحين الموسيقى، محاكاة تجارب علمية، وبناء قصص تفاعلية. اعتبر البرمجة كمهارة قراءة وكتابة — طريقة للتعبير عن الأفكار — لا مهنة متخصصة للمحترفين فقط.
هذا التركيز يغيّر تعريف "البرنامج الجيد". أداة التعليم يجب أن تدعو إلى العبث، تعطي تغذية راجعة سريعة، وتجعل المحاولة مرة أخرى آمنة.
هنا يدخل Smalltalk والواجهات الرسومية المبكرة. إذا أردت للناس أن يبدعوا، تحتاج للتلاعب المباشر، نتائج فورية، وبيئة تجعل التجربة التجريبية طبيعية. نظام Smalltalk الحي والاستعارات البصرية للـ GUI دعمت نفس الهدف: تقصير المسافة بين الفكرة والنتيجة العملية.
Dynabook لم يكن "التنبؤ بالجهاز اللوحي". كان اقتراحًا لعلاقة جديدة مع الحوسبة: وسيط للفكر والإنشاء. يمكن لأجهزة متعددة أن تقارب ذلك، لكن الرؤية تدور حول تمكين المستخدمين — خصوصًا المتعلمين — لا عن حجم شاشة أو تصميم عتاد بعينه.
عندما يسمع الناس "Smalltalk"، غالبًا يتصوّرون لغة برمجة فقط. تعامل فريق كاي معها كشيء أوسع: نظام عمل كامل حيث صُمِّمت اللغة، الأدوات، وتجربة المستخدم كوحدة متكاملة.
بعبارات بسيطة، Smalltalk نظام حيث كل شيء كائن. النوافذ على الشاشة، النص الذي تكتبه، الأزرار التي تنقرها، الأرقام التي تحسبها — كلٌ كائن يمكنك أن تطلب منه فعل شيء.
صُمّم Smalltalk للتعلّم بالممارسة. بدل كتابة كود، وتجميعه، والأمل أنه يعمل، يمكنك فحص الكائنات بينما يعمل النظام، رؤية حالتها الحالية، تغييرها، وتجربة فكرة جديدة فورًا.
تلك الحيوية مهمة لأنها تحوّل البرمجة إلى استكشاف. لست تنتج ملفات فقط؛ أنت تشكّل عالمًا جارٍ. تشجّع الفضول: "ما هذا الشيء؟" "ما الذي يحتويه؟" "ماذا يحدث لو عدّلت هذا؟"
أدوات تطوير Smalltalk لم تكن إضافات منفصلة. المتصفحات، المفحّصات، المصحّحات، والمحرّرات كانت جزءًا من نفس الكون القائم على الكائنات. الأدوات فهمت النظام من الداخل لأنها بُنيت في نفس الوسط.
هذا الاندماج غيّر شعور "العمل على برمجيات": أقل كإدارة شفرة بعيدة، وأكثر كالتفاعل المباشر مع النظام الذي تبنيه.
تخيل تحرير مستند وهو مفتوح ورَسْم التغييرات فوري — التعديلات تظهر مباشرة، يمكنك البحث، إعادة الترتيب، والتراجع دون الحاجة لإعادة "بناء". هدف Smalltalk كان ذلك النوع من الفورية، ولكن للبرامج: تعدّل الشيء الجاري، ترى النتائج فورًا، وتستمر في الحركة.
الفكرة الأكثر نفعًا عند كاي ليست "الفئات والوراثة". هي أن الكائن هو حاسوب صغير معزول: يحتفظ بحالته، ويقرر كيف يستجيب عندما تطلب منه فعل شيء.
فكر في كل كائن على أنه يمتلك:
هذا الإطار عملي لأنه يحوّل التركيز من "أين تخزن البيانات؟" إلى "من المسؤول عن التعامل مع هذا؟"
التشويش الشائع هو معامل الكائنات كسجلات بيانات جميلة: حزمة من الحقول مع بعض الدوال المساعدة. في هذا الرأي، أجزاء أخرى من البرنامج تتطفّل بحرية على الباطن.
رؤية كاي أقرب إلى الفاعلون. لا تدخل في كائن وتعيد ترتيب أدراجه. ترسِل إليه طلبًا وتتركه يدير حالته بنفسه. هذه الفاصلة هي الفكرة الجوهرية.
تمرير الرسائل ببساطة هو طلب/استجابة.
تخيل مقهى: لا تدخل المطبخ وتطبخ لنفسك. تضع طلبًا ("اصنع لي ساندويتش"), وتحصل على نتيجة ("هنا ساندويتشك" أو "نفدت الخبز"). المقهى يقرّر كيفية تلبية الطلب.
الكائنات في البرمجيات تعمل بنفس الكيفية: ترسل رسالة ("احسب الإجمالي"، "احفظ"، "ارسم نفسك"), والكائن يستجيب.
عندما تعتمد أجزاء النظام الأخرى فقط على الرسائل، يمكنك تغيير كيفية عمل كائن داخليًا — تبديل الخوارزميات، تغيير التخزين، إضافة تخزين مؤقّت — دون إجبار إعادة كتابة كل شيء حوله.
هكذا تنمو الأنظمة دون كسر كل شيء: اتفاقات مستقرة على الحدود، وحُرّية داخل المكونات.
غالبًا ما يُعامل "البرمجة الشيئية" كمرادف لاستخدام الفئات. هذا مفهوم منطقي — تعلم معظم اللغات البرمجة الشيئية عبر مخططات فئات وشجرات وراثة. لكن تركيز كاي الأصلي كان مختلفًا: فكر في قطع متواصلة تتواصل.
الفئة (Class) هي مخطط: تصف ما يعرفه شيء وما يمكنه فعله.
المثال (Instance) أو الكائن هو شيء مُصنَّع من المخطط — مثال واحد محدد.
الطريقة (Method) هي عملية يمكن للكائن أداؤها عند الطلب.
الحالة (State) هي بيانات الكائن الحالية: ما يتذكّره الآن، والتي يمكن أن تتغير عبر الزمن.
Smalltalk شاعت نموذج كائن موحّد: كل شيء كائن، وتتفاعل مع الكائنات بطريقة متسقة. كما اعتمد بقوة على تمرير الرسائل — لا تصل إلى باطن كائن آخر؛ ترسِل رسالة وتدع الكائن يقرّر التصرف.
هذا الأسلوب يتماشى بطبيعة الحال مع الربط المتأخر (dynamic dispatch): يقرّر البرنامج وقت التشغيل أي طريقة تتعامل مع الرسالة، اعتمادًا على الكائن المستلم. الفائدة العملية هي المرونة: يمكنك تبديل السلوكيات دون إعادة كتابة المستدعي.
قاعدة إبهام مفيدة: صمّم حول التفاعلات. اسأل "ما الرسائل التي يجب أن توجد؟" و"من يملك هذه الحالة؟" إذا تعاونت الكائنات بسلاسة، ستصبح بنية الفئات أبسط — وأكثر قابلية للتغيير — كنتيجة جانبية.
غيرت الواجهة الرسومية شعور "استخدام البرمجيات". بدل حفظ الأوامر، يمكنك الإشارة إلى الأشياء، تحريكها، فتحها، ورؤية النتائج فورًا. النوافذ، القوائم، الأيقونات، والأزرار جعلت الحوسبة أقرب إلى التعامل مع أشياء مادية — تلاعب مباشر بدل تعليمات مجردة.
تلك "المادية" تتطابق طبيعيًا مع نموذج الكائنات. في واجهة جيدة التصميم، كل ما تراه وتتفاعل معه يمكن اعتباره كائنًا:
هذا ليس مجرد راحة برمجية؛ إنه جسر مفاهيمي. يفكر المستخدم بكائنات ("حرّك هذه النافذة"), والبرمجية مبنية من كائنات يمكنها بالفعل أداء تلك الأفعال.
عندما تنقر، تكتب، أو تسحب، يولّد النظام حدثًا. في رؤية كائنية، الحدث يشبه رسالة مرسلة إلى كائن:
يمكن للكائنات سپس إعادة توجيه الرسائل لكائنات أخرى ("قل للمستند أن يحفظ"، "قل للنافذة أن تعيد الرسم"), مكونة سلسلة من التفاعلات المفهومة.
لأن واجهة المستخدم مصنوعة من كائنات دائمة ذات حالة مرئية، تشبه دخول مساحة عمل بدل تشغيل أمر لمرة واحدة. يمكن ترك النوافذ مفتوحة، ترتيب الأدوات، العودة إلى مستند، ومتابعة العمل من حيث توقفت. تصبح الواجهة بيئة متماسكة — حيث الأفعال هي محادثات بين كائنات تراها.
إحدى أفكار Smalltalk المميزة لم تكن ميزة نحوية — كانت الصورة (image). بدل التفكير بالبرنامج كـ "شفرة مصدر تُجمّع إلى تطبيق"، عامل Smalltalk النظام كعالم جارٍ من الكائنات. عندما تحفظ، يمكنك حفظ البيئة الحية كاملة: الكائنات في الذاكرة، الأدوات المفتوحة، حالة الواجهة، والعمل الجاري.
نظام مبني على الصورة يشبه إيقاف فيلم وحفظ ليس السيناريو فقط، بل الإطار والمشهد ومواقع الممثلين. عندما تستأنف، تعود حيث توقفت — أدواتك ما تزال مفتوحة، كائناتك ما تزال موجودة، وتغييراتك مستمرة بالفعل.
دعم هذا حلقات تغذية راجعة متقاربة. يمكنك تغيير سلوك، تجربته فورًا، ملاحظة النتائج، وتحسين — دون إعادة الضبط الذهني لـ "بناء، إعادة تشغيل، إعادة تحميل بيانات، التوجه مرة أخرى للشاشة".
نفس المبدأ يظهر في تدفقات عمل "vibe-coding" الحديثة أيضًا: عندما يمكنك وصف تغيير بلغة بسيطة، رؤيته مطبّقًا فورًا، والتكرار، تتعلم النظام أسرع وتحافظ على الزخم. منصات مثل Koder.ai تدخل في هذا بتحويل بناء التطبيقات إلى حلقة محادثة — خطط، عدّل، معاينة — مع إنتاج شفرة حقيقية يمكنك تصديرها وصيانتها.
تجد أصداء لفكرة الصورة في ميزات محبوبة اليوم:
ليست متطابقة مع صور Smalltalk، لكنها تشترك في الهدف: تقليل المسافة بين الفكرة ونتيجتها قدر الإمكان.
حفظ عالم جارٍ كامل يطرح أسئلة صعبة. قد تتدهور قابلية التكرار إذا كانت "الحقيقة" تعيش في حالة قابلة للتغيير بدل عملية بناء نظيفة. النشر يصبح أصعب: شحن صورة قد يطمس الحدود بين التطبيق والبيانات والبيئة. التصحيح قد يصبح أكثر تعقيدًا عندما تعتمد الأخطاء على تسلسل تفاعلات معين وحالة متراكمة.
رهان Smalltalk كان أن تسريع التعلّم والتكرار يستحق تلك التعقيدات — وما زال ذلك الرهان يؤثر في كيفية تفكير كثير من الفرق بتجربة المطوّر.
عندما تحدث آلان كاي عن البرمجيات، غالبًا ما تعامل معها أقل كحزمة كود وأكثر كـ نظام: أجزاء كثيرة تتفاعل مع مرور الزمن لإنتاج السلوك الذي نهتم به.
النظام لا يُعرّف بمكون واحد. يُعرّف بالعلاقات — من يتحدث مع من، ماذا يُسمح بطلبه، وماذا يحدث عندما تتكرر تلك المحادثات.
بعض المكونات البسيطة يمكنها خلق سلوك معقّد بمجرد إضافة التكرار والتغذية الراجعة. مؤقت يقرع، نموذج يحدث الحالة، وواجهة تعيد الرسم كلٌ منها بسيط. اجمعها معًا فتحصل على حركات، تراجع/إعادة، حفظ تلقائي، تنبيهات، ولحظات "لماذا تغير هذا الآن؟".
لذلك التفكير بالنظم عملي: يدفعك للبحث عن الحلقات ("عندما يتغير A، يتفاعل B، مما يفعّل C…") والزمن ("ماذا يحدث بعد 10 دقائق من الاستخدام؟"), لا مجرد استدعاءات دوال منفردة.
في نظام، الواجهات أهم من التنفيذ. إذا كان جزء يتفاعل مع آخر عبر رسائل واضحة فقط ("زد العداد"، "ارسم"، "سجل حدث"), يمكنك تبديل الباطن دون إعادة كتابة كل شيء.
هذا قريب من تأكيد كاي على تمرير الرسائل: لا تسيطر على أجزاء أخرى مباشرة؛ تسأل، وهي ترد.
تخيل ثلاثة كائنات:
تدفق عبر الزمن:
clicked.increment إلى CounterModel.changed(newValue).changed وتعيد الرسم.record("increment", newValue).لا يحتاج أي مكوّن للتطفّل داخل الآخر. السلوك يَبْنَى من المحادثة.
آلان كاي دفع فكرة بسيطة تبدو أحيانًا راديكالية: يجب أن تكون البرمجيات سهلة التعلم، لا فقط قوية. التصميم "الذكي" غالبًا يحسّن رضا المنفّذ — اختصارات، حيل مخفية، تجريدات كثيفة — بينما يترك المستخدمين العاديين يحفظون طقوسًا.
كان كاي يهتم بالبساطة لأنها قابلة للتوسع: مفهوم يتمكن المبتدئ من فهمه بسرعة يمكن للفرق تعليمه ومشاركته والبناء عليه.
كثير من البرمجيات تعامل المستخدمين كمشغّلين: اضغط الأزرار الصحيحة لتحصل على الناتج. هدف كاي أقرب إلى أداة تفكير — شيء يدعو إلى الاستكشاف، يدعم المحاولة والخطأ، ويتيح للناس بناء نماذج ذهنية.
لهذا قدّر الأنظمة التفاعلية حيث ترى ما يحدث وتعدّل أثناء العمل. عندما يستجيب النظام فورًا وبمعنى، يصبح التعلم جزءًا من الاستخدام.
كاي كثيرًا ما استخدم التعلّم — وتخيّل الأطفال كمستخدمين — كقوة إجبار للوضوح. إذا كان المفهوم يمكن التلاعب به، فحصه، وشرحه دون مواربة، فهو أكثر احتمالًا أن يعمل للجميع.
هذا لا يعني "التصميم للأطفال فقط". يعني استخدام قابلية التعليم كاختبار جودة: هل يكشف النظام عن منطقَه؟
قابلية التعلم هي ميزة منتجية. يمكنك التصميم لها عبر:
العائد ليس فقط مستخدمين مبتسمين. بل تسجيل أسرع، تذاكر دعم أقل، ومنتج يشعر الناس بالقدرة على تمديده — بالضبط نوع "وكالة المستخدم" التي رغب كاي في تضخيمها.
عمل كاي لم "يخترع كل شيء" لكنّه أثّر بقوة في كيفية تفكير الناس حول بناء البرمجيات — خصوصًا الموجّهة للبشر.
العديد من الممارسات الحديثة تُعيد أفكارًا جعلها Smalltalk وبيئة Xerox PARC ملموسة وشائعة:
بعض جوانب الرؤية الأصلية لم تنتقل بسلاسة:
إذا تدقّق، الكثير من الأنماط الحالية تتناغم مع تمرير الرسائل: واجهات مكوّنة (React/Vue)، تطبيقات مدفوعة بالأحداث، وحتى مايكروسيرفيسز التي تتواصل عبر HTTP أو قوائم انتظار. ليست هي نفسها — لكنها تظهر كيف تستمر فكرة كاي الجوهرية (الأنظمة كأجزاء متفاعلة) في إعادة التفسير تحت قيود حديثة.
إذا أردت جسرًا عمليًا من التاريخ إلى الممارسة، القسم الأخير (انظر /blog/practical-takeaways) يحوّل هذه التأثيرات إلى عادات تصميمية يمكنك استخدامها فورًا.
عمل كاي قد يبدو فلسفيًا، لكنّه يترجم إلى عادات عملية جدًا. لست بحاجة لاستخدام Smalltalk — أو حتى "البرمجة الشيئية" — للاستفادة. الهدف بناء برمجيات تبقى مفهومة مع نموها.
عند البدء (أو إعادة الهيكلة)، جرّب وصف النظام كمجموعة أدوار تعمل معًا:
هذا يبقي تركيزك على المسؤوليات، لا على "الفئات لأننا بحاجة لفئات".
قبل الجدل حول جداول قاعدة البيانات أو شجرات الفئات، عرّف الرسائل — ما الذي يطلبه جزء من جزء آخر.
تمرين مفيد: اكتب "محادثة" قصيرة لإجراء مستخدم واحد:
بعدها قرر كيف تُنفَّذ الأدوار (فئات، وحدات، خدمات). هذا أقرب لتركيز كاي على تمرير الرسائل: السلوك أولًا، البنية ثانيًا.
كان كاي يهتم بالأنظمة الحية حيث ترى آثار التغييرات سريعًا. في فريق عصري، يعني ذلك عادة:
إن لم تستطع أن تعرف ما الذي تغيّر — أو إن أحدث التغيير أثرًا إيجابيًا — فأنت تُبحر بلا معلم.
إذا تبنيت سير عمل يقوده الشات (مثلاً في Koder.ai)، ينطبق نفس النصيحة: عامل المخرجات المولّدة كوسيلة للتكرار السريع، لكن اجعل الحدود صريحة، واستخدم لقطات/استرجاع ورصد وسحب شفرة المصدر حتى يبقى النظام مفهومًا مع الزمن.
إن لامستك هذه التدوينة، استكشف:
هذه المواضيع أقل عن الحنين وأكثر عن تطوير ذائقة: بناء برمجيات قابلة للتعلّم، التكيّف، والتماسك كنظام.
آلان كاي دعا إلى علاقة مختلفة مع الحواسيب: ليست مهام مجدولة على دفعات، بل وسيط شخصي تفاعلي للتعلّم والإبداع.
هذا التفكير شكل توقعات نعتبرها اليوم بديهية — ردود فعل فورية، واجهات يمكن التلاعب بها، وبرمجيات يمكن استكشافها وتعديلها أثناء العمل.
الـ Dynabook كان رؤية لجهاز حاسوب محمول وشخصي مصمم بالأساس لـ التعلّم والإبداع (القراءة، الكتابة، الرسم، المحاكاة).
الأهم أنه لم يكن مجرد "تنبؤ بوجود أجهزة لوحية"، بل تحديد لما يجب أن تبدو عليه الحوسبة التمكينية: المستخدمون مؤلفون للأفكار، لا مجرد مشغّلين للأدوات.
في Smalltalk، اللغة والأدوات وواجهة المستخدم تكون منظومة متماسكة.
بالمقابل العملي، يمكنك فحص الكائنات أثناء التشغيل، تغيير السلوك، تصحيح التداخل تفاعليًا، والاستمرار في العمل دون إعادة بناء وإعادة تشغيل متكررة — مما يقصر المسافة بين الفكرة والنتيجة.
الفكرة الأساسية لـ كاي لم تكن "الفئات والوراثة" بحد ذاتها. كانت الكائنات كوكلاء مستقلين يتواصلون بإرسال رسائل.
من ناحية التصميم، هذا يوجهك لتعريف حدود واضحة: المستدعون يعتمدون على الرسائل التي يقبلها الكائن، لا على شكل بياناته الداخلي.
فخ شائع هو اعتبار البرمجة الشيئية مجرد شجرة فئات: فئات كثيرة، وراثة عميقة، وبيانات مشتركة قابلة للتغيير.
قواعد عملية مستمدة من رؤية كاي:
الواجهات الرسومية تجعل البرمجيات تبدو كما لو أنك تتعامل مع أشياء (نوافذ، أزرار، أيقونات). هذا ينسجم طبيعيًا مع نموذج الكائنات حيث لكل عنصر واجهة حالة وسلوك.
أفعال المستخدم (نقرات، سحب، ضغط مفاتيح) تصبح أحداثًا هي في الجوهر رسائل تُرسَل إلى الكائنات، والتي قد تعيد توجيه الطلبات عبر النظام.
صورة Smalltalk تحفظ العالم الحيّ بكل كائناته: الكائنات في الذاكرة، الأدوات المفتوحة، حالة الواجهة، والعمل الجاري.
فوائد:
مقايضات:
التفكير بالنظم يبدل التركيز إلى السلوك عبر الزمن: حلقات التغذية الراجعة، التفاعلات المتسلسلة، ومن يتحدث مع من.
عمليًا، يقود ذلك لتصميم بواجهات واضحة (رسائل) واعتماد أقل على التفاصيل الداخلية، لأن التطبيق يُنظر إليه كمجموعة أجزاء تتفاعل معًا لا كمجموعة إجراءات معزولة.
استخدم تصميمًا يعطي الأولوية للرسائل لمسار واحد من العمل:
getTotal, isAvailable, authorize).بعدها اختر كيفية التنفيذ (فئات، وحدات، خدمات). راجع قسم التحقق العملي في /blog/practical-takeaways للبدء.
أدوات العصر الحديث كثيرًا ما تُعيد صدى أهداف كاي رغم اختلاف التنفيذ:
ليست مثل صور Smalltalk، لكنها تسعى إلى نفس النتيجة العملية: جعل التغيير والتعلّم أرخص وأسرع.