AR
RU
EN
ES
ZH
FR
DE
PT
HI
أنماط التصميم في Kotlin: متى ولماذا
\n\nهل سبق لك أن كتبت كودًا أصبح بعد شهر لغزًا حتى بالنسبة لك؟ أو واجهت موقفًا يؤدي فيه تغيير بسيط في مكان واحد إلى تعطيل التطبيق بأكمله؟ مرحبًا بك في عالم التطوير الحقيقي! هنا تأتي أنماط التصميم للإنقاذ — وهي قوالب حلول مثبتة عبر الزمن للمشاكل النمطية. لكن في Kotlin، بفضل تركيبته الحديثة وميزاته القوية، تكتسب العديد من الأنماط الكلاسيكية حياة جديدة. دعنا نفهم كيف ومتى نطبقها، بحيث لا يكون كودك فعالاً فحسب، بل أنيقًا أيضًا.
\n\nلماذا يغير Kotlin قواعد اللعبة؟
\nKotlin ليس مجرد "Java بدون كود متكرر". إنها لغة استوعبت أفضل ما في البرمجة الوظيفية والكائنية التوجه. بفضل الدوال عالية المستوى، اللامبدات، فئات البيانات، والمفوضين، تصبح العديد من الأنماط إما تافهة أو تُنفذ بطريقة مختلفة تمامًا. على سبيل المثال، نمط Singleton في Java يتطلب طقوسًا كاملة مع volatile وsynchronized. في Kotlin؟ مجرد كلمة object. لكن الشيطان، كما هو الحال دائمًا، في التفاصيل: من المهم ليس فقط معرفة التركيب، بل فهم متى تحتاج النمط، ومتى يكون عبئًا معماريًا زائدًا.
أفضل 4 أنماط يجب أن يعرفها كل مطور Kotlin
\nلن نعدد جميع أنماط GoF الـ 23 — فالعديد منها في Kotlin يُحل باستخدام أدوات مدمجة. بدلاً من ذلك، سنركز على تلك التي تمنح Kotlin مزايا حقيقية.
\n\n1. Builder: عندما يكون المُنشئ مؤلمًا
\nتخيل أنك تنشئ كائنًا بـ 15 معاملًا، نصفها اختياري. المُنشئ الكلاسيكي يتحول إلى كابوس، والمُنشئات التلسكوبية (واحد بـ 3 معاملات، وآخر بـ 5...) تصبح نمطًا معاديًا. هنا يظهر Builder على المسرح.
\n\nفي Java، كنت ستكتب فئة منفصلة بسلسلة معقدة من الدوال. في Kotlin، الأمر أبسط: استخدم المعاملات المسماة والقيم الافتراضية. لكن إذا كنت بحاجة إلى منطق مخصص للتحقق أو البناء — مرحبًا بك في عالم apply ودوال النطاق.
\n\n// مثال: بناء طلب HTTP باستخدام نمط Builder\nclass HttpRequest private constructor(\n val url: String,\n val method: String,\n val headers: Map<String, String>,\n val body: String?\n) {\n // Builder داخلي (بأسلوب DSL)\n class Builder {\n private var url: String = ""\n private var method: String = "GET"\n private var headers: MutableMap<String, String> = mutableMapOf()\n private var body: String? = null\n\n fun url(url: String) = apply { this.url = url }\n fun method(method: String) = apply { this.method = method }\n fun header(key: String, value: String) = apply { this.headers[key] = value }\n fun body(body: String) = apply { this.body = body }\n\n fun build(): HttpRequest {\n require(url.isNotBlank()) { "URL لا يمكن أن يكون فارغًا" }\n return HttpRequest(url, method, headers.toMap(), body)\n }\n }\n}\n\n// الاستخدام — موجز وقابل للقراءة\nval request = HttpRequest.Builder()\n .url("https://api.example.com/data")\n .method("POST")\n .header("Content-Type", "application/json")\n .body("""{"key": "value"}""")\n .build()\n\nprintln(request)\nالمزايا: تحصل على مرونة بدون كود ضخم. نمط Builder في Kotlin لا يعني "كتابة الكثير من الكود"، بل التحكم في إنشاء كائن معقد.
\n\n2. Singleton: واحد للجميع
\nيُستخدم Singleton عندما يجب أن يكون هناك مثيل واحد فقط من الفئة في التطبيق: مسجل، إعدادات، مجموعة اتصالات. في Java، هذا صداع أبدي مع التحقق المزدوج من القفل. في Kotlin — فقط أعلن object.
