স্মলটক ও প্রথমের GUI-গুলোর পেছনে অ্যালান কেয়ের মূল ধারণাগুলো এবং কীভাবে সেগুলো আজকের সফটওয়্যারকে অবজেক্টগুলোর আন্তঃক্রিয়াশীল সিস্টেম হিসেবে দেখা হয় তা অন্বেষণ করুন।
অ্যালান কেয় শুধুমাত্র প্রোগ্রামিং ইতিহাসের একটি নাম নয়। কম্পিউটার সম্পর্কে আমরা প্রতিদিন যে অনেক অনুমান করি—কি একটি “উইন্ডো”, কেন সফটওয়্যারই ইন্টারঅ্যাকটিভ হওয়া উচিত, কীভাবে প্রোগ্রাম সমবায় অংশগুলো থেকে গঠিত হতে পারে—এসবের বেশিরভাগ কেয় এবং তার টিম (প্রধানত Xerox PARC-এ) এগিয়ে দেওয়া ধারণাগুলোর দ্বারা আকৃত।
এই পোস্টটি ট্রিভিয়াল নয়; এটা ধারণাগুলো সম্পর্কে। আপনার কোডিং জানা লাগবে না যাতে বোঝা যায়, এবং এখানে বিরল টেকনিক্যাল বিশদ দেখানো হবে না। পরিবর্তে আমরা কয়েকটি মেন্টাল মডেলের উপর ফোকাস করব যা আজকের টুল এবং প্রোডাক্টগুলোতেও দেখা যায়: সফটওয়্যার কিভাবে বোঝা যায়, পরিবর্তিত করা যায় এবং শেখা যায়।
প্রথমত, Smalltalk: কেবল একটি প্রোগ্রামিং ভাষা নয়, বরং একটি পূর্ণমানের ওয়ার্কিং এনভায়রনমেন্ট যা অন্বেষণ ও শেখার উৎসাহ দেয়।
দ্বিতীয়ত, GUI (গ্রাফিক্যাল ইউজার ইন্টারফেস): উইন্ডো, আইকন, মেনু—ইন্টারঅ্যাকটিভ সফটওয়্যার এমন কিছু যা আপনি সরাসরি ম্যানিপুলেট করতে পারেন, কেবল নির্দেশ দেওয়ার চাইতে বেশি।
তৃতীয়ত, সিস্টেম চিন্তা: সফটওয়্যারকে কোড ফাইলের গাদা হিসেবে না দেখে আন্তঃক্রিয়াশীল অংশগুলোর একটি সেট হিসেবে দেখা।
এটি কেয়কে একক প্রতিভা হিসেবে উপস্থাপন করবে না, এবং বলবে না যে কোনো এক "সঠিক" প্যারাডাইমই সবকিছু ঠিক করে। কিছু ধারণা অসাধারণভাবে কাজ করেছে, কিছু ভুলভাবে বোঝা হয়েছে, এবং কিছু যতটা বিস্তার হওয়া উচিত ছিল ততটা ছড়ায়নি।
লক্ষ্যটা বাস্তবসম্মত: শেষে আপনি আধুনিক অ্যাপ এবং কোডবেসগুলোকে একটু পরিষ্কারভাবে দেখতে সক্ষম হবেন—কেন সেগুলো এমন অনুভূত হয়—এবং আপনার পরবর্তী প্রজেক্টে কী নিতে পারেন।
অ্যালান কেয় এমন এক কম্পিউটিং সংস্কৃতির মধ্যে ঢুকেছিলেন যা শক্তিশালী, ব্যয়বহুল এবং সাধারণ মানুষেদের প্রতি অধিকাংশ সময় উদাসীন ছিল। কম্পিউটারগুলোকে একটি শেয়ার করা অবকাঠামো মনে করা হত: সময় বুক করা, কাজ সাবমিট করা, এবং ফলাফলের জন্য অপেক্ষা করা। সেই মডেল সবকিছুকে প্রভাবিত করত—প্রোগ্রামের রূপ, কে ব্যবহার করতে পারে, এবং “সাফল্য” কী বোঝায়।
বহু ব্যবহারকারীর জন্য কম্পিউটিং মানে ছিল মেশিনে একটি কাজ হস্তান্তর করা (প্রায়ই পাঞ্চ কার্ড বা কিউযুক্ত টার্মিনাল মাধ্যমে) এবং পরে আউটপুট পাওয়া। কিছু ভুল হলে আপনি ঘেঁচড়ে দেখেন না—আপনি পুনরায় সাবমিট করতেন এবং আবার অপেক্ষা করতেন। অন্বেষণ ধীর ছিল, এবং কম্পিউটারটি একটি দূরের সার্ভিসের মতো অনুভূত হত, এমন একটি টুল নয় যেটা নিয়ে আপনি চিন্তা করতে পারেন।
কেয়ের লক্ষ্য কেবল “ছোট কম্পিউটার” বানানো ছিল না। এটি সম্পর্কটাই আলাদা করে দিতে চেয়েছিল: একটি কম্পিউটার ব্যক্তিগত মাধ্যম হিসেবে, শেখা, লেখা, সিমুলেট করা, আঁকা এবং ধারণা গঠনের জন্য—বিশেষ করে শিশু ও অ-বিশেষজ্ঞদের জন্য। তার জন্য তাৎক্ষণিকতা দরকার ছিল। আপনার দেখতে হবে আপনার ক্রিয়াগুলো কী করছে, দ্রুত সংশোধন করতে হবে, এবং সৃজনশীল প্রবাহ বজায় রাখতে হবে।
এ ধরনের পরিবর্তন অনুসরণ করতে হলে হার্ডওয়্যার, সফটওয়্যার এবং ইন্টারঅ্যাকশন ডিজাইন একসাথে পরীক্ষার জন্য জায়গা দরকার। Xerox PARC-এর মতো রিসার্চ ল্যাব দীর্ঘসময়ের শর্তে বাজি ধরার সুযোগ দিয়েছিল: নতুন ডিসপ্লে, নতুন ইনপুট ডিভাইস, নতুন প্রোগ্রামিং মডেল, এবং এগুলোকে একটি সঙ্গত অভিজ্ঞতায় প্যাকেজ করার উপায়। লক্ষ্যটি কোনো ফিচার বের করা ছিল না—বরং নতুন ধরণের কম্পিউটার ব্যবহার আবিষ্কার করা।
কম্পিউটার যদি শেখার ও সৃষ্টির মেশিন হতে চায়, usability আর পরের কাজ হতে পারে না। ইন্টারফেসকে আবিষ্কার, প্রতিক্রিয়া এবং বোঝার ক্ষমতা দিতে হবে। সেই ফোকাস কেয়কে এমন সিস্টেমগুলোর দিকে ঠেলে দিল যেখানে ইন্টারঅ্যাকশনের “ফিল”—আপনি ক্লিক করলে, এডিট করলে বা অন্বেষণ করলে কী ঘটে—সফটওয়্যারের গঠনগত পরিকল্পনার সঙ্গে ঘনিষ্ঠভাবে যুক্ত।
অ্যালান কেয়ে শুরু করেন না “কিভাবে অফিস ওয়ার্ক দ্রুত করা যায়?” দিয়ে। তিনি একটি আলাদা প্রশ্ন দিয়ে শুরু করেছিলেন: যদি কোনো শিশু একটি বইয়ের মতো একটি ব্যক্তিগত কম্পিউটার বহন করতে পারে, এবং সেটি আইডিয়া অন্বেষণ, কিছু তৈরি করা এবং ডু করে শেখার জন্য ব্যবহার করতে পারে তাহলে কী হবে? ধারণাটি Dynabook-এ পরিণত হয়—বেশি হলেও একটি পণ্য স্পেস নয়, একটি উত্তর-তারকা ব্যক্তিগত কম্পিউটিংয়ের জন্য।
Dynabook কল্পনা করা হয়েছিল হালকা, ব্যাটারি-চালিত এবং সর্বদা উপলব্ধ। কিন্তু সবচেয়ে গুরুত্বপূর্ণ শব্দ ছিল “পোর্টেবল” নয়—বলেছিল “ব্যক্তিগত।” এই কম্পিউটারটি ব্যবহারকারীর নিজের মতোই হবে, যেভাবে একটি নোটবুক বা যন্ত্র উপভোগ করা হয়—কিছু যা আপনি সময়ের সঙ্গে গঠন করেন, কেবল অপারেট করেন না।
ততটাই গুরুত্বপূর্ণ: এটি শেখার যোগ্য হতে হবে। কেয়ের লক্ষ্য ছিল কম্পিউটিংকে মেনুদের দেয়াল দিয়ে আড়ালে রেখে দেওয়া নয়; বরং মানুষকে ক্রমে লেখক হওয়ার সুযোগ দেওয়া।
Dynabook-এর 'কিলার অ্যাপস' ছিল পড়া, লেখা, অঙ্কন, সঙ্গীত রচনা, বিজ্ঞান-সম্পর্কিত সিমুলেশন এবং ইন্টারঅ্যাকটিভ গল্প বানানো। এটি প্রোগ্রামিংকে একটি সাক্ষরতার মতো বিবেচনা করত—ধারণা প্রকাশের অন্য একটি উপায়—পেশাদারদের জন্য সংরক্ষিত বিশেষ ট্রেড নয়।
এই ফোকাসই বদলে দেয় 'ভাল সফটওয়্যার' কী মানে। একটি শেখার টুলকে টিঙ্কারিং আমন্ত্রণ জানাতে হবে, দ্রুত ফিডব্যাক দিতে হবে, এবং আবার চেষ্টা করা নিরাপদ করতে হবে।
Dynabook ট্যাবলেট ভবিষ্যদ্বাণী করছিল না; এটি কম্পিউটিংয়ের সঙ্গে একটি নতুন সম্পর্ক প্রস্তাব করছিল: চিন্তা ও সৃষ্টির জন্য একটি মাধ্যম। অনেক ডিভাইস এটি অনুকরণ করতে পারে, কিন্তু ভিশনটি ব্যবহারকারীকে ক্ষমতাবান করা সম্পর্কে—বিশেষ করে শিক্ষার্থীদের—নিয়ে, নির্দিষ্ট স্ক্রিন সাইজ বা হার্ডওয়্যার ডিজাইনের ব্যাপার নয়।
লোকেরা যখন “Smalltalk” শুনে, প্রায়শই একটি প্রোগ্রামিং ভাষার কথা ভাবেন। কেয়ের টিম এটা বড়ভাবে দেখত: একটি সম্পূর্ণ কাজের সিস্টেম যেখানে ভাষা, টুল এবং ব্যবহারকারীর অভিজ্ঞতা একসাথে ডিজাইন করা হয়।
সহজভাবে বলতে গেলে, Smalltalk এমন একটি সিস্টেম যেখানে প্রতিটি কিছুই একটি অবজেক্ট। স্ক্রিনের উইন্ডো, আপনি টাইপ করা টেক্সট, আপনি ক্লিক করা বাটন, আপনি গণনা করা সংখ্যা—প্রত্যেকটি এমন একটি অবজেক্ট যাকে আপনি কোনো কাজ করতে বলতে পারেন।
Smalltalk শেখার মাধ্যমে করার জন্য তৈরি করা হয়েছিল। কোড লিখে কম্পাইল করে আশা করার পরিবর্তে, আপনি চলমান সিস্টেমের অবজেক্টগুলো ইনস্পেক্ট করতে পারতেন, তাদের বর্তমান অবস্থা দেখতেন, পরিবর্তন করতেন এবং নতুন ধারণা তাৎক্ষণিকভাবে পারখ করতে পারতেন।
এই জীবন্ততা গুরুত্বপূর্ণ ছিল কারণ এটি প্রোগ্রামিংকে অন্বেষণে পরিণত করেছিল। আপনি কেবল ফাইল উৎপাদন করছেন না; আপনি একটি চলমান জগত গঠন করছেন। এটি কৌতুহল উত্সাহ দেয়: “এই জিনিসটা কী?” “এর ভিতরে কী আছে?” “এটি একটু টুইক করলে কী হবে?”
Smalltalk-এর ডেভেলপমেন্ট টুলগুলো আলাদা অ্যাড-অন ছিল না। ব্রাউজার, ইনস্পেক্টর, ডিবাগার, এবং এডিটরগুলো একই অবজেক্ট-ভিত্তিক জগতের অংশ ছিল। টুলগুলো সিস্টেমকে ভেতর থেকেই বুঝত, কারণ সেগুলোই একই মাধ্যমে তৈরি করা হয়েছিল।
এই ঘনিষ্ঠ ইন্টিগ্রেশন বদলে দিয়েছিল কাজ করার অনুভূতিটা: দূরের সোর্স কোড ম্যানেজ করা নয়, বরং আপনি যে সিস্টেম তৈরি করছেন তার সঙ্গে সরাসরি ইন্টারঅ্যাক্ট করা।
একটি খোলা এবং প্রতিক্রিয়াশীল ডকুমেন্ট এডিট করার কথা ভাবুন—ফরম্যাটিং তৎক্ষণাৎ বদলায়, আপনি সার্চ, পুনরায়রচনা এবং আনডো করতে পারেন কোনো "বিল্ড" করার আগে। Smalltalk সেই ধরনের তাৎক্ষণিকতা চাইত, কিন্তু প্রোগ্রামের জন্য: আপনি চলমান জিনিস এডিট করেন, ফলাফল সঙ্গে সঙ্গে দেখেন, এবং চলতে থাকেন।
কেয়ের সবচেয়ে দরকারী মেন্টাল মডেলটি হলো “ক্লাস ও ইনহেরিট্যান্স” নয়—বস্তু হলো একটি ছোট, নিজস্ব গণনা-ক্ষমতাসম্পন্ন মেশিন: এটি নিজের স্টেট রাখে (এখন কী জানে) এবং যখন আপনি কিছু করতে বলবেন তখন নিজেই সিদ্ধান্ত নেয় কিভাবে প্রতিক্রিয়া জানায়।
প্রতিটি অবজেক্টকে ভাবুন যা আছে:
এই ফ্রেমিংটি প্রায়োগিক কারণ এটি আপনার দৃষ্টি পরিবর্তন করে: “ডেটা কোথায় সংরক্ষিত?” থেকে “কে এই জবাবদিহি নেবে?” এ চলে যান।
একটি সাধারণ বিভ্রান্তি হলো অবজেক্টকে শুধু ফিল্ডের একটি বান্ডিল হিসেবে দেখা: কয়েকটি হেল্পার ফাংশনসহ। ঐ দৃষ্টিভঙ্গিতে, প্রোগ্রামের অন্যান্য অংশগুলো অবজেক্টের অন্তর্গত অবস্থা ফ্রিক করে এবং বদলে দেয়।
কেয়ের দৃষ্টিভঙ্গি_actor_ ধারণার কাছাকাছি: আপনি একটি অবজেক্টের ভিতরে ঢুকে তার আলমারিগুলো সাজান না। আপনি একটি অনুরোধ পাঠান এবং এটি নিজের স্টেট পরিচালনা করতে দেয়। এই বিভাজনটাই উদ্দেশ্য।
মেসেজ পাসিং মানে সহজভাবে অনুরোধ/প্রতিক্রিয়া।
একটি ক্যাফে কল্পনা করুন: আপনি রান্নাঘরে ঢুকে নিজের খাবার রান্না করেন না। আপনি অর্ডার দেন ("একটা স্যান্ডউইচ বানাও"), এবং আপনি ফল পান ("নিচ্ছে স্যান্ডউইচ" বা "রুটিতে নেই")। ক্যাফে সিদ্ধান্ত নেয় কিভাবে অর্ডার পূরণ করবে।
সফটওয়্যার অবজেক্টগুলোও একইভাবে কাজ করে: আপনি একটি বার্তা পাঠান ("মোট হিসাব কর", "সংরক্ষণ কর", "নিজেকে রেন্ডার কর") এবং অবজেক্ট প্রতিক্রিয়া দেয়।
যখন সিস্টেমের অন্যান্য অংশগুলো কেবল বার্তাগুলোর উপর নির্ভর করে, আপনি একটি অবজেক্টের অভ্যন্তরীণ কাজ পরিবর্তন করতে পারেন—অ্যালগরিদম বদলান, সংগ্রহস্থল বদলান, ক্যাশ যোগ করুন—বিনা পরিমার্জন করে সবখানে।
এভাবেই সিস্টেম বড় হয় ভাঙে না: সীমানায় স্থির চুক্তি এবং ভেতরে স্বাধীনতা।
লোকেরা প্রায়ই 'অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিং'কে ক্লাস ব্যবহারের সমতুল্য ধরে। এটা বোঝা যায়—অনেক ভাষা OOP ক্লাস ডায়াগ্রামের মাধ্যমে শেখায়। কিন্তু কেয়ের মূল জোরটা ছিল আলাদা: যোগাযোগকারী অংশগুলো নিয়ে চিন্তা করা।
একটি ক্লাস হলো একটি ব্লুপ্রিন্ট: কি কিছু জানবে এবং কি করতে পারবে তা বর্ণনা করে।
একটি ইনস্ট্যান্স (অথবা অবজেক্ট) হলো ওই ব্লুপ্রিন্ট থেকে তৈরি একটি কংক্রিট জিনিস—আপনার নির্দিষ্ট "ওটাই"।
একটি মেথড হলো একটি অপারেশন যা অবজেক্টকে অনুরোধ করা হলে এটি করতে পারে।
স্টেট হলো অবজেক্টের বর্তমান ডেটা: সেটি এখন কী মনে রাখে, যা সময়ের সাথে বদলে যেতে পারে।
Smalltalk একটি একরকম অবজেক্ট মডেল জনপ্রিয় করে তুলেছিল: সবই অবজেক্ট, এবং অবজেক্টগুলোর সঙ্গে ইন্টারঅ্যাকশন সঙ্গতিপূর্ণভাবে করা যায়। এটি মেসেজ পাসিং-এও জোর দেয়—অন্যের অভ্যন্তরীণ অংশে পৌঁছানোর বদলে আপনার বার্তা পাঠাবেন এবং এটি নিজে ঠিক করবে কী করা দরকার।
এই স্টাইলটি প্রায়শই লেট বাইন্ডিং (রানটাইমে সিদ্ধান্ত নেওয়া) এর সঙ্গে মিলে যায়: প্রোগ্রাম রানটাইমে ঠিক করে কোন মেথড কোন বার্তা হ্যান্ডেল করবে। ব্যবহারিক সুবিধা হলো নমনীয়তা: আপনি কলার বদল না করে আচরণ বদলাতে পারেন।
একটি ব্যবহারযোগ্য রুল অফ থাম্ব: ইন্টারঅ্যাকশন ঘিরে ডিজাইন করুন। প্রশ্ন করুন "কোন কোন বার্তাগুলো থাকা উচিত?" এবং "কে এই স্টেটের দায়িত্বে থাকবে?" যদি অবজেক্টগুলো সুন্দরভাবে সহযোগিতা করে, ক্লাস স্ট্রাকচার সাধারণত সহজে এবং পরিবর্তনবান্ধবভাবে গড়ে ওঠে।
একটি গ্রাফিক্যাল ইউজার ইন্টারফেস (GUI) সফটওয়্যার ব্যবহারের অনুভূতিটা বদলে দেয়। কমান্ড মনে রাখার পরিবর্তে আপনি পয়েন্ট ও ম্যানিপুলেট করতে পারেন, বস্তুগুলো সরান, খুলুন এবং তাৎক্ষণিক ফল দেখেন। উইন্ডো, মেনু, কন্ট্রোল ও ড্র্যাগ-অ্যান্ড-ড্রপ সবই এমন বিশ্বাস প্রতিফলিত করে: ইন্টারফেসটি অন্বেষণ করে শেখার উপযোগী হওয়া উচিত।
"বস্তু-হিসেবের" ধারণা অবজেক্ট মডেলের সঙ্গে মিল খায়। একটি ভাল ডিজাইনের GUI-তে দেখা ও ইন্টারঅ্যাক্ট করা প্রায় প্রতিটি জিনিসকে অবজেক্ট হিসেবে বিবেচনা করা যায়:
এটা কেবল প্রোগ্রামিং সুবিধা নয়; এটি ধারণাগত সেতু। ব্যবহারকারী ‘উইন্ডো সরাও’, ‘বাটনে ক্লিক কর’—এমন ভাবেই চিন্তা করে, এবং সফটওয়্যারটি এসব কাজ বাস্তবে করতে পারে।
আপনি ক্লিক করলে, টাইপ করলে বা ড্র্যাগ করলে সিস্টেম একটি ইভেন্ট তৈরি করে। অবজেক্ট-ওরিয়েন্টেড দৃষ্টিভঙ্গিতে, একটি ইভেন্ট হলো মূলত একটি বার্তা:
তারপর অবজেক্টগুলো বার্তাগুলো অন্যদের কাছে ফরোয়ার্ড করতে পারে ("ডকুমেন্টকে বলো সেভ কর", "উইন্ডোকে বলো রিড্র করে"), ফলে একটি বোঝানোর যোগ্য অন্তঃক্রিয়া শৃঙ্খলা তৈরি হয়।
UI টিকে ধারাবাহিক অবজেক্ট হিসেবে দেখায়, তাই এটি একটি কার্যক্ষেত্র প্রবেশের মতো মনে হয়—একটি একবারের কমান্ড চালানোর বদলে। উইন্ডো খোলা রাখতেই পারেন, টুলগুলো সাজাতে পারেন, একটি ডকুমেন্টে ফিরে এসে যেখানে ছিলেন সেখানে কাজ চালিয়ে যেতে পারেন। GUI একটি সঙ্গতিপূর্ণ পরিবেশ হয়ে ওঠে—একটি যেখানে কাজগুলো দৃশ্যমান অবজেক্টগুলোর মধ্যে কথোপকথন।
Smalltalk-এর সবচেয়ে আলাদা ধারণাগুলোর একটি ছিল ইমেজ। সোর্স কোডকে কম্পাইল করে একটি অ্যাপে পরিণত করার বদলে, Smalltalk সিস্টেমটিকে একটি চলমান জগত হিসেবে দেখত। যখন আপনি সেভ করতেন, আপনি সম্পূর্ণ জীবন্ত পরিবেশই সেভ করতে পারতেন: মেমরির অবজেক্ট, খুলে থাকা টুল, UI স্টেট এবং আপনার কাজের বর্তমান অবস্থা।
একটি ইমেজ-ভিত্তিক সিস্টেম হলো একটি চলমান চলচ্চিত্র পজ করে কেবল স্ক্রিপ্ট নয়, সঠিক ফ্রেম, সেট এবং প্রতিটি অভিনেতার অবস্থাও সেভ করা। যখন আপনি পুনরায় চালু করেন, আপনি ঠিক সেখানে ফিরে আসেন যেখানে ছেড়ে ছিলেন—আপনার টুলগুলো খোলা, অবজেক্টগুলো এখনও আছে, এবং আপনার পরিবর্তনগুলো ইতিমধ্যেই কার্যকর।
এটি কঠোর ফিডব্যাক লুপকে সমর্থন করে। আপনি আচরণ পরিবর্তন করতে পারেন, তা তাৎক্ষণিকভাবে চেষ্টা করতে পারেন, কী হচ্ছে তা পর্যবেক্ষণ করতে পারেন, এবং পরিমার্জন করতে পারেন—বারবার "রিবিল্ড, রিলঞ্চ, ডেটা রিলোড, স্ক্রিন নেভিগেট" করার মানসিক রিসেট ছাড়া।
এই একই নীতি আধুনিক "vibe-coding" ওয়ার্কফ্লোতেও দেখা যায়: যখন আপনি সাধারণ ভাষায় একটি পরিবর্তন বর্ণনা করতে পারেন, তা তাৎক্ষণিকভাবে প্রিভিউ দেখতে পান এবং পুনরাবৃত্তি করেন, তখন আপনি সিস্টেমকে দ্রুত শিখেন এবং গতি ধরে রাখতে পারেন। প্ল্যাটফর্মগুলি যেমন Koder.ai কথ্য-ভিত্তিক প্রক্রিয়ায় এটির উপর নির্ভর করে—পরিকল্পনা, সামঞ্জস্য, প্রিভিউ—এবং সত্ত্বেও বাস্তব কোড রপ্তানি ও বজায় রাখা যায়।
এখানে Smalltalk ইমেজের অনুরণন পাওয়া যায়:
এসব Smalltalk ইমেজের সম-ই নয়, কিন্তু উদ্দেশ্য একই: একটি ধারণা ও তার ফলাফলের মধ্যে দূরত্ব যতটা সম্ভব ছোট করা।
পুরো চলমান জগত সংরক্ষণ করা কঠিন প্রশ্ন তোলে। যদি "সত্য" একটি মিউটেবল স্টেটে থাকে, পরিষ্কার বিল্ড প্রসেসের বদলে, পুনরুত্পাদনশীলতা দুর্বল হতে পারে। ডিপ্লয়মেন্ট জটিল হয়: একটি ইমেজ শিপ করলে অ্যাপ, ডেটা এবং পরিবেশের মধ্যে সীমানা ঝাপসা হয়ে যায়। নির্দিষ্ট ক্রিয়াকলাপ ও সামঞ্জস্যপূর্ণ স্টেটের উপর নির্ভরশীল বাগ ডিবাগ করাও জটিল হতে পারে।
Smalltalk-এর শর্ত ছিল দ্রুত শেখা ও পুনরাবৃত্তি করা সেই জটিলতাগুলোকে মূল্যবান করে—এবং সেই শর্তটি আজও অনেক টিমের ডেভেলপার এক্সপেরিয়েন্সের চিন্তাভাবনায় ছাপ ফেলে।
অ্যালান কেয়ে যখন সফটওয়্যার নিয়ে কথা বলতেন, তিনি তা প্রায়শই একটি সিস্টেম হিসেবে বিবেচনা করতেন: অনেক উপাদানসমূহ যা সময়ের সঙ্গে একে অপরের সঙ্গে মিশে আচরণ তৈরি করে।
একটি সিস্টেম কোনো একক উপাদান দ্বারা সংজ্ঞায়িত হয় না। এটি সংজ্ঞায়িত হয় সম্পর্কগুলো দ্বারা—কে কার সাথে কথা বলে, তারা কী অনুরোধ করতে পারবে, এবং সেই কথোপকথনগুলো বারবার ঘটলে কী ঘটে।
কয়েকটি সহজ উপাদানই জটিল আচরণ তৈরি করতে পারে যখন আপনি পুনরাবৃত্তি ও ফিডব্যাক যোগ করেন। একটি টাইমার, একটি মডেল যা স্টেট আপডেট করে, এবং একটি UI যা পুনরায় আঁকে—প্রতিটি সহজ হলেও একত্রে তারা অ্যানিমেশন, আনডো/রিডো, অটোসেভ, এলার্ট এবং “এটা কেন বদলে গেল?” ধরনের আচরণ তৈরি করতে পারে।
এজন্য সিস্টেম চিন্তা ব্যবহারিক: এটা আপনাকে লুপগুলো খুঁজে বের করতে বলে ("A বদলে গেলে B কীভাবে প্রতিক্রিয়া করে, যা C-কে ট্রিগার করে…") এবং সময়কে বিবেচনা করতে বলে ("১০ মিনিট ব্যবহারির পর কী ঘটে?")—কেবল একক ফাংশন কল নয়।
একটি সিস্টেমে, ইন্টারফেসগুলো বাস্তবে ইমপ্লিমেন্টেশনের চাইতে বেশি গুরুত্বপূর্ণ। যদি একটি অংশ অন্যটিকে স্পষ্ট বার্তাগুলোর মাধ্যমে ইন্টারঅ্যাক্ট করে ("কাউন্ট বাড়াও", "রেন্ডার করো", "ইভেন্ট রেকর্ড করো"), আপনি অভ্যন্তরীণ পরিবর্তন করে দিতে পারেন বাকি সিস্টেম ছেড়ে দিয়ে।
এটি কেয়ের মেসেজ পাসিং জোরের সঙ্গে মিলছে: আপনি অন্য অংশ নিয়ন্ত্রণ করেন না; আপনি জিজ্ঞেস করেন, তারা উত্তর দেয়।
ধরুন তিনটি অবজেক্ট আছে:
সময়ের উপর প্রবাহ:
clicked পাঠায়।increment পাঠায় CounterModel-কে।changed(newValue) পাঠায়।changed শুনে রেন্ডার করে।record("increment", newValue) গ্রহণ করে।কোনো উপাদান আরেকটির ভেতর ঢুকে দেখছে না। আচরণ কথোপকথন থেকে উদ্ভূত হয়।
অ্যালান কেয়ে একটি সরল ধারণা প্রস্তাব করেছিলেন যা আজও কিছুটা বিপ্লবী মনে হয়: সফটওয়্যারকে শক্তিশালী করার বদলে শেখা সহজ হওয়া উচিত। “চতুর” ডিজাইন প্রায়ই নির্মাতার সন্তুষ্টির জন্য অপ্টিমাইজ করে—শর্টকাট, লুকোনো কৌশল, ঘন আবস্ট্রাকশন—এবং সাধারণ ব্যবহারকারীদের চলে যায় মনের মধ্যে আচরণ শিড়িয়ে নেওয়ার দিকে।
কেয়ে সরলতাকে গুরুত্ব দিয়েছেন কারণ এটি স্কেল করে: একটি ধারণা যা একজন শিক্ষার্থী দ্রুত ধরতে পারে, তা টিমে শিখানো, ভাগ করা এবং উপর ভিত্তি করে নির্মাণ করা সহজ করে।
অনেক সফটওয়্যার ব্যবহারকারীদের অপারেটর হিসেবে দেখে: সঠিক বোতাম চাপলে আউটপুট পাবেন। কেয়ের লক্ষ্য ছিল চিন্তা-সহায়ক টুল—এমন কিছু যা অন্বেষণ আমন্ত্রণ জানায়, পরীক্ষা-নিরীক্ষা সমর্থন করে, এবং মানুষের মেন্টাল মডেল বানাতে দেয়।
এই কারণে তিনি ইন্টারঅ্যাকটিভ সিস্টেমকে মূল্য দিয়েছেন যেখানে আপনি কী হচ্ছে তা দেখতে পান এবং চলতে চলতে সামঞ্জস্য করতে পারেন। যখন সিস্টেম তাৎক্ষণিক ও অর্থপূর্ণ প্রতিক্রিয়া দেয়, শেখা ব্যবহার করার অংশে পরিণত হয়।
কেয়ে প্রায়ই শেখাকে (কখনও কখনও শিশুদের ব্যবহারকারী হিসেবে কল্পনা করে) ক্লারিটি শক্তির জন্য ব্যবহার করতেন। যদি কোনও ধারণা সরাসরি ম্যানিপুলেট করা যায়, ইন্সপেক্ট করা যায় এবং ব্যাখ্যা করা যায়—হাত ঝাপটা ছাড়াই—তাহলেই সেটি সবার জন্য কাজ করার সম্ভাবনা বেশি।
এটার মানে নয় "শুধু বাচ্চাদের জন্য ডিজাইন করা"। এর মানে হলো শেখাতে সক্ষমতা একটি মান নির্দেশক: সিস্টেম নিজের যুক্তি প্রকাশ করতে পারে কি না?
শিখার যোগ্যতাকে একটি প্রোডাক্ট ফিচার হিসেবে বিবেচনা করুন। আপনি ডিজাইন করতে পারেন:
ফলাফল শুধু সুখী শিক্ষার্থীরা নয়। দ্রুত অনবোর্ডিং, কম সাপোর্ট টিকট এবং এমন একটি প্রোডাক্ট যাকে লোকেরা আত্মবিশ্বাসের সঙ্গে বাড়াতে পারে—এগুলোই কেয় চেয়েছিলেন সফটওয়্যার দিয়ে বাড়ানো।
কেয়ের কাজ সবকিছু আবিষ্কার করেনি, তবে এটি অনেককিছুর উপর গভীর প্রভাব ফেলেছে—বিশেষ করে মানুষের জন্য তৈরি সফটওয়্যার কীভাবে বানানো হয় তা নিয়ে।
অনেক আধুনিক অনুশীলন তাদের ভিত্তি পায় Smalltalk এবং Xerox PARC-সংস্কৃতি থেকে:
মূল ভিশনের কিছু অংশ সোজা করে চলে আসেনি:
আপনি যদি নজরদারি করেন, অনেক বর্তমান প্যাটার্ন মেসেজ পাসিংয়ের সঙ্গে অনুরণন করে: কম্পোনেন্ট-ভিত্তিক UI (React/Vue), ইভেন্ট-চালিত অ্যাপ, এমনকি মাইক্রোসার্ভিসগুলো HTTP বা কিউজের মাধ্যমে যোগাযোগ করে। এগুলো একই নয়—কিন্তু কেয়ের মূল ধারণা (অন্তঃক্রিয়াশীল অংশ হিসেবে সিস্টেম) আধুনিক সীমাবদ্ধতার মধ্যেই পুনরায় ব্যাখ্যা হচ্ছে।
যদি আপনি ইতিহাস থেকে অনুশীলনে সরাসরি পুল করতে চান, পোস্টের শেষ অংশটি (দেখুন /blog/practical-takeaways) এই প্রভাবগুলোকে এমন ন্যায়সঙ্গত ডিজাইন অভ্যাসে রূপান্তর করে যা আপনি অবিলম্বে ব্যবহার করতে পারবেন।
কেয়ের কাজ দার্শনিক শুনাতে পারে, কিন্তু তা খুবই ব্যবহারিক অভ্যাসে অনুবাদ করা যায়। আপনাকে Smalltalk ব্যবহার করার দরকার নেই—এমনকি কঠোরভাবে OOP করবেই না বলে কেয়ের লাভ মিলবে। লক্ষ্যটি এমন সফটওয়্যার তৈরি করা যা বেড়ে ওঠার সঙ্গে বোঝা সহজ থাকে।
শুরুতে (অথবা রিফ্যাক্টরিংয়ে) চেষ্টা করুন সিস্টেমটিকে এমন ভূমিকা-সমষ্টি হিসেবে বর্ণনা করতে:
এতে আপনি ক্লাস দরকার এয়ারোপার্কে নয়, দায়িত্বে ফোকাস রাখেন।
ডেটাবেস টেবিল বা ক্লাস হায়ারার্কি নিয়ে ঝগড়ার আগে বার্তাগুলো সংজ্ঞায়িত করুন—একটি অংশ অন্যটি কী ধরনের অনুরোধ করবে তা।
একটি ব্যবহারযোগ্য ব্যায়াম: একটি ব্যবহারকারীর কার্যক্রমের ছোট “কনভারসেশন” লিখুন:
getTotal জানে।”isAvailable জিজ্ঞাসা করে।”authorize বলবে।”তারপরই সিদ্ধান্ত নিন কিভাবে ভূমিকা বাস্তবায়িত হবে (ক্লাস, মডিউল, সার্ভিস)। এটি কেয়ের জোর—মেসেজ পাসিং: আগে আচরণ, পরে কাঠামো।
কেয় লাইভ সিস্টেম পছন্দ করতেন যেখানে পরিবর্তনের প্রভাব দ্রুত দেখা যায়। আধুনিক টিমে এর মানে সাধারণত:
আপনি যদি একটি চ্যাট-চালিত ওয়ার্কফ্লো (উদাহরণস্বরূপ Koder.ai) দিয়ে নির্মাণ করেন, একই উপদেশ প্রযোজ্য: প্রম্পট ও উৎপাদিত আউটপুটকে দ্রুত পুনরাবৃত্তির উপায় হিসেবে ব্যবহার করুন, কিন্তু সীমানাগুলো স্পষ্ট রাখুন, এবং স্ন্যাপশট/রোলব্যাক ও সোর্স-কোড এক্সপোর্টের মত সেফগার্ড রাখুন যাতে সিস্টেম বুঝতে সহজ থাকে।
এই বিষয়গুলো আরও অন্বেষণ করুন:
এই বিষয়গুলো নস্টালজিয়া নয়—এগুলো স্বাদের উন্নয়নের বিষয়ে: এমন সফটওয়্যার বানানো যা শেখার যোগ্য, অভিযোজনশীল এবং একটি সিস্টেম হিসেবে সঙ্গতিপূর্ণ।
অ্যালান কেয়ে একটি বিভিন্ন সম্পর্ক پیشنهاد করেছিলেন কম্পিউটারের সঙ্গে: কিউ করে ব্যাচ কাজ দেওয়ার পরিবর্তে, একটি ইন্টারঅ্যাকটিভ ব্যক্তিগত মাধ্যম যেখানে শেখা এবং সৃষ্টিই মূল উদ্দেশ্য।
এই মানসিকতা সেই প্রত্যাশাগুলোকে গড়ে তুলেছে যা আমরা এখন স্বাভাবিক মনে করি—তাৎক্ষণিক প্রতিক্রিয়া, অবজেক্টগুলোর মতো ম্যানিপুলেবল ইন্টারফেস এবং এমন সফটওয়্যার যাকে কাজ করার সময়ই অন্বেষণ ও পরিবর্তন করা যায়।
Dynabook ছিল একটি পোর্টেবল, ব্যক্তিগত কম্পিউটারের ভিশন যা মূলত শেখা ও সৃজনশীলতার জন্য ডিজাইন করা ছিল (পড়া, লেখা, অঙ্কন, সিমুলেশন)।
এটা বেশি “তাকে ট্যাবলেট হিসেবে ভবিষ্যদ্বাণী করা” নয়; বরং এটি সংজ্ঞায়িত করেছিল কীভাবে ক্ষমতাবান কম্পিউটিংটি অনুভূত হওয়া উচিত: ব্যবহারকারীকে অপারেটর না করে লেখক হিসেবে শক্তিশালী করা।
Smalltalk-এ ভাষা, টুল এবং UI এক সুসংগঠিত পরিবেশ হিসেবে কাজ করত।
প্রায়োগিকভাবে এর মানে: আপনি চলমান অবজেক্টগুলো পরীক্ষা করতে পারেন, আচরণ পরিবর্তন করতে পারেন, ইন্টারেক্টিভভাবে ডিবাগ করতে পারেন এবং বারবার রিবিল্ড না করেই কাজ চালিয়ে যেতে পারেন—এটি ভাবনা থেকে ফলাফলের দূরত্ব কমায়।
কেয়ের মূল ধারণা ছিল অবজেক্টগুলো স্বাধীন এজেন্ট হিসেবে কাজ করে এবং তারা বার্তা পাঠিয়ে একে অপরের সাথে যোগাযোগ করে।
ডিজাইন দৃষ্টিকোণ থেকে, এটা আপনাকে স্পষ্ট সীমারেখা নির্ধারণ করতে বাধ্য করে: কলকারীরা নির্ভর করে ওই অবজেক্ট কোন বার্তা গ্রহণ করে, না যে তার অভ্যন্তরীণ ডেটা কেমন।
একটি সাধারণ ভুল হচ্ছে OOP-কে কেবল 'ক্লাস + ইনহেরিট্যান্স' হিসেবে দেখা: অনেক ক্লাস, গভীর উত্তরাধিকার এবং শেয়ার্ড মিউটেবল ডেটা।
কেয়ের দৃষ্টিকোণ অনুসারে ভাল নিয়মটি:
GUI-গুলো সফটওয়্যারকে এমনভাবে অনুভব করায় যেন আপনি কোন 'বস্তু' ম্যানিপুলেট করছেন (উইন্ডো, বাটন, আইকন)। এটা অবজেক্ট মডেলের সঙ্গে স্বাভাবিকভাবে মেলে কারণ প্রতিটি UI উপাদানই স্টেট এবং আচরণ রাখে।
ব্যবহারকারীর ক্রিয়াকলাপ (ক্লিক, ড্র্যাগ, টাইপ) ইভেন্ট হিসেবে উঠলে সেগুলো অবজেক্টকে পাঠানো বার্তা হিসেবে বিবেচিত হতে পারে, এবং সেই অবজেক্টগুলো প্রয়োজন হলে বার্তা অন্য কোথাও ফরোয়ার্ডও করে।
Smalltalk image পুরো চলমান বিশ্বের অবস্থা সংরক্ষণ করে: মেমরিতে থাকা অবজেক্ট, খুলে থাকা টুল, UI স্টেট এবং আপনার চলমান কাজ সবই।
ফায়দা:
টার্ডঅফস:
সিস্টেম চিন্তাভাবনা সময়ের সাথে আচরণকে গুরুত্ব দেয়: ফিডব্যাক লুপ, ক্রমবর্ধমান প্রতিক্রিয়া, এবং কে কার সাথে কথা বলে।
প্রয়োগে, এটি পরিষ্কার ইন্টারফেস (বার্তা) এবং কম লুকোনো নির্ভরশীলতা তৈরিতে পরিচালিত করে, কারণ আপনি অ্যাপটিকে আলাদা পার্টস হিসেবে দেখেন—কেবল ফাংশনের সমষ্টি নয়।
আপনি Smalltalk ব্যবহার না করেও কেয়ের ভাবনাগুলো প্রয়োগ করতে পারেন:
getTotal, isAvailable, authorize).এরপরই নির্ধারণ করুন কিভাবে এগুলো বাস্তবে করা হবে (ক্লাস, মডিউল, সার্ভিস)।
আধুনিক টুলগুলো প্রায়ই কেয়ের লক্ষ্যগুলোকে অনুকরণ করে, যদিও বাস্তবায়ন আলাদা:
এসব পুরোপুরি Smalltalk ইমেজ নয়, কিন্তু তারা একই প্রায়োগিক উদ্দেশ্য পূরণ করে: পরিবর্তন ও শেখাকে সস্তা করে তোলা।