لماذا نستخدم الكلاس في البرمجة بدلًا من كتابة مجموعة من المتغيرات والدوال المنفصلة؟ نستخدم الكلاس لأنه يجمع البيانات والوظائف المرتبطة بها داخل وحدة منظمة يمكن إنشاء نسخ متعددة منها، مما يجعل الكود أسهل في الفهم والتطوير والاختبار وإعادة الاستخدام.
يمكن تشبيه الكلاس بمخطط هندسي يحدد صفات الشيء وما يستطيع فعله، بينما يمثل الـ Object نسخة فعلية تم إنشاؤها بالاعتماد على هذا المخطط.
على سبيل المثال، يمكن إنشاء كلاس باسم Student يحدد أن لكل طالب اسمًا وعمرًا ودرجة، ويوفر وظائف لحساب النتيجة أو عرض بيانات الطالب. بعد ذلك يمكن إنشاء مئات الطلاب من الكلاس نفسه دون تكرار منطق البرنامج لكل طالب.
توضح وثائق Python الرسمية أن الكلاسات توفر وسيلة لجمع البيانات والوظائف معًا، وأن إنشاء كلاس جديد يؤدي إلى إنشاء نوع جديد من الكائنات يمكن تكوين نسخ متعددة منه. كما تصف مفاهيم البرمجة كائنية التوجه الكائن بأنه حزمة تجمع الحالة والسلوك المرتبطين بها.
ما هو الكلاس في البرمجة؟
الكلاس أو Class هو قالب برمجي يصف البيانات والسلوكيات المشتركة بين مجموعة من الكائنات.
يتكون الكلاس عادة من عنصرين أساسيين:
- الخصائص Attributes: البيانات التي تصف حالة الكائن، مثل الاسم والسعر والرصيد.
- الدوال Methods: العمليات التي يستطيع الكائن تنفيذها، مثل الدفع أو تسجيل الدخول أو حساب الخصم.
لنفترض أننا نطوّر متجرًا إلكترونيًا. كل منتج يمتلك اسمًا وسعرًا وكمية متاحة، كما يمكن حساب سعره بعد الخصم. بدلًا من توزيع هذه التفاصيل على متغيرات ودوال غير مترابطة، يمكن جمعها داخل كلاس واحد:
class Product:
def __init__(self, name, price, quantity):
self.name = name
self.price = price
self.quantity = quantity
def price_after_discount(self, discount):
return self.price * (1 – discount / 100)
يمكن بعد ذلك إنشاء أكثر من منتج:
phone = Product(“هاتف ذكي”, 3000, 10)
laptop = Product(“حاسوب محمول”, 6500, 5)
print(phone.price_after_discount(10))
print(laptop.price_after_discount(15))
الكلاس هنا لا يمثل منتجًا واحدًا، بل يحدد القواعد التي يجب أن تتبعها جميع المنتجات.
ما الفرق بين الكلاس والأوبجكت؟
الكلاس هو المخطط، بينما الأوبجكت أو Object هو نسخة فعلية من ذلك المخطط.
يمكن توضيح الفرق من خلال هذا المثال:
| العنصر | المعنى | المثال |
| الكلاس | قالب يحدد الخصائص والوظائف | مخطط تصميم سيارة |
| الأوبجكت | نسخة تم إنشاؤها من القالب | سيارة محددة على الطريق |
| الخاصية | معلومة تخص الكائن | اللون أو السرعة |
| الدالة | سلوك يستطيع الكائن تنفيذه | التشغيل أو التوقف |
عند كتابة:
class Car:
def __init__(self, brand, color):
self.brand = brand
self.color = color
def start(self):
return f”تم تشغيل سيارة {self.brand}”
فإن Car هو الكلاس.
أما عند كتابة:
car_one = Car(“Toyota”, “أبيض”)
car_two = Car(“Ford”, “أسود”)
فإن car_one وcar_two كائنان مستقلان. كلاهما يتبع التصميم نفسه، لكن لكل واحد بياناته الخاصة.
هذه النقطة من أهم أسباب استخدام الكلاس: يمكنك تطبيق القواعد نفسها على كائنات كثيرة مع الاحتفاظ بحالة مستقلة لكل كائن. وتوضح وثائق Java الرسمية أن الكائنات التابعة للنوع نفسه تمتلك حقولًا متشابهة، لكن كل نسخة تحتفظ بقيمها الخاصة.
لماذا نستخدم الكلاس في البرمجة عمليًا؟
نستخدم الكلاس عندما نريد تمثيل كيان يمتلك بيانات وسلوكًا مترابطين، أو عندما نحتاج إلى إنشاء عدة كائنات تتبع القواعد نفسها.
تظهر فائدته بوضوح في التطبيقات المتوسطة والكبيرة التي تحتوي على مستخدمين ومنتجات وطلبات ومدفوعات ورسائل وعناصر أخرى تتفاعل مع بعضها.
أهم فوائد الكلاس هي:
- تنظيم البيانات والدوال المرتبطة بها.
- تقليل تكرار الكود.
- إنشاء نسخ متعددة من الكيان نفسه.
- حماية الحالة الداخلية للكائن.
- تسهيل صيانة البرنامج وتوسيعه.
- توزيع العمل بين أعضاء الفريق.
- دعم الاختبار وإصلاح الأخطاء.
- تمثيل نطاق العمل بطريقة مفهومة.
لكن هذا لا يعني أن كل جزء من البرنامج يجب أن يتحول إلى كلاس. أحيانًا تكون دالة بسيطة أكثر وضوحًا وأقل تعقيدًا.
كيف يساعد الكلاس على تنظيم الكود؟
تخيل برنامجًا مصرفيًا صغيرًا دون استخدام الكلاسات:
customer_name = “أحمد”
customer_balance = 1000
def deposit(balance, amount):
return balance + amount
def withdraw(balance, amount):
if amount > balance:
return balance
return balance – amount
قد يبدو هذا الكود مقبولًا في البداية، لكن ماذا سيحدث عند إضافة 100 عميل؟
سنحتاج إلى متغيرات كثيرة، وقد نربط رصيد عميل باسم عميل آخر بالخطأ. كما ستصبح إدارة العمليات والصلاحيات وسجل المعاملات أكثر صعوبة.
يمكن تنظيم الفكرة داخل كلاس:
class BankAccount:
def __init__(self, owner, balance=0):
self.owner = owner
self.balance = balance
def deposit(self, amount):
if amount <= 0:
raise ValueError(“يجب أن يكون مبلغ الإيداع أكبر من صفر”)
self.balance += amount
return self.balance
def withdraw(self, amount):
if amount <= 0:
raise ValueError(“يجب أن يكون مبلغ السحب أكبر من صفر”)
if amount > self.balance:
raise ValueError(“الرصيد غير كافٍ”)
self.balance -= amount
return self.balance
أصبحت بيانات الحساب والقواعد التي تتحكم فيها موجودة في مكان واحد. عندما يقرأ مطور آخر الكود، يستطيع معرفة مسؤولية BankAccount دون البحث في ملفات ودوال كثيرة.
كيف يقلل الكلاس من تكرار الكود؟
دون الكلاسات قد يكرر المبرمج البيانات والدوال نفسها لكل مستخدم أو منتج أو مركبة.
أما باستخدام الكلاس، فنكتب القواعد مرة واحدة ثم ننشئ منها العدد المطلوب من الكائنات:
account_one = BankAccount(“سارة”, 1500)
account_two = BankAccount(“خالد”, 900)
account_three = BankAccount(“منى”, 2400)
جميع الحسابات تستطيع تنفيذ deposit وwithdraw لأن هذه الوظائف معرّفة داخل الكلاس.
وعند اكتشاف خطأ في طريقة السحب، يكفي تعديله داخل BankAccount بدلًا من البحث عن نسخ متعددة من المنطق نفسه.
لكن إعادة الاستخدام ليست مبررًا لإنشاء كلاس ضخم يحتوي على عشرات المسؤوليات. التصميم الجيد يجعل لكل كلاس غرضًا واضحًا، مثل:
- User لإدارة بيانات المستخدم.
- Order لإدارة الطلب.
- Payment لتنفيذ الدفع.
- Notification لإرسال الإشعارات.
كلما كانت المسؤولية أوضح، أصبح تعديل الكود واختباره أكثر أمانًا.
كيف يحمي الكلاس بيانات البرنامج؟
من المبادئ المرتبطة بالكلاسات مفهوم التغليف Encapsulation، وهو جمع البيانات مع العمليات المسموح بتنفيذها عليها، مع الحد من التعديل العشوائي للحالة الداخلية.
لنفترض أن لدينا رصيدًا بنكيًا. السماح لأي جزء من البرنامج بتغيير الرصيد مباشرة قد يؤدي إلى قيمة سالبة أو عملية غير مسجلة.
الأفضل أن يتم التغيير من خلال دوال تحتوي على قواعد واضحة:
class Wallet:
def __init__(self):
self._balance = 0
def add_money(self, amount):
if amount <= 0:
raise ValueError(“القيمة غير صالحة”)
self._balance += amount
def get_balance(self):
return self._balance
الفكرة ليست مجرد وضع شرطة سفلية قبل اسم المتغير، لأن مستوى الحماية يختلف باختلاف لغة البرمجة. الفكرة الأساسية هي توفير واجهة واضحة للتعامل مع حالة الكائن بدلًا من تعديلها عشوائيًا.
يساعد ذلك على ضمان أن كل تغيير يمر بالقواعد التي وضعها البرنامج.
كيف يجعل الكلاس تطوير المشروع أسهل؟
تتغير البرامج باستمرار. قد يطلب العميل إضافة خصومات أو صلاحيات أو طرق دفع أو أنواع جديدة من الحسابات.
عندما تكون مسؤوليات النظام موزعة على كلاسات واضحة، يمكن تعديل الجزء المطلوب مع تقليل التأثير في الأجزاء الأخرى.
في متجر إلكتروني مثلًا، قد يحتوي النظام على:
- Product
- Customer
- ShoppingCart
- Order
- Payment
- Shipment
بدلًا من وضع كل شيء في ملف واحد، يمثل كل كلاس مفهومًا محددًا.
عند تغيير طريقة حساب الشحن، يعرف المطور أن المنطق الأساسي يوجد غالبًا داخل Shipment. وعند تعديل قواعد السلة، يتجه إلى ShoppingCart.
هذه البنية لا تمنع الأخطاء تلقائيًا، لكنها تقلل الوقت اللازم لفهم مكان المسؤوليات وكيفية انتقال البيانات داخل النظام.
كيف يسهّل الكلاس اختبار البرنامج؟
يمكن اختبار كل كلاس بصورة شبه مستقلة، خاصة عندما تكون مسؤولياته محددة ولا يعتمد مباشرة على تفاصيل كثيرة خارجية.
مثال على اختبار حساب بنكي:
def test_deposit():
account = BankAccount(“أحمد”, 100)
account.deposit(50)
assert account.balance == 150
ومثال على اختبار منع السحب الزائد:
import pytest
def test_cannot_withdraw_more_than_balance():
account = BankAccount(“أحمد”, 100)
with pytest.raises(ValueError):
account.withdraw(150)
هذه الاختبارات توضح السلوك المتوقع للكلاس. إذا عدّل أحد المطورين الكود لاحقًا وأفسد قاعدة السحب، يستطيع الاختبار اكتشاف المشكلة مبكرًا.
ومع ذلك، يجب ألا يعتمد الكلاس على قواعد بيانات وخدمات خارجية مباشرة دون تصميم مناسب، لأن كثرة الاعتماديات قد تجعل الاختبار أكثر تعقيدًا.
كيف يساعد الكلاس على تمثيل الأشياء الواقعية؟
تستخدم البرمجة كائنية التوجه الكلاسات لتمثيل مفاهيم نطاق المشروع، وليس فقط الأشياء المادية.
يمكن أن يمثل الكلاس:
- طالبًا في منصة تعليمية.
- طلبًا في متجر إلكتروني.
- موعدًا في نظام حجز.
- فاتورة في برنامج محاسبي.
- جلسة مستخدم في تطبيق.
- رسالة داخل نظام محادثة.
- اشتراكًا في خدمة رقمية.
على سبيل المثال:
class Course:
def __init__(self, title, lessons):
self.title = title
self.lessons = lessons
def completion_percentage(self, completed_lessons):
if self.lessons == 0:
return 0
return completed_lessons / self.lessons * 100
الكلاس لا يقلد الواقع حرفيًا، بل يختار المعلومات والسلوكيات التي يحتاج إليها البرنامج.
ليس من الضروري أن يحتوي كلاس الطالب على كل تفصيل متعلق بالإنسان. يكفي أن يتضمن ما يفيد النظام، مثل الاسم ورقم التسجيل والدورات المشترك بها.
ما علاقة الكلاس بالوراثة؟
الوراثة Inheritance تسمح بإنشاء كلاس جديد يعتمد على كلاس موجود ويضيف إليه أو يخصص بعض سلوكياته.
مثال:
class Employee:
def __init__(self, name, salary):
self.name = name
self.salary = salary
def calculate_bonus(self):
return self.salary * 0.05
class Manager(Employee):
def calculate_bonus(self):
return self.salary * 0.10
هنا يرث Manager خصائص Employee، لكنه يقدم طريقة مختلفة لحساب المكافأة.
يمكن أن تكون الوراثة مفيدة عندما توجد علاقة حقيقية من نوع «هو نوع من». فالمدير نوع من الموظفين.
لكن استخدامها لمجرد التخلص من بضعة أسطر مكررة قد ينتج تصميمًا معقدًا. في كثير من المشاريع يكون التركيب Composition أوضح، أي أن يحتوي الكائن على كائن آخر بدلًا من أن يرث منه.
مثلًا، السيارة «تحتوي على» محرك، لكنها ليست نوعًا من المحرك. لذلك يكون وضع كائن Engine داخل Car أكثر منطقية من جعل Car يرث من Engine.
ما الفرق بين الكلاس والدالة؟
الدالة تنفذ مهمة محددة، بينما يجمع الكلاس حالة مستمرة مع مجموعة من الوظائف التي تتعامل معها.
| استخدم دالة عندما | استخدم كلاس عندما |
| تكون العملية مستقلة وبسيطة | توجد بيانات وسلوكيات مترابطة |
| لا تحتاج إلى الاحتفاظ بحالة | تحتاج إلى الاحتفاظ بحالة بين العمليات |
| لا تنشئ نسخًا متعددة | تحتاج إلى عدة كائنات من النوع نفسه |
| المدخلات تنتج مخرجات مباشرة | توجد دورة حياة وقواعد للكيان |
مثال مناسب للدالة:
def calculate_tax(price, tax_rate):
return price * tax_rate
لا يحتاج هذا المنطق بالضرورة إلى كلاس، لأنه يستقبل قيمًا ويعيد نتيجة دون الاحتفاظ بحالة.
أما سلة التسوق فتحتاج غالبًا إلى كلاس لأنها تحتفظ بالمنتجات والكميات وتسمح بالإضافة والحذف وحساب الإجمالي:
class ShoppingCart:
def __init__(self):
self.items = []
def add_item(self, product):
self.items.append(product)
def total_items(self):
return len(self.items)
السؤال الصحيح ليس: «هل أستطيع استخدام كلاس؟»، بل: «هل سيجعل الكلاس التصميم أوضح وأسهل في التغيير؟».
متى يجب استخدام الكلاس؟
غالبًا يكون الكلاس مناسبًا في الحالات التالية:
- عندما توجد بيانات ودوال تنتمي إلى مفهوم واحد.
- عندما تحتاج إلى إنشاء نسخ متعددة مع حالات مستقلة.
- عندما يمتلك الكيان دورة حياة تتغير خلالها حالته.
- عندما توجد قواعد يجب فرضها على البيانات.
- عندما تريد توفير واجهة واضحة لبقية أجزاء البرنامج.
- عندما يسهل الكلاس اختبار المسؤولية بصورة مستقلة.
- عندما يتوقع أن يتوسع المشروع وتزداد وظائفه.
مثلًا، يعد استخدام كلاس للطلب منطقيًا لأن الطلب يمتلك رقمًا وحالة ومنتجات وسعرًا، ويمر بمراحل مثل الإنشاء والدفع والشحن والإلغاء.
متى لا نحتاج إلى استخدام الكلاس؟
قد لا تحتاج إلى كلاس عندما تكون المشكلة صغيرة جدًا أو لا توجد حالة يجب الاحتفاظ بها.
من الحالات التي قد تكفي فيها الدوال:
- تحويل درجة الحرارة.
- تنسيق نص.
- حساب ضريبة بسيطة.
- التحقق من بريد إلكتروني.
- قراءة قيمة وإجراء عملية واحدة عليها.
- سكربت قصير يستخدم مرة واحدة.
إنشاء كلاس باسم TemperatureConverter يحتوي على دالة واحدة فقط قد لا يقدم فائدة حقيقية:
class TemperatureConverter:
def celsius_to_fahrenheit(self, value):
return value * 9 / 5 + 32
الدالة المباشرة أبسط:
def celsius_to_fahrenheit(value):
return value * 9 / 5 + 32
الكلاس أداة لتنظيم التعقيد، وليس هدفًا يجب تطبيقه في كل سطر.
ما أشهر الأخطاء عند استخدام الكلاسات؟
أحد الأخطاء الشائعة هو إنشاء «كلاس عملاق» يدير المستخدمين والطلبات والدفع والإشعارات في الوقت نفسه. يصبح هذا الكلاس صعب الفهم والاختبار، وقد يؤدي أي تعديل صغير فيه إلى آثار جانبية غير متوقعة.
ومن الأخطاء المتكررة أيضًا:
- إنشاء كلاس لكل دالة بسيطة.
- جعل خصائص الكائن قابلة للتعديل دون قواعد.
- الاعتماد المفرط على الوراثة.
- استخدام أسماء عامة مثل Manager أو Helper.
- خلط التعامل مع قاعدة البيانات بمنطق العمل والعرض.
- إضافة وظائف لا ترتبط بمسؤولية الكلاس.
- تمرير عدد كبير جدًا من القيم إلى المنشئ.
- إنشاء ترابط قوي بين الكلاسات.
- استخدام متغيرات مشتركة دون فهم الفرق بينها وبين متغيرات النسخة.
في بعض اللغات توجد خصائص تابعة للكلاس نفسه وخصائص مستقلة لكل Object. وتشير وثائق Java إلى أن متغيرات الكلاس المشتركة تكون متاحة لجميع النسخ، بينما تحصل كل نسخة على قيمها الخاصة من متغيرات الكائن.
كيف نعرف أن تصميم الكلاس جيد؟
يمكن تقييم الكلاس من خلال مجموعة أسئلة عملية:
- هل أستطيع وصف مسؤوليته في جملة واحدة؟
- هل وظائفه مرتبطة بالبيانات التي يحتفظ بها؟
- هل اسمه يكشف الغرض منه؟
- هل يمكن اختباره دون تشغيل النظام كاملًا؟
- هل تعديل إحدى وظائفه يؤثر في أجزاء كثيرة؟
- هل يعتمد على عدد كبير من الكلاسات الأخرى؟
- هل يحتوي على منطق يجب نقله إلى مكان آخر؟
لنفترض وجود كلاس باسم User يتولى تسجيل الدخول وإرسال البريد وحفظ البيانات وحساب الفواتير وقراءة التقارير. رغم أن كل العمليات مرتبطة بالمستخدم بصورة ما، فإنها لا تنتمي بالضرورة إلى مسؤولية واحدة.
يمكن توزيعها على مكونات أوضح:
- User
- AuthenticationService
- EmailService
- InvoiceService
- UserRepository
ليس المطلوب زيادة عدد الكلاسات بلا حدود، وإنما وضع كل قاعدة في المكان الذي يجعلها مفهومة وقابلة للتغيير.
كيف نطبق الكلاس في مثال متكامل؟
لنفترض أننا نريد بناء نظام مبسط لإدارة الدورات التعليمية:
- class Student:
def __init__(self, name):
self.name = name
self.enrolled_courses = []
def enroll(self, course):
if course not in self.enrolled_courses:
self.enrolled_courses.append(course)
- class Course:
def __init__(self, title, capacity):
self.title = title
self.capacity = capacity
self.students = []
def add_student(self, student):
if len(self.students) >= self.capacity:
raise ValueError(“لا توجد أماكن متاحة”)
if student not in self.students:
self.students.append(student)
student.enroll(self)
def available_seats(self):
return self.capacity – len(self.students)
الاستخدام:
python_course = Course(“أساسيات Python”, 2)
sara = Student(“سارة”)
khaled = Student(“خالد”)
python_course.add_student(sara)
python_course.add_student(khaled)
print(python_course.available_seats())
print(sara.enrolled_courses[0].title)
يوضح المثال عدة فوائد:
- يحتفظ كل طالب بدوراته.
- تحتفظ كل دورة بطلابها.
- تمنع الدورة تجاوز السعة.
- يمكن إنشاء عدد غير محدود من الطلاب والدورات.
- توجد قاعدة التسجيل في مكان واضح.
- يمكن تطوير النظام لاحقًا بإضافة المدربين أو الدرجات أو الحضور.
هذه هي القيمة الحقيقية للكلاس: تحويل قواعد المشروع إلى أجزاء منظمة تعبّر عن النظام بدلًا من توزيعها بين متغيرات ودوال متفرقة.
ما الخلاصة السريعة؟
- الكلاس قالب يجمع البيانات والدوال المرتبطة بها.
- الأوبجكت نسخة فعلية تم إنشاؤها من الكلاس.
- نستخدم الكلاس لتنظيم الكود وتقليل التكرار وحماية الحالة.
- يساعد الكلاس على إنشاء كائنات متعددة تتبع القواعد نفسها.
- يسهل تقسيم المشاريع الكبيرة واختبار أجزائها وتطويرها.
- لا يحتاج كل منطق برمجي إلى كلاس؛ قد تكون الدالة أفضل للعمليات البسيطة.
- يجب أن يمتلك الكلاس مسؤولية واضحة بدلًا من إدارة النظام كله.
- الوراثة مفيدة عند وجود علاقة منطقية حقيقية، وليست الحل الافتراضي دائمًا.
- التصميم الجيد لا يقاس بعدد الكلاسات، بل بوضوح المسؤوليات وسهولة التغيير.
ما الأسئلة الشائعة عن استخدام الكلاس؟
هل الكلاس ضروري في كل برامج البرمجة؟
لا. يمكن بناء برامج صغيرة باستخدام الدوال والمتغيرات فقط. يصبح الكلاس مفيدًا عندما توجد بيانات وسلوكيات مترابطة أو كائنات متعددة تحتاج إلى القواعد نفسها.
هل الكلاس هو نفسه الأوبجكت؟
لا. الكلاس قالب أو تعريف، بينما الأوبجكت نسخة فعلية تم إنشاؤها من هذا القالب وتحمل قيمًا خاصة بها.
هل استخدام الكلاسات يجعل البرنامج أسرع؟
ليس بالضرورة. الهدف الأساسي من الكلاسات هو تحسين تنظيم الكود وتصميمه وقابليته للصيانة. وقد توجد تكلفة بسيطة لإنشاء الكائنات حسب اللغة وطبيعة التنفيذ.
هل يمكن إنشاء أكثر من أوبجكت من الكلاس نفسه؟
نعم. يمكنك إنشاء عدد كبير من الكائنات من الكلاس نفسه، ويحتفظ كل كائن عادة بحالته وقيمه الخاصة.
هل الكلاس متاح في جميع لغات البرمجة؟
لا تتعامل جميع اللغات مع الكلاسات بالطريقة نفسها. تدعم لغات مثل Python وJava وC++ وC# الكلاسات، بينما تعتمد لغات أخرى على نماذج مختلفة أو توفر بدائل لتنظيم البيانات والسلوك.
أيهما أفضل: الكلاس أم الدالة؟
لا توجد إجابة واحدة لجميع الحالات. استخدم الدالة لمهمة مستقلة وبسيطة، واستخدم الكلاس عندما تحتاج إلى جمع حالة مستمرة مع مجموعة من السلوكيات المرتبطة بها.
هل يجب تعلم الكلاسات قبل بناء أول مشروع؟
يمكن البدء بمشاريع بسيطة باستخدام المتغيرات والشروط والحلقات والدوال، ثم تعلم الكلاسات عندما تبدأ الحاجة إلى تنظيم كيانات متعددة وعلاقات أكثر تعقيدًا.
ما أفضل طريقة لتعلم الكلاسات؟
ابدأ بكيان بسيط مثل كتاب أو طالب أو منتج. حدّد خصائصه، ثم أضف دالتين أو ثلاثًا تتعامل مع هذه الخصائص، وبعد ذلك أنشئ عدة كائنات واختبر اختلاف حالتها.
كيف تبدأ في استخدام الكلاسات بطريقة صحيحة؟
ابدأ بمشكلة حقيقية صغيرة بدلًا من حفظ المصطلحات فقط. اختر مشروعًا مثل سلة مشتريات أو مكتبة كتب، وحدد الكيانات التي تمتلك بيانات وسلوكًا واضحين.
أنشئ كلاسًا واحدًا، واكتب له مسؤولية محددة، ثم اختبره باستخدام أكثر من Object. عندما تجد أن الكلاس أصبح يدير وظائف غير مرتبطة، قسّمه إلى مكونات أبسط.
في هيلا تيك نؤمن بأن تعلم البرمجة يصبح أسهل عندما تنتقل من التعريف النظري إلى التطبيق. ابدأ الآن بتصميم كلاس يمثل عنصرًا من مشروعك، وراقب كيف يساعدك على تحويل الكود المتفرق إلى نظام واضح يمكن تطويره بثقة.
