التصميم كائني التوجه( Object-oriented design) هو عملية تخطيط نظام الخاص بالكائنات المتفاعلة بغرض حل مشكلة برمجية. بمكن التعبير عنها أنها عبارة عن نهج واحد لتصميم البرمجيات .
نظرة عامة
يحتوي الكائن على بيانات وإجراءات مغلفة مجمعة معًا (grouped together) لتمثيل كيان (entity). "واجهة الكائن" ('object interface') تعرّف (defines) كيفية التعامل مع الكائن . يتم وصف برنامج كائني التوجه بتفاعل هذه الكائنات. التصميم الموجه للكائنات هو نظام تعريف الكائنات وتفاعلاتها لحل مشكلة تم تحديدها (identified ) وتوثيقها (documented) أثناء التحليل الموجه للكائنات .
ما يلي هو وصف للمجموعة الفرعية المبنية على الأصناف (class-based) للتصميم الموجه للكائنات ، والتي لا تتضمن المناهج القائمة على النموذج الأولي للكائن (object prototype-based) حيث لا يتم الحصول على الكائنات عادةً عن طريق إنشاء مثيل للأصنف ( instantiating classes) ولكن عن طريق استنساخ (cloning ) كائنات أخرى (نموذج أولي). التصميم الموجه للكائن هو طريقة للتصميم تشمل (encompassing) عملية التحلل (decomposition) الموجه للكائن وتدوينًا (depicting) لتصوير النماذج المنطقية والفيزيائية (logical and physical) وكذلك النماذج الديناميكية للنظام تحت التصميم.
موضوعات التصميم كائني التوجه
الإدخال (input) (المصادر) للتصميم كائني التوجه
يتم توفير مدخلات (input) التصميم الكائني التوجه من خلال إخراج (output) التحليل الكائني التوجه . ندرك أن مخرجات الناتج (output artifact) لا تحتاج إلى تطويرها بالكامل لتكون بمثابة مدخلات للتصميم الكائني التوجه. قد يحدث التحليل والتصميم بالتوازي ، وفي التطبيق العملي، يمكن أن تغذي نتائج نشاط واحد النشاط الآخر في دورة تغذية راجعة (feedback) قصيرة من خلال عملية تكرارية (iterative process) . يمكن إجراء كل من التحليل والتصميم بشكل تدريجي ، ويمكن تطويرالأدوات (artifacts) بشكل مستمر بدلاً من تطويرها بالكامل في لقطة واحدة ( one shot).
بعض عناصر الإدخال النموذجية (typical input artifacts) للتصميم كائني التوجه هي:
- النموذج المفاهيمي (Conceptual model): نتيجة للتحليل الكائني التوجه ، أنه يلتقط المفاهيم في نطاق المشكلة . يتم اختيار النموذج المفاهيمي بشكل صريح ليكون مستقلاً عن تفاصيل التنفيذ (implementation)، مثل التزامن أو تخزين البيانات.
- حالة الاستخدام (Use case) : وصف تسلسل الأحداث التي تؤدي مجتمعةً إلى قيام النظام بعمل مفيد. توفر كل حالة استخدام سيناريو واحد أو أكثر ينقل الكيفية التي ينبغي أن يتفاعل بها النظام مع المستخدمين الذين يطلق عليهم الممثلون (actors )لتحقيق هدف أو وظيفة تجارية محددة. قد يكون الممثلون (actors) في حالة الاستخدام مستخدمين نهائيين (end users) أو أنظمة أخرى( other systems). في كثير من الظروف ، يتم شرح حالات الاستخدام بشكل أكبر في مخططات حالة الاستخدام (use case diagrams). تُستخدم مخططات حالة الاستخدام لتحديد الممثل (identify the actor) (المستخدمون أو الأنظمة الأخرى) والعمليات التي يقومون بها.
- رسم تخطيطي لتسلسل النظام (System sequence diagram): الرسوم البيانية لتسلسل النظام( system sequence diagrams (SSD)) هي صورة توضح ، بالنسبة لسيناريو معين لحالة الاستخدام ، الأحداث التي يولدها الممثلين الخارجيين (external actors)، وترتيبهم ، والأحداث المحتملة بين النظام (inter-system events).
- وثائق واجهة المستخدم (User interface documentations) (إن وجدت): مستند يعرض ويصف شكل وأسلوب( look and feel) واجهة المستخدم للمنتج النهائي (end product's user interface). ليس من الضروري الحصول على هذا ، ولكنه يساعد على تصوير (visualize) المنتج النهائي (end-product) وبالتالي يساعد المصمم (designer).
- نموذج البيانات العلائقية (Relational data model) (إن أمكن): نموذج البيانات (data model) هو نموذج مجرد (abstract model) يصف كيفية تمثيل البيانات واستخدامها. إذا لم يتم استخدام قاعدة بيانات كائن ، يجب إنشاء نموذج البيانات العلائقية (relational data model) قبل التصميم ، نظرًا لأن الإستراتيجية المختارة لرسم الخرائط العلائقية للكائنات (object-relational mapping) هي ناتج لعملية تصميم كائني موجه (OO). ومع ذلك ، من الممكن تطوير نموذج البيانات العلائقية (relational data model) الأدوات التصميمية الموجهة للكائنات بالتوازي (object-oriented design artifacts in parallel)، ويمكن أن يحفز نمو الأداة (artifact) لتحسين الأدوات الأخرى.
مفاهيم موجهة للكائنات
المفاهيم الأساسية الخمسة للتصميم الموجه للكائنات هي ميزات مستوى التنفيذ (implementation level features) المبنية (built into) في لغة البرمجة. غالبًا ما تتم الإشارة إلى هذه الميزات من خلال هذه الأسماء الشائعة:
- كائن / صنف (Object/Class): اقتران (coupling) أو ربط وثيق (association) لهياكل البيانات ( data structures) مع الطرق (methods) أو الوظائف (الدوال) (functions) التي تعمل على البيانات. هذا يسمى صنف (class) ، أو كائن (object) (يتم إنشاء كائن بناءً على صنف). كل كائن يخدم وظيفة منفصلة. يتم تعريفها بخصائصها (properties ) ، ماهيتها و ما يمكن أن تفعله. يمكن أن يكون الكائن جزءًا من صنف ، وهي مجموعة من الكائنات المتشابهة.
- إخفاء المعلومات (Information hiding) : القدرة على حماية (protect) بعض مكونات (components) الكائن من كيانات خارجية (external entities). يتم تحقيق ذلك من خلال الكلمات المفتاحية اللغوية ( language keywords) لتمكين الإعلان (declared) عن متغير (variable) على أنه خاص(private) أو محمي(protected) للصنف المالك.
- الوراثة : قدرة الصنف (class) على توسيع (extend) أو تجاوز (override) وظيفة صنف أخرى (functionality of another class). يحتوي ما يسمى بالصنف الفرعية (subclass) على قسم كامل مشتق (موروث) من الصنف الأصل (superclass) ومن ثم لديه مجموعة من الوظائف (functions) والبيانات الخاصة به.
- Interface() (برمجة موجهة للكائنات) : القدرة على تأجيل تنفيذ (implementation) طريقة (method) . القدرة على تعريف (define) التواقيع (signatures) للدوال (functions')' أو الأساليب(methods ) دون تنفيذها (without implementing them).
- تعدد الأشكال (Polymorphism) (على وجه التحديد ، اشتقاق النوع بشكل فرعي (Subtyping)): القدرة على استبدال كائن (object) ما بكائناته الفرعية (with its subobjects) . قدرة متغير الكائن (object-variable) على احتواء (contain)، ليس هذا الكائن فقط ، ولكن أيضًا جميع الكائنات الفرعية (subobjects) الخاصة به.
مفاهيم التصميم
- تعريف الكائنات (Defining objects)، إنشاء (creating) رسم تخطيطي للصنف(class diagram) من الرسم التخطيطي المفاهيمي (conceptual diagram) : عادة تعيين الكيان إلى الصنف (map entity to class) .
- تحديد (Identifying) السمات (attributes).
- استخدام أنماط التصميم (design patterns) (إن وجدت): نمط التصميم ليس تصميمًا منتهيًا ، إنه وصف لحل لمشكلة شائعة في سياق ما.
[1] الميزة الرئيسية لاستخدام نمط التصميم هي أنه يمكن إعادة استخدامه في تطبيقات متعددة. يمكن أيضًا اعتباره قالباً لكيفية حل مشكلة يمكن استخدامها في العديد من المواقف و / أو التطبيقات المختلفة. عادةً ما تُظهر أنماط التصميم الكائني التوجه (Object-oriented design patterns) العلاقات (relationships) والتفاعلات (interactions) بين الأصناف أو الكائنات ، دون تحديد أصناف التطبيق النهائي (final application classes) أو الكائنات المتضمنة (objects that are involved).
- تعريف (Define) إطار التطبيق (application framework) (إن وجد): إطار التطبيق عادة ما يكون مجموعة من المكتبات أو الأصناف التي يتم استخدامها لتنفيذ الهيكل القياسي (to implement the standard structure) لتطبيق (application) لنظام تشغيل معين. من خلال تجميع (bundling) كمية كبيرة من الكود القابل لإعادة الاستخدام في إطار عمل ،(framework) بذلك يتم توفير الكثير من الوقت للمطور (developer)، حيث يمكن أن يحفظه في مهمة إعادة كتابة كميات كبيرة من الكود القياسي لكل تطبيق جديد يُطوّر (is developed).
- تحديد الكائنات / البيانات الدائمة (Identify persistent objects/data) (إن أمكن): حدد الكائنات( Identify objects) التي يجب أن تستمر لفترة أطول من وقت تشغيل واحد للتطبيق (single runtime of the application). إذا تم استخدام قاعدة بيانات علائقية( relational database) ، قم بتصميم تخطيط علاقة الكائن (object relation mapping).
- تحديد (Identify) وتعريف (define) الكائنات البعيدة (remote objects) (إن وجدت).
إخراج (مخرجات) التصميم كائني التوجه
- مخطط التسلسل (Sequence diagram): قم بتوسيع مخطط تسلسل النظام (system sequence diagram) لإضافة كائنات محددة تتعامل مع أحداث النظام.
- يُظهر مخطط التتابع (sequence diagram) ، كخطوط عمودية متوازية ، عمليات أو كائنات مختلفة تعيش في وقت واحد (simultaneously)، وكأسهم أفقية (horizontal arrows)، يتم تبادل الرسائل فيما بينها ، بالترتيب الذي تظهر به.
- مخطط الصنف (Class diagram): يمثل الرسم التخطيطي للصنف نوعًا من مخطط UML للهيكل الثابت( static structure) يصف بنية النظام (structure of a system) من خلال إظهار أصناف النظام (system's classes) وسماتها (attributes) والعلاقات بين الأصناف (relationships between the classes). يمكن للرسائل والأصناف التي تم تحديدها من خلال تطوير مخطط التتابع أن تكون بمثابة مدخلات (Inputs) للإنشاء التلقائي لمخطط الصنف العام للنظام (global class diagram of the system) .
بعض مبادئ واستراتيجيات التصميم
- حقن التبعية (Dependency injection) : الفكرة الأساسية هي أنه إذا كان الكائن (object) يعتمد على وجود مثيل لكائن آخر (instance of some other object)، فإن الكائن المطلوب "يتم حقنه" ("injected") في الكائن التابع (dependent) ؛ على سبيل المثال ، يتم تمرير اتصال قاعدة بيانات (database connection) كقيمة (argument) للمنشئ (constructor) بدلاً من إنشاء واحد داخليًا (instead of creating one internally).
- مبدأ التبعيات الحلقية (Acyclic dependencies principle): الرسم البياني للتبعية للحزم (dependency graph of packages) أو المكونات (components) :تعتمد التقسيمات (granularity) على نطاق (scope of work for) العمل لمطور واحد (one developer)) يجب ألا يحتوي على دورات. ويشار إلى هذا أيضًا بوجود رسم بياني لا دوري موجه[2]directed acyclic graph. على سبيل المثال ، تعتمد الحزمة (package C) على الحزمة (package B) ، والتي تعتمد على الحزمة( package A). إذا كانت الحزمة (package A) تعتمد أيضًا على الحزمة (package C) ، فستكون لديك حلقة (cycle).
- مبدأ إعادة الاستخدام المركب (Composite reuse principle): يفضل التركيب (composition) متعدد الأشكال (polymorphic) للكائنات على الميراث. [1]
مقالات ذات صلة
المراجع
- Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. 1995. . مؤرشف من الأصل في 26 مارس 2020.
- "What Is Object-Oriented Design?". Object Mentor. مؤرشف من الأصل في 30 يونيو 200703 يوليو 2007.
روابط خارجية
- التحليل والتصميم الكائني - نظرة عامة باستخدام UML
- لارمان ، كريج. تطبيق UML والأنماط - الإصدار الثالث
- التحليل والتصميم الكائني التوجه
- LePUS3 و Class-Z : لغات النمذجة الرسمية للتصميم الكائني التوجه